[apalrd]

In industry, a good CAN stack will usually do one of the following:
-Use an ISR or other interrupt-like task to deal with messages as they come. This is usually done for the rare protocols which use a single ID for all of their messages (CCP is like this).
-Store the latest message in a buffer. There are several variants to this implementation. Depending on how tightly the OS and application are integrated, the buffer either stores the latest message by ID (one message per ID deep) or it depacketizes them into the values within which are stored as variables, and other software reads the variables to get the values when it wants the data.

The ideal way to do CAN is purely isochronously. Every loop, in an ideal world, the Jaguar would send out all of it's status data at a frequency which is fixed (100hz seems good for a 1M CAN bus). Every loop, the application code on the cRio would send out all important dynamic Jaguar parameters in a single message, using all 8 bytes to save packet overhead. Less important data gets sent less frequently, e.g. 10hz or 50hz or 20hz, to reduce bus load.

For some reason, the *IMHO REALLY BAD DESIGN* current CAN stack waits for an Ack on everything by default (the Set can act isochronously, but nothing else does). It should just spam the Jaguar with a configuration packet at 20hz and setpoint/speed commands at 100hz and be done, and the Jaguar should pack it's messages more efficiently (e.g. full 8-byte utilization, with sub-8bit parameters packed tightly). This would allow you to send all of the non-static configuration parameters fast enough to not care if it resets and not monitor for it.



So, to answer your original question, a well-designed CAN stack would buffer exactly one of each message ID, the latest one, but the FRC CAN system isn't exactly 'well-designed'.