CAN reliability

[Radical Pi]

My mistake on the serial bandwidth. The point still stands though that it's not an issue.

I see the 5 bytes too of data in the soft limits code for C++ as well.

Yes, both languages use the same .out file, but the driver only handles pulling the data off of the serial line and splitting messageID from data. The CAN protocol is still defined by user code.

I think I may have a reason for the slowdown and the jitter. In the C++ code, all requests to the CAN driver are routed through either FRC_NetworkCommunication_JaguarCANDriver_sendMessa ge, or FRC_NetworkCommunication_JaguarCANDriver_receiveMe ssage. Also, when the driver is loaded by the OS, the init calls FRC_NetworkCommunication_JaguarCANDriver_registerI nterface with a pointer to the driver class. By the names, I'd assume that all messages are run through the NetworkCommunication library before they get to the driver itself, most likely so a disabled robot cannot continue to send CAN messages. NetworkCommunication is searching for a driver station and communicating with the driver station, so it could account for the delay and the jitter.

As a test, could you put a timer around setTransaction, or even better around the receiveMessage inside setTransaction? receiveMessage directly calls the NetworkCommunication library, so it would be the best place to time the command

One quick question. I see a few "trusted" commands (Enable and Set for each of the control modes) which get an extra 2 bytes of 0s at the beginning of their data section. I don't have the source to the jag firmware that reads Trusted commands, so I'm wondering if you know what trusted means and why it should be used