CANopen Diagnosis
The chapter describes the diagnosis options offered by the CANopen protocol.
CANopen State
A CANopen network consists of a NMT master (network management) and NMT slaves. In this case, the NMT master controls all devices and can change their communication states. A CANopen device is in one of four possible states:
Initialization: After switching on, the node passes through this state. At this time, the device application and the device communication (bit rate and node address) are initialized. Afterwards, the node switches independently to the "Pre-Operational" state.
Pre-Operational: Communication with the node is possible via SDOs. However, the node is not able to perform PDO communication.
Operational: The CANopen node is fully operational. It can independently send and receive process data.
Stopped: The node is completely separated from the network. No SDO or PDO communication is possible. The node can changed to another network state only by a corresponding network command (example: start node).
Error Register
According to CiA 301, each CANopen device has an error register (object 16#1001). This register can be read via SDO and in case of error provides additional information about the error.
Only bit 0 (generic error) is required in the error register. The other bits are optional and are not set by every slave. As soon as a device detects any error, at least bit 0 of this object is set.
Bit | Description |
|---|---|
0 | Generic error |
1 | Current |
2 | Voltage |
3 | Temperature |
4 | Communication error (overrun error state) |
5 | Device profile specific |
6 | Reserved (always 0) |
7 | Manufacturer-specific |
Emergency and Predefined Error Field (EMCY)
CANopen defines the optional emergency (EMCY) protocol to indicate errors. An emergency is a CAN message that is transmitted according to the predefined connection set with CAN-ID 16#80 + NODE-ID.
The telegram has the following structure:
The length of an emergency message is always 8 bytes. The respective emergency error code (EEC) is transmitted in the first two bytes. This is followed by the current value of error register 0x1011 (ER: error register) and 5 manufacturer-specific bytes (MEF: manufacturer-specific error field).
The respective interpretation of the error codes has to be taken from the manufacturer's manual. The emergency protocol is not supported by all slaves and has to be configured accordingly by the CANopen Manager.
The history of the occurred emergencies (error history) can be read from object 16#1003 via SDO. Here, subindex 0 contains the number of stored errors and the following subobjects contain the data contents of the transmitted emergencies.
Monitoring Mechanisms: Heartbeat and Node Guarding
Monitoring of a CAN node is required if it does not send messages continuously (cyclic PDOs). For this purpose the mechanisms 'heartbeat' and 'node guarding' are provided, which can be used alternatively.
Node guarding: With this protocol, messages (CAN remote frames) are sent by the NMT master to the existing CANopen slaves. The slaves have to respond to these messages within a specific time. If there is no response, then this is registered by the NMT master. Because CAN remote frames should be avoided in general, monitoring by means of heartbeat is preferable.
Heartbeat: The heartbeat protocol was released with CANopen version 4.0 and is the preferred monitoring method. Here, each node independently sends a message in cyclic intervals. This message can be monitored by any other subscriber in the network.