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:

otransmit PDO (TPDO): PDO transmitted by the device

oreceive PDO (RPDO): PDO received by the device

Transmission Modes

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

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

oInhibit 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:

oEvent 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).

This table shows an example of values:

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:

oRead SDOs (download SDO)

oWrite 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 slave (bus coupler, for example) at regular time intervals, known as Guard Time. The slave responses with its NMT state. If the slave does not receive a poll after a defined period, called Lifetime, this slave 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 slaves.

When one of the two parameters Lifetime Factor or Guard Time is set to 0 (default configuration), the slave 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 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 slave may inadvertently transition to the state as configured in the object 1029H.

Monitoring is performed in the following way:

NOTE: Even if the monitoring function over time is disabled (Guard Time and Lifetime-Factor registers set to 0), the slave 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:

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:

oThe most significant bit is reserved and always has a value of 0

oThe 7 least significant bits provide the status for the device producing the Heartbeat message

The possible values are as follows: