Generally there are two very different flavours of CAN networks.
- Large networks with lots of nodes/sensors, such as industrial/factory automation applications.
- Control system networks where something is responding fast and in real-time, such as cars, machines, general actuators. These are often mission-critical.
In the "large industrial network" version it becomes important to control bus load. If you have 100 different sensors reporting in to some data collector, they can't just chatter away or you'll get 100% bus load with timing destroyed. You will get starvation phenomenon where lower priority messages never gets access to the bus - eventually leading to nodes going error passive/bus off.
To avoid high bus load, nodes could be configured to only send data when it is changing. When you use such a setting, it can be combined with an inhibit time, to make sure that a node where data is changing a lot still keeps calm and only sends data with a minimum time interval.
Other mechanics such as a master sending out a "SYNC" message can be used. Then each node is configured to respond from the point where it gets "SYNC" until a certain amount of time has passed. With this method you could configure individual offsets per node, so that they all respond at different points in time, regardless of their internal clocks.
CANopen supports a lot of features like these. Many device profiles like CiA 401 for generic I/O are set by default to keep their data output low and only send when there's new data available.
In the "control system network" version however, you always send all data cyclically over and over, regardless if there were any changes. This means that in case of data corruption or lost communication, such errors will only last until the next data cycle. Only sending a message upon change becomes very dangerous in case a node misses to catch that one message for whatever reason.
Typically these cycles are set to once per 1ms, 10ms or 100ms. And it also becomes possible to calculate "hard" real-time response of everything on the bus. Every node will be designed with a time-out and revert to a safe mode in case new messages stop coming.
These kind of systems have a higher bus load overall, but are deterministic, with careful timing considerations made by the one who designed the bus.
"SYNC" messages can be used here too, but rather for the purpose of acting like a crude system clock. Suppose for example that you control two proportional actuators at once, but from different nodes, and they need to move in unison. You can achieve this with "SYNC" and the accuracy is quite high: basically the MCU clock accuracy plus a bit of propagation delay, both likely negligible (assuming external quartz oscillator).