[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.