[apalrd]

I am familiar with CAN in the automotive industry, and read the entire LabVIEW FRC CAN driver, but FRC CAN is a terrible mess of garbage due to some insane restrictions on the Jaguar's CAN chip and poor software, and I highly recommend against ever using it in FRC.

Basically, the Jaguar's CAN chip has a 1-message rx buffer, and the receiving software in the Jaguar is either not interrupt driven or the 1khz control loop has higher priority, so multiple messages will overwrite and possibly corrupt the buffer (why not lock the buffer while reading?). The FRC solution is to not send another message to a single Jaguar until the Jaguar responds with an Ack. The WPIlib implementation waits for the Ack by locking the thread and waiting, which is terrible programming practice, especially in a single-threaded program sending command messages at 100hz plus configuration messages possibly as fast. Also, a single Jaguar failure will cause a 10ms task delay for each message missed when a Jaguar is down, which can cause several task iteration to be skipped waiting for Acks from other Jaguars.

A better solution would be to queue all messages to send to the Jaguars for a given loop tick and send one message to a jaguar at a time and hope the spacing is enough, relying on the CAN checksum, or use a state machine for each Jaguar to check if an Ack has been received without block-waiting for it and locking the thread.

Luckily, the great folks at Cross The Road Electronics are working hard to fix this for the 2015 control system. Until then, Jaguar CAN sucks.