Introduction to CANopen

CANopen services allow a standardized communication via the CAN-bus. CANopen networks can have up to 127 participants. The data content of a CAN message is limited to maximal 8 bytes by the CAN-bus. CANopen specifies the CAN bit rates 10 kbit/s, 20 kbit/s, 50 kbit/s, 125 kbit/s, 250 kbit/s, 500 kbit/s, 800 kbit/s and 1 Mbit/s. The CAN bit rate depends on the cable length. The CANopen network must be terminated at each end by a resistor of 120 Ohm.

The CAN in Automation (CiA) is responsible for the standardization. There are various types of CANopen standards:

• physical layer specifies the physical conditions for CANopen network participants

• communication profiles specify fundamental CANopen services,

• device profiles specify the usage of fundamental CANopen services and objects for special device classes

• application profiles specify the usage of fundamental CANopen services and objects and device profiles for special application systems

Each CANopen device can consist of up to 8 logical devices. Each logical device can use another device profile. Special functionalities of the device profile can be assigned to virtual devices.

Open

Figure 2: CANopen device model

CANopen provides various services based on different communication models:

• master/slave model,

• client/server model and

• producer/consumer model.

The most CANopen services are configurable via the CANopen network.

This chapter only gives an overview about the most used CANopen services. More detailed information is available in the CiA standards and in the user manual of the CANopen Library from port.

Object dictionary

All device parameters are stored in an object dictionary. This object dictionary contains the description, data type and structure of the parameters as well as the address composed of a 16‑bit index and an 8-bit sub-index. The object dictionary is organized in different sections:

Table 1: Structure of the object dictionary

Service Data Objects

Service Data Object (SDO) represents a CANopen service based on the client/server model. This service allows the access to all objects and is used for configuration purposes.

The transfer of object values requires some CANopen messages for objects that are larger than 4 bytes. In order to transfer different amounts of data the following mechanisms for SDOs are specified:

• expetited transfer for object sizes up to 4 bytes

• normal transfer, also called segmented transfer, for object sizes greater than 4 bytes with a confirmation of each CANopen message

• block transfer, for object sizes greater than 4 bytes only with a confirmation at the end of a sequence

• Errors that occurred during SDO communication are reported by the mechanism:

• SDO abort transfer

This service is configured via the SDO communication parameters.

Process Data Objects

Process Data Object (PDO) represents a CANopen service based on the producer/consumer model. This model allows the transmission of broadcast messages. This service is used for a quick exchange of process values between various devices in the CANopen network. PDOs can be transmitted:

• event-driven,

• synchronized or

• timer-driver.

The content of PDO messages is determined by the PDO mapping. The PDO mapping is specified in profile standards or can be set by the manufacturer. There are two types of PDO mapping:

• static PDO mapping: The PDO mapping is not changeable during runtime.

• dynamic PDO mapping: The PDO mapping can be configured during runtime.

This service is configured via the PDO communication and PDO mapping parameters.

Synchronization object

The Synchronization object (SYNC) represents a CANopen service based on the producer/consumer model. This service provides a basic network clock. This service is also used for synchronized PDOs.

This service can be configured via the objects 0x1005, 0x1006, 0x1007 and 0x1019.

Emergency object

The Emergency object represents a CANopen service based on the producer/consumer model. Error events can be reported via the Emergency object (EMCY) to other CANopen network participants, exactly to other Emergency consumers. Each Emergency message contains:

• an error code of data type UNSIGNED16,

• the value of object 0x1001 (error register) and

• the additional information.

The CiA standard CiA-301 specifies error classes for the error code. CiA profiles specify more detailed error codes additionally.

The additional information consists of 5 bytes, which can be used manufacturer-specific.

Object 0x1003 (pre-defined error field) offers the possibility to provide an error history about the object dictionary.

This service can be configured via the objects 0x1003, 0x1014 and 0x1015.

Network Management

The CANopen services are controlled by a Network Management (NMT) state machine:

Open

Figure 3: NMT state machine

The NMT service bases on the master/slave model. The NMT master controls the CANopen communication in the NMT slave devices.

Error Control events

CANopen provides two services for the communication monitoring:

• Heartbeat and

• Node Guarding.

Additional the NMT state of the monitored device can be checked.

Heartbeat represents a CANopen service based on the producer/consumer model. This service can be configured via the objects 0x1016 and 0x1017.

Node Guarding represents a CANopen service based on the master/slave model. This service can be configured via the objects 0x100C and 0x100D. This service is no longer recommended by the CiA because the service bases on RTR frames.

Pre-defined connection set

The CANopen services can be distinguished by the CAN-IDs of the CANopen messages. The CiA standard CiA-301 specifies the allocation of CAN-IDs to CANopen services. This allocation scheme is named pre-defined connection set.

The user can assign CAN-IDs for the CANopen services that are not specified by the pre-defined connection set. During reconfiguration of CAN-IDs the CAN-IDs shall be in the CAN-ID range of the CANopen service according to the pre-defined connection set. It is important to ensure that no restricted CAN-ID is used if CAN-IDs are configured. Table 2 lists all restricted CAN-IDs according to CiA-301.V4.2:

Table 2: Restricted CAN-IDs