CANopen Device Monitoring
To ensure the continuity of the network of nodes, CANopen offers two alternatives:
- Node Guarding, whereby the so-called ‘NMT master’ cyclically queries the node status; or
- Automatic transmission of a “Heartbeat Message” from the network nodes.
A single CAN-ID per node is required to monitor the device’s communication status. Low-priority message IDs, with a value of 1792 + node-ID, are reserved for this purpose.
Node Guarding
In this process, the NMT master queries the other CANopen nodes in the network – the ‘NMT slaves’ – one by one using a CAN-Remote Frame and requests that they return a message containing their current communication status. This takes place at regular intervals, known as the “guard time” . A node responds with a “Node Guarding” message, as shown below, which includes a Toggle bit. This bit changes value with every transmission. This is intended as a simple check to determine whether a message has been missed.
If a node fails to respond to the NMT master’s request within a specified time – the “Node Life Time” – it is considered a node failure. The NMT master’s host controller is notified via a “Node Guarding Event”. It is then up to the application software to take appropriate action.
At the same time, the NMT slaves also check whether they have received a request from the NMT master within this “Node Life Time”. If no such request is received within the specified time, the NMT slave assumes that the NMT master itself has failed and internally reports this event as a “Life Guarding Event”.
Nowadays, Node Guarding has taken a back seat. This is mainly due to the higher bus load, as two CAN messages are required per monitoring interval. However, the centralisation of device monitoring for CANopen nodes on the NMT master is also seen as less desirable.
Heartbeat
With node monitoring based on the heartbeat principle, a CANopen node automatically and regularly sends a message containing its communication status as proof that the node is able to communicate. The interval between two heartbeat messages – the “heartbeat interval” – of a so-called heartbeat producer is configured via Object Directory item [1017]. A value of 0 disables the heartbeat mechanism. The so-called “Heartbeat Consumer Time” for up to 127 network nodes is specified in Object Directory entry [1016]. This time interval determines the maximum acceptable period until the receipt of a heartbeat message in the monitored node.
NodeGarding or Heartbeat message
In a NodeGarding or Heartbeat message, the communication status is transmitted in the form of a single-byte value:
The following values are defined for the node status:
| Value (hex) | Status |
|---|---|
| 0x00 | Boot-up |
| 0x04 | Stopped |
| 0x05 | Operational |
| 0x7F | Pre-operational |
The MSB has a special role – in Node Grading messages, it is used to toggle; this is the Toggle bit in the figure above. In Heartbeat messages, it must be set to 0 at all times; this is the Rsvrd in this figure. The node status message has particular significance during node start-up. This start-up message – the aforementioned “Bootup message” – is automatically transmitted by a CANopen node as soon as its state changes from “initialisation” status to the “pre-operational” state. This informs all existing nodes in a CANopen network of the presence of a new node.
In addition, a configuration node – the NMT master – is notified that it can begin configuring this node.
