CANopen is a communication protocol and device profile specification for embedded systems used in automation. The CANopen standard consists of an addressing scheme, several small communication protocols and an application layer defined by a device profile. The communication protocols have support for network management, device monitoring and communication between nodes, including a simple transport layer for message segmentation/desegmentation. The lower level protocol implementing the data link and physical layers is usually Controller Area Network (CAN), although devices using some other means of communication (such as Ethernet Powerlink, EtherCAT) can also implement the CANopen device profile.

EtherCAT provides the same communication mechanisms as in CANopen-Standard (CoE) : Object Dictionary, PDO Mapping (Process Data Objects) and SDO (Service Data Objects) and the network management is similar.

General principle

Every CANopen device has to implement certain standard features in its controlling software.

  • A communication unit implements the protocols for messaging with the other nodes in the network.
  • Starting and resetting the device is controlled via a state machine. It must contain the states Initialization, Pre-operational, Operational and Stopped. The transitions between states are made by issuing a network management (NMT) communication object to the device.
  • The object dictionary is an array of variables with a 16-bit index. Additionally, each variable can have an 8-bit subindex. The variables can be used to configure the device and reflect its environment, i.e. contain measurement data.
  • The application part of the device actually performs the desired function of the device, after the state machine is set to the operational state. The application is configured by variables in the object dictionary and the data are sent and received through the communication layer.

Object dictionary

One of the most important properties of CANopen is the provision of a standardized device description in the form of the so-called object dictionary.

This is based on a table (device object dictionary named OD), which has the same structure for all types of devices. With this it is possible to access all important data, parameters and functions of a device using a kind of logical addressing system (index, subindex) from the “outside”, i.e. via the CAN bus. Access to the OD is provided by means of the SDO protocol.

An entry in the object dictionary (OD object) is addressed via a (hexadecimal) index and can have up to 255 sub-entries (subindex). Sub-entries are normally used to combine values of the same type, such as with an array, or to access connected values, such as with a data record. An OD object therefore has a 24-bit address, made up of the 16-bit index and 8-bit subindex.

Behind every OD object there is a value, which can be read or written with the aid of a SDO transfer. With this a device can be configured and controlled, as an object dictionary entry can also directly represent a property or a function of the device (e.g. start-up of a drive). With read access to an object dictionary entry, the device returns the value of the entry. The data type and meaning of the value must be known to the enquirer. For this reason there is the electronic data sheet (EDS), which describes each object dictionary entry with address (main-/subindex), parameter name, data type, access type and default value.

For example, the standardized device communication parameters are mapped in the index range 0x1000–0x1FFF (“communication profile area”). The first few entries in this area are as follows:

Main index Object name Name Data type Access type
0x1000 variable device type DWORD ro
0x1001 variable error register BYTE ro
… … … … …
0x1008 variable device name string const
… … … … …
0x1010 array store parameters DWORD rw
… … … … …

With object dictionary entries that are data records or areas, there is a special feature on subindex 0, as this defines the subindex of the last valid element as a BYTE value - in most cases this value is synonymous with the number of elements. The elements themselves are provided in subindex1 to subindex <value of subindex 0>. Subindex 0 is particularly useful in the case of arrays of variable size, for example with PDO mapping.

Communication

Service Data Object protocol (SDO)

Specific communication objects, so-called service data objects (SDOs) are used for direct access to CANopen devices. With these “service data objects”, object dictionary entries can be read and written. As the data transfer is carried out via such a connection as an acknowledged service, this means that two CAN messages per connection are required: one message for the request (SDO request) and a second for the response (SDO response) of the node.

There is a logical connection between the two partners, which is also referred to as an “SDO channel”. Every device must support at least one server SDO channel. The initiative for an SDO transfer always originates from the client. As an SDO transfer is acknowledged, every request must be answered, even if the device is not able to provide meaningful data or the request itself was already erroneous. Such a negative response is called “abort”. In such a response, in addition to the 4-byte long error code (abort code), which specifies the cause of the abort, the address of the object dictionary entry to which the unsuccessful SDO transfer referred, is also transmitted. As already mentioned, an SDO transfer always runs as a request-response sequence according to a separate protocol, which is specified in the first data byte of the service data object. Therefore the message identifier specifies the SDO itself and the first data byte of the SDO specifies the specific protocol. For this reason the first data byte is also referred to as the protocol or command byte. An SDO-message is always eight bytes long, bits of the data field that are not required must be set to 0.

Data fields of any length or byte sequences can be transmitted with an object dictionary access. For this reason, the length of the information that can be transmitted via the SDO protocol is theoretically unlimited. The SDO protocol runs in two phases: In the initialization phase an object dictionary entry is addressed and the length of the data to be transferred is indicated. In the second phase the utility data are then transmitted in segments (each of seven bytes). Accordingly, standard distinguishes between four different SDO services: Initiate SDO Upload, Upload SDO Segment, Initiate SDO Download and Download SDO Segment. As very often only a few utility data bytes are to be transmitted, the SDO transfer can be shortened and up to a maximum of four bytes transmitted already in the initialization phase. This is referred to as an “expedited SDO transfer”.

Process Data exchange / Object protocol (PDO)

The main task of a CANopen system is of course the exchange of process data. For this, not only most of the CAN identifiers are provided but also most of the object dictionary entries. For the transmission of process data, this occurs without additional protocol overhead and transmission occurs according to the “producer-consumer principle”. This means that a message transmitted by a node (the “producer”) can be received by all other nodes (the “consumers”). This principle is also referred to as “broadcasting” and represents a very efficient principle of data transmission, especially if a message (e.g. a synchronization message) is to be transmitted at the same time to all process participants.

A CAN message that contains process data is called PDO (“Process Data Object”). As already described, transmission of PDOs is only possible in the “Operational” state. PDOs have no fixed format. The basic idea is that both the transmitter and the receiver know how the content of a PDO is to be interpreted. The PDO mapping describes which individual process variables in the data field of a PDO are transmitted, how they are arranged and which data type and length they have. Therefore the content and meaning of the data field of each defined PDO is described in the form of a PDO-mapping record inside the object dictionary both on the transmit and on the receive side.

The PDO producer composes the data field of a PDO in accordance with its TxPDO mapping. For this it takes the current data of the variables to be transmitted from its object dictionary and copies these into the data field of the PDO before the CAN message (PDO) is sent. The same happens on the consumer side: on the basis of the RxPDO mapping record, the data bytes of the received PDOs are copied into local object dictionary entries and thus generally device-specific actions are triggered (e.g. setting of digital outputs). A network node that wants to accept a certain PDO must only activate the coresponding CAN message.

But now back to PDO mapping. The principle of the arrangement (mapping) of process variables is shown in the following (the variables are available in the form of object dictionary entries in the application profile). The mapping of the individual process variables in the data field of a PDO is described in the form of a table. This is also given as an object dictionary entry, namely for every transmit- and receive-PDO in [16xx] or [1Axx]. These tables, and therefore the mapping of the process variables in the data field of a PDO can be configured via SDO write accesses.

In this example there are exactly two object links: from object (process variable) [2345sub67] of the PDO producer to object [5432sub10] of the PDO consumer and from object [6000sub01] of the producer to object [6200sub02] of the consumer. The third transmit object, [2001sub00] is not evaluated on the receiver side and is therefore covered up with a so-called dummy object.

The mapping tables are of data type “PDO mapping”, which contains in subindex 0 the number of mapped objects and in subindex 1 to 8 the mapped object dictionary entries themselves as DWORD. This contains the 24-bit long OD address (index, subindex) and the 8-bit coded length of the OD entry. A device that supports eight mapping entries has a granularity of 8 and can therefore only carry out “byte-wise mapping”. Devices with a granularity of 1, on the other hand, support mapping of each individual PDO bit (“bit-mapping”). Accordingly there must then be 64 entries in the mapping table.