Need a programmer familiar with CAN

Hey guys,

I need somebody who has worked with CAN before. I’m working on ATALibJ and I have to make a module for CANJaguars. If you have experience with CAN, please PM me. I don’t have the first clue on how exactly to do it and I need the module done.

I’ll explain the details of the project if you can help out.


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.

I’m sorry if I was unclear with my intentions. I agree with you and am not planning to use CAN at all. I’m building a library in Java for FRC teams that wraps all of the wpilibj classes. Naturally, CANJaguar is on that list. I mostly have to do it out of necessity, and not at all because I think people should use it.

Continuing to parrot this rhetoric at every opportunity over a season after No-Ack commands have been implemented in the Jaguar firmware and LabVIEW libraries doesn’t seem quite right.

Now if you want to complain about the C++ and Java libraries not implementing them, that would probably be more appropriate.

I suggested an alternative method using a state-machine for each Jaguar. There are still many deficiencies of the protocol, as the isochronous updates only apply to set commands, not set configuration, and configuration is volatile so it must be re-sent periodically if a device resets, or if the software wishes to change it (e.g. gain scheduled PID). A purely isochronous protocol would be significantly better.

When I implemented a rewrite of WPIlib in LabVIEW, I removed all CAN support because it wasn’t worth the trouble. In fact, I removed almost all FPGA functionality that wasn’t commonly used to improve efficiency. I only kept PWM, Analog input, Accumulator, DI, Relay, Solenoid, Encoder, and Counter. I will heavily consider adding CAN support back in for 2015, if CTRE improves the protocol design.

As for C++/Java libraries not implementing them, then the isochronous no-ack set command messages would be a good step.

If you would like any advice at all on how FRC-can operates or implementation advice from a CAN message standpoint (not java specific), I can answer questions, but I am not a Java programmer.