Error control protocols

Error control protocols enable the monitoring of a CANopen network. They comprise the Heartbeat-, Node-/Life-Guarding-, as well as the Boot-up protocol. The Heartbeat protocol is used to verify that all network participants are still available in a CANopen network and that they are still in their intended NMT FSA state. In old-fashioned CANopen systems, the CAN remote frame-based Node-/Life-guarding protocol is used for this purpose, instead of the Heartbeat protocol. CAN in Automation no longer recommends using CAN remote frame-based services. All error control protocols (Heartbeat and Boot-up message) use the same the CAN-ID (700h + Node-ID).

Heartbeat protocol

The Heartbeat protocol is a cyclically transmitted message that informs all heartbeat consumers of the availability of the heartbeat producer. In addition to the availability of the heartbeat producer, the heartbeat protocol provides the current NMT FSA state of the heartbeat producer. The cycle time for transmitting the Heartbeat message is configurable in the object dictionary index 1017h.

Boot-up protocol

The boot-up protocol represents a special type of an error control protocol. It is transmitted as the final action in NMT FSA state Initialisation, prior to enter the NMT FSA state Pre-operational. The reception of this message indicates that a new device has been registered to the CANopen network. The unintended reception of such a protocol during runtime either indicates a change in the network setup (e.g. due to the addition of a new CANopen device) or is considered a sign for an error condition (e.g. erroneous power supply of related CANopen device). The protocol uses the same identifier as any other error control protocol, such as e.g. the heartbeat protocol. The 1-byte data field has a fixed value of zero.

Node-/Life guarding protocol

Guarding is an outdated method of checking whether a guarded CANopen device is still working in the correct network state. As this is an RTR-based service, the Heartbeat protocol is used in new designs. In old-fashioned applications, the host controller triggers the error control information of the monitored CANopen devices via the CAN remote frame (RTR) for example. Each monitored CANopen device has to be triggered individually. The monitored device replies with a CAN data frame that indicates the current NMT FSA state.