CANopen Transmission and Monitoring

Introduction

CANopen is an open industry-standard communication protocol and device profile specification (EN 50325-4) that is based on the Controller Area Network (CAN) protocol. The “Layer 7” protocol was developed for embedded networking applications and defines communication and device functions for CAN-based systems.

CANopen supports both cyclic and event driven communication, allowing you to reduce bus load to a minimum but still maintain short reaction times.

Process Data Object (PDO)

PDOs are objects which provide the communication interface with process data and enable them to be exchanged in real time. The set of PDOs on a CANopen device describes the implicit exchanges between this device and its communication partners on the network. The exchange of PDOs is authorized when the device is in ‘OPERATIONAL’ mode.

There are two types of PDOs:

Transmit PDO (TPDO): PDO transmitted by the device
Receive PDO (RPDO): PDO received by the device

Transmission Modes

The TM3 CANopen bus coupler supports three types of PDO transmission mode:

Transfer Code Type	Transmission Mode	Description
0	Acyclic - Synchronous	Send PDO on first SYNC message following an event
1-240	Cyclic - Synchronous	Send PDO every x SYNC messages, where x can be configured from 1 to 240
255 (Default)	Asynchronous	Send PDO on event

A further two options are associated with event-triggered PDOs:

Inhibit Time: The Inhibit Time utility is used to define a minimum time delay before transmission of a new PDO. This avoids overloading the bus where a significant number of events occur in rapid succession. The Inhibit Time is expressed in multiples of 100 μs.

This feature is available for Type 255 (Asynchronous) transfer.

This table shows an example of values:

Value (dec)	Timing (ms)
0	0
10	1
100	10
1000	100
10000	1000
65535	6553.5

Event Time: The Event Time is used to define an expiry time delay where transmission of a PDO will be forced, even if there has been no change in status. The Event Time is expressed in milliseconds.

This feature is available for Type 255 (Asynchronous) transfer.

This table shows an example of values:

Value (dec)	Timing (ms)
0	0 (deactivates timer)
10	10
100	100
1000	1000
10000	10000
65535	65535

Service Data Object (SDO)

An SDO allows a device's data to be accessed by using explicit requests. The SDO service is available when the device is in ‘OPERATIONAL’ or ‘PRE-OPERATIONAL’ state.

There are two types of SDO:

Read SDOs (download SDO)
Write SDOs (upload SDO)

The SDO protocol is based on a Client/Server model. For a Download SDO, the client (typically the controller) sends a request indicating the object to be read. The server (in this case the bus coupler) returns the data contained within the object. For an Upload SDO, the client (typically the controller) sends a request indicating the object to be written to and the desired value. After the object has been updated, the server (in this case the bus coupler) returns a confirmation message.

If an SDO is not processable by the server (bus coupler), the server returns an error code (Abort Code). This applies to both Download and Upload SDO. If the server does not respond within a pre-configured time period (SDO Timeout), the client will issue an SDO timeout abort code.

Error Control Protocols

Error control protocols are used to detect communication errors on the network. There are two protocols: node-guarding and heartbeat. These two monitoring mechanisms are especially important in the CANopen system. Devices connected to the bus do not regularly indicate their presence in operating mode, especially when commanded by Event.

NOTE: A CANopen device cannot support monitoring using both monitoring methods - Guarding and Heartbeat - concurrently. If both configurations are received by the device, it will only use the Heartbeat monitoring method.

Node Guarding

In this protocol, the NMT master (typically the controller) polls each NMT device (bus coupler, for example) at regular time intervals, known as Guard Time. The device responds with its NMT state. If the device does not receive a poll after a defined period, called Lifetime, this device transitions to the state as configured in the object 1029H, and generates a life guarding event. For the bus coupler, it transitions to the state as configured in the object 1029H (if object 1029H is left as default), fallback management is engaged, and guarding event is generated. Lifetime is defined as follow: Lifetime = Guard Time x Lifetime Factor. The object 100CH contains the guard time parameter expressed in milliseconds. The object 100DH contains the lifetime factor parameter. Guard Time and Lifetime can be configured differently for different devices.

When one of the two parameters Lifetime Factor or Guard Time is set to 0 (default configuration), the device does not perform monitoring. To activate monitoring over time, you must enter a value (minimum 2) in the object 100DH and specify a time in milliseconds in the object 100CH.

Typical values for the Guard Time parameter lie between 200 ms and 2 s.

In order to help maintain a more reliable and secure operation, you must enter a Lifetime Factor (object 100DH) with a value of 2 or greater. If a value of 1 is used, and should a delay occur due to the processing of high priority messages or internal processing on the node-guarding master, the device may inadvertently transition to the state as configured in the object 1029H.

WARNING
	UNINTENDED MACHINE OPERATION Set the Lifetime Factor (object 100DH) to a value no less than 2 when enabling Node Guarding. Failure to follow these instructions can result in death, serious injury, or equipment damage.

Monitoring is performed in the following way:

Phase	Description
1	The master sets Remote-Frames (or Remote-Transmit-Request request messages) on the Guarding-CobID of the devices to be monitored.
2	The devices concerned respond by sending the Guarding message. This message contains the Status-Code of the device and the Toggle-Bit, which changes after each message.
3	The NMT (Network Management Telegram) master compares the Status and Toggle-Bit information: if they are not in the expected state or if no response is received, the NMT master considers that an error has been detected on the device.

NOTE: Even if the monitoring function over time is disabled (Guard Time and Lifetime-Factor registers set to 0), the device responds to a remote request from the master. For the Guarding message, the initial value of the Toggle-Bit sent in the first Guarding message is 0. Then, the Toggle bit changes in each subsequent Guarding message, which makes it possible to indicate if a message has been lost.

The network state of the device is indicated in the seven remaining bits:

Network state	Response (hex)
‘STOPPED’	04H or 84H
‘PRE-OPERATIONAL’	7FH or FFH
‘OPERATIONAL’	05H or 85H

Heartbeat Mechanism

In this protocol, the producer transmits a Heartbeat message periodically, depending on the Producer Heartbeat Time parameter (in milliseconds) configured in object 1017H. Devices responsible for monitoring this message will have a Consumer Heartbeat Time parameter (in milliseconds), configured in object 1016H. If the producer Heartbeat message is not received within the configured time of the consumer devices, the devices generates a Heartbeat event. For the bus coupler, it transitions to the CANopen state as configured in the object 1029H, fallback management is engaged and Heartbeat event is generated.

The message Heartbeat indicates the device status on a byte, composing of:

The most significant bit is reserved and always has a value of 0
The 7 least significant bits provide the status for the device producing the Heartbeat message

The possible values are as follows:

Status of the Heartbeat Producer	Value (Decimal)
BOOT-UP	0
STOPPED	4
OPERATIONAL	5
PRE-OPERATIONAL	127