CANopen protocol

CANopen is the internationally standardized (EN 50325-4) CAN-based higher-layer protocol for embedded control system, as developed and maintained by CiA members.. The set of CANopen specifications comprise the application layer and communication profile, as well as application, device, and interface profiles. CANopen provides very flexible configuration capabilities, and for this reason CANopen networks are used in a very broad range of application fields, such as machine control, medical devices, off-road and rail vehicles, maritime electronics, building automation, power generation, etc.

The CANopen protocol defines basically two aspects of the communication protocol: how the communication should be formatted (CANopen frame), and what objects are defined in common. Those objects may be used to configure or arbitrate the communication, or simply to exchange application data. Communication objects are available to:

  • Exchange process and service data.
  • Process or system time synchronization.
  • Error state supervision.
  • Control and monitoring of node states.

The following interactive figure depicts this:

CANopenProtOverView

For further information about the CANopen protocol, please refer to this link.

CANopen frame

CANopen protocol is based in CAN frames and uses one CAN frame for each CANopen message. There are two important parts of the frame that the user needs to modify: the arbitration field and the data field. The rest of the fields of the frame are normally automatically configured by the CAN hardware.

The CANopen protocol can work over other data link layer protocols. However, as it was designed based on the CAN specification, this document explain the CANopen message format over CAN.

For further information about CAN specification, please refer to the CAN section.

Arbitration field

In CANopen messages the identifier part of the arbitration field is known as Communication Object Identifier (COB-ID). It is divided into a 4-bit part function code and a 7-bit node-ID as depicted:

COB-ID description

Parallel to CAN, every node on a CANopen network must have a unique node-ID. The range of valid values comprises from 1 to 127. Zero is not allowed.

Similarly, the priority is determined by the COB-ID and RTR bits. As expected, the RTR bit on the arbitration field is used to request information from a remote node. In particular, it is used to implement the node guarding and TPDO request features, explained in the following chapters. With the exception of these two circumstances, the RTR bit is always set to zero.

The function code determines the communication object, which should be one of the allowed in CANopen. The final COB-ID of the object depends on the ID of which node receives or transmits the message, which allows to further establish priorities between nodes for the same function code.

In a master/slave communication, the messages could be divided into two groups, as shown in the following tables.

  • CANopen broadcast messages:

Communication Object

Function code (binary)

COB-IDs (hexadecimal)

NMT service

0000b

0x000

SYNC

0001b

0x080

  • CANopen peer-to-peer messages:

Communication Object

Function code (binary)

COB-ID (hexadecimal)

Range of valid COB-IDs (hexadecimal)

EMERGENCY

0001b

0x80 + Node ID

0x81 - 0x0FF

PDO1 (transmit)

0011b

0x180 + Node ID

 0x181 - 0x1FF

PDO1 (receive)

0100b

0x200 + Node ID

0x201 - 0x27F

PDO2 (transmit)

0101b

0x280 + Node ID

0x281 - 0x2FF

PDO2 (receive)

0110b

0x300 + Node ID

0x301 - 0x37F)

PDO3 (transmit)

0111b

0x380 + Node ID

0x381 - 0x3FF

PDO3 (receive)

1000b

0x400 + Node ID

0x401 - 0x47F

PDO4 (transmit)

1001b

0x480 + Node ID

0x481 - 0x4FF

PDO4 (receive)

1010b

0x500 + Node ID

0x501 - 0x57F

SDO (transmit)

1011b

0x580 + Node ID

0x581 - 0x5FF

SDO (receive)

1100b

0x600 + Node ID

0x601 - 0x67F

NMT error control

1110b

0x700 + Node ID

0x701 - 0x77F

Data field

The content of the data field depends on the CANopen message type. Detailed information about the CANopen message data is found under the appropriate object type in Communication objects.

Data is stored and transmitted in little endian format, which mean that least significant byte of the data is placed in the first position. For example, the number 0x15542612 would be represented as: