Do we need to wait between CAN Bus commands?

[ksanger]

Hi;

My question is that in 2016 do we still need to wait between sequential CAN Bus Commands? In the past if we wrote to a CANJaguar we needed to wait before issuing another command too fast. I've read that the devices are being queried and updated every 20 msec. But I have not found any information regarding a need to wait between CAN commands for the last command to finish. For instance if we read currents from the Power Distribution Panel do we need to wait between reading the first and the second channels? Would we have issues reading four channels in a row? Or do the new libraries take care of that for us?

Should we assume that a CAN command that returns a value will not continue until the value is read? And that a command that sets a value without returning a variable may take a while to actually execute? Therefor we do not need to wait after asking for a reading, but may need to wait after sending a command? Or do the libraries buffer all CAN commands?

We are programming in Java.

Thanks

[Alan Anderson]

You should probably go with the assumption that the actual CAN messages are happening constantly in the background, and your code won't need to wait. The status frames are read and cached by the communication code, so your program gets an immediate answer when it asks for a value.

[apalrd]

In general, CAN (in general, not specific to FRC) is implemented as an isochronous network.

This means that real-time data on the network is continuously retransmitted at some interval, and only the latest frame with a given ID is needed.

With a network like this, all devices which produce data will transmit it on the bus at a regular, fixed interval, which is picked to not overload the bus but still provide data fast enough for it to be useful.

All of the new CTRE CAN products operate in this way. As status frames are received by the low-level CAN driver, they are buffered. A read call by the high level libraries simply returns the data from the last CAN frame received, it doesn't actively request it from the device. Outgoing messages are actively transmitted whenever you call the set functions, so your code determines the transmit rate of these on the bus.

The older CAN Jaguars operated much differently, they used a synchronous message passing system which required roughly 2x the CAN bandwidth (all packets had a request and response). This also required the user code to wait for the response message. In my understanding, this was done because the Jaguar had a poor CAN firmware implementation and too many messages addressed to a single Jaguar too quickly could cause a CAN buffer overrun, so the user code had to wait for an ACK from that Jaguar before sending another message to it. This is not normal for CAN design.

[RufflesRidge]

The older CAN Jaguars operated much differently, they used a synchronous message passing system which required roughly 2x the CAN bandwidth (all packets had a request and response). This also required the user code to wait for the response message. In my understanding, this was done because the Jaguar had a poor CAN firmware implementation and too many messages addressed to a single Jaguar too quickly could cause a CAN buffer overrun, so the user code had to wait for an ACK from that Jaguar before sending another message to it. This is not normal for CAN design.

This describes the original Jaguar protocol.

Asynch was added to the Jag firmware even before the switch to roboRIO. During the switch last year, the WPILib portions of CANJag (for sure for C++ and Java, and I think LV too) were rewritten to make them work like the CTRE hardware from a user perspective.

[ksanger]

Thanks guys; I didn't realize everything that was going on in the background. Explains how the DriverStation SW has a record of all of the reading of the PDP after an Enable/Disable session.

Thanks again.