Guard protocol – CanOpen

The Guarding protocol is used for boot messages, heart beat messages and to ensure that nodes are alive and healthy or to generate errors if not.

Two principles are used for guarding and this is

1. heartbeat messages, where the nodes transmits their communication state as a proof of live
2. node-guarding, where each node is queried by the NMT master to check it is alive.

With heatbeat messages nodes can be configured as heartbeat producers or heartbeat consumers, if a consumer does not see a expected heartbeat within its expected interval it signals an error

With node guarding, nodes are expected to respond to a can remote frame with in a certain time “node life time” and likewise the nodes expect to see a request from the master and if it goes missing for a certain period they assume the master as failed and sends a “Life guarding event”. If the node guarding master doesn’t receive the current state reply within the guard time, it signals a remote error for that slave. If the slave doesn’t receive this request during its ‘life time’ (guard time * life time factor) then the slave will switch to pre-operation state.

All nodes always transmit a heatbeat when switching into pre-operation state

The packet format is as follows:-

Status can be

Value

The extra bit 0x80 is only used in the guarding protocol where it must toggle every transmission, in heartbeat mode it is fixed as 0.

The following Object Dictionary entries control the guarding/heartbeat

Heartbeat consumer (0x1016) is an array of 32bit values that describe the heartbeat monitoring configuration. each monitored node should have an entry as a sub index of 0x1016, each sub index has the following makeup:-