CANbus consultant?

The maximum latency is linear only if the bus is utilized under 30%, so it is unlikely that the low priority device will give the way to the same high priority device more then at one time per waiting period. The expected latency is exponential anyway.

It is not so simple because the periods of transmission are different and affected by the external events. Although the load is low on average, there could be high peaks. This is another reason to stay within average 30% of bus utilization.

So, CanOpen is a hierarchy network with the explicit measures to minimize the contentions. And the reaction time can't be better then the SYNC period. And the SYNC period should be made long enough so every device can transmit in one period.

VLV

The latency increases in a linear way as long as the rate of high priority message transmission is regulated. If a high priority device is allowed to transmit constantly without pauses, it will hog the bus. IMHO such devices are faulty and equivalent to a DoS attack.

Compare the situation in any priority based RTOS, in which the RTOS can only guarantee the execution time of the highest priority runnable task. It can not guarantee anything for any low priority runnable tasks, which are at the mercy of the high priority task.

If the high priority task decides to run a busy loop forever, all the low priority tasks will be blocked forever. Thus, such task is conceptually similar as a CAN device transmitting indiscriminately at a high priority.

When using a priority based RTOS, much care is needed to keep the execution time short and precipitable for high priority tasks, in order to be able to calculate the latencies for any low priority tasks.

However, most priority based operating systems have some kind of lowest priority task (NULL/IDLE task) that executes constantly a busy loop (or a busy loop containing an wait for interrupt instruction to save power). This is perfectly OK, since the execution is preempted by any higher priority task becoming runnable.

On the CAN bus, you should control the maximum transmission rate of high priority messages, but on the other hand, if some device has some "nice to know" information, such as the outdoor temperature, it can be transmitted with a low priority message as often as the bus is free. It does not matter, if you get the temperature reading once during a one second period, but ten times during the next one second period, if the measurement is only used to decide, if you are going to use a hat when you go out.

Sending such non-essential data and keeping the bus at a constant 100 % load is OK and is conceptually similar to the NULL/IDLE task in some RTOS. In neither case does this hurt the high priority messages/tasks.

The transmission rate on high priority messages should be regulated in one way or other. Low priority messages can be sent to the CAN controller at any time (and possibly delayed by high priority messages on the bus).

Reading with the SYNC is one option, when you want to sample the external word at exactly the same time using sensors on many different nodes, however, the delivery latencies may vary, but the sample point is the same in all cases.

The SYNC method in fact generates the worst congestion, when all nodes wants to transmit simultaneously.

However, if you remove the SYNC and configure each node to transmit at the same rate as the SYNC message appeared, each node will sooner or later transmit at different times, reducing the congestion.

Not necessary. If you want to record accurately the state change time from a signal that rarely changes state, just send a high priority change of state message, however, do not send a new change of state message until an adjustable inhibit time, if the signal changes often against all expectations, thus extending the "pulse". For instance when using alarms, it is usually more important that the activation event is recorded accurately, while the time the alarm was reset is of less urgency.

This is a good design practice :-).

Paul

True in principal, except for the very highest priority message which always gets the bus.

Not true in practice, because if you know which way is up you very carefully apportion the bus resources for the highest priority messages, and you make sure that they're periodic with known period -- this lets you calculate the maximum expected latency (which had better be less than one period!).