CANopen Communication Model

CANopen mechanisms and services allow a standardized communication via the CAN-bus. The CAN in Automation (CiA) is responsible for the standardization. There are various types of CANopen standards:

• communication profiles specify fundamental CANopen mechanisms and services,

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

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

The CANopen Library from port provides communication profiles with interfaces to the user application.

Two CANopen services with different characteristics are dominating most automation networks and thus CANopen. These are the service for very quick messages for process data and the service for slower yet more flexible message for service data. Furthermore, CANopen defines an interface for accessing and storing data in a basic dictionary. All data and parameters of a device which shall be visible from the CAN bus or the application, can be reached via this object dictionary.

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 and therefore guarantees compatibility with existing older device profiles (e.g. DRIVECOM). Only the CANopen specific entries have no correlation with other profile definitions. The sub-index refers to the elements of complex data types e.g. arrays and records.

Table 1: organization of complex data types on the example of an object for the RS232 configuration

The following C-structure is the equivalent of the contents in Table 1.

typedef struct {
  UNSIGNED8   numberOfEntries;
  UNSIGNED16 baudRate;
  UNSIGNED8   numberOfDataBits;
  UNSIGNED8   numberOfStopBits;
  UNSIGNED8   parity;
} RS232_T;

The object dictionary is organized in different sections, see Table 2.

Table 2: structure of object dictionary

The communication profile area is used to configure the standardized communication services supported by a device. Objects in this area have a predefined meaning and will expect values according to the CiA standards.

The big address space in the manufacturer-specific area is totally under control of the device developer and can be used however he needs. It is often used to store application data or configuration that is unrelated to the CANopen functionality, but which shall be accessed via the CAN bus. In other words, this is the storage of (most of) the data that will be communicated using CANopen.

The object dictionary concept allows optional predefined device features which ensure a standardized behavior of certain device classes. These device profiles are standardized by the CiA and use objects in the standardized profile-specific area both for configuration and data storage. Multiple device profiles can be implemented at the same time.

Service data objects

Service data messages, in CANopen called Service Data Objects (SDO), are used to read and write all entries of the object dictionary of a device. Main usage of this type of messages is the device configuration. Besides reading and writing of the parameters and data, it is possible to download whole programs to the devices.

The SDO message contains information to address data in the device object dictionary and the data itself. Most existing profiles use 3 bytes to address objects, divided in two bytes for an index address and one byte for the sub-index address. Considering one byte for the protocol four bytes remain for parameter data. 

A basic SDO transfer consists of a CAN message to initiate and perform data transfer and a CAN message for handshake. Transfers of more than 4 Byte will use more than those 2 messages.

SDOs are typically transmitted asynchronously. The requirements towards transmission speed are not as high as for PDOs.

Figure 2: SDO communication principle

Figure 2 shows the communication between two devices. There are two variants for SDO usage. The first one is a write access and the second one is a read access to the SDO server object dictionary. 

The SDO client initiates a write service with a SDO write request. The SDO server indicates the message, writes the value to the object dictionary and gives a response to the CAN network. The client gets a confirmation of that service. 

At a read request the client initiates the SDO service. The SDO server indicates the message, reads the value from object dictionary and gives a response to the CAN network.  The client gets a confirmation message containing the data read. 

If it is necessary to transfer more than 4 bytes, e.g. arrays or files, a sequence of segmented messages will follow the initiate transfer message, each one acknowledged by the data server. See Figure 3 for the SDO protocol.

Figure 3: SDO protocol

The SDOs get low priority CAN identifiers. There are two SDO service types required for SDO communication. The first is the SDO server (SSDO), which cannot initiate a SDO service request. Instead they react to an SDO indication e.g. by writing or reading values to/from the local object dictionary. 

The COB-IDs for the first server SDO are pre-defined and must not be changed in order to ensure the connection to the device. The COB-IDs are built according to the following rules: