[Radical Pi]

Originally Posted by Mike Copioli

This is not the case when CAN is implemented correctly. The FRC implementation is not the most efficient way. The current approach sends every CAN message over Ethernet/serial from the cRIO. The CAN device then must send an ACK back over Ethernet/serial to the cRIO. If I remember correctly the function is also blocking. A better way would be to allow the gateway device (2CAN or Black JAG) to perform all of the CAN "hand shaking" and have the application simply make requests for position, speed or current... The reason for the current implementation is to allow teams to create their own CAN gateways without having knowledge of the Tokenization protocol used by the Jags.

That's not quite true. On things like Set(), there is a message then an ACK, but on things like GetCurrent(), there is no ack, just the data. And only the sending portion of the message is blocking, the received messages can arrive out of order and do not block other receiving messages.

The current system also doesn't send entire CAN messages over the (Black Jag) bridge device. Only the minimal data is sent (MessageID, size, extra data) over the serial connection, the rest is filled in by the CAN driver on the jag. The only "Hand Shaking" that the cRIO sees is ACK replys from send messages (like Set()), and the data from requesting messages acts as the ACK. The cRIO never sends ACKs to the jaguars. The only thing that could potentially be removed from communications in the ACK from the jaguar, which would mean no error messages could be seen about a lost jaguar unless a requesting message was sent.