One of the things you need to be aware off as you design (or use) a CAN based protocol is how arbitration works and how it can be used to your advantage or create a timing bug if it used wrong.
CANbus consist of a 11 or 19 bit ID field at the head of a message. These bits are part of what is called the “arbitration field” where 0 is a “dominant” bit. As a device want to send a message it waits for the bus to be idle and then start sensing on a clever timed scheme. At this point our device might be one of many that start sending, so we read back what was sent on the bus. If one device send 0 and another 1 the electronics will work the way that 0 becomes dominant. The device that send 1 and read 0 will stop sending and the device sending the lowest id field will at the end complete it’s sending. This means two things:
ID=0 is a very good candidate for a high priority alarm message.
Some messages will be delayed due to the bus being busy and their ID did not win the arbitration. This means that as you want to send a message every 100ms that message might pop up much later than you expect if you have a busy network and accidentally many devices that want to send.
This arbitration delay can lead to some very random and frustrating timing issues if your CAN protocol is designed wrong as in not handling this well. Messages simply get delayed.
Do however remember that the main reason for messages being delayed usually is noise on the twisted pair causing CRC errors.
How do you see these things? The answer is that you need an advanced CAN logger and CAN Protocol Analyzer that tend to cost a bit of money. This is easy to detect scanning a log as you will see this as dense message sequences in the log. A proper analyzer will show you a graph or alarm you about arbitration situations of some length, but these tools sadly cost money.