Data transfer in CANopen is based on the standardised reading or writing of data, which is available in nodes in a standardised structure.
Object Dictionary (OD)
One of the most important features of CANopen is the standardised device description, known as the ‘Object Directory’ (OD). It is a database that has the same structure for all types of devices. This makes it possible to access all the important data, parameters and functions of a device from the “outside” – that is, via the CAN bus – using a logical addressing system. The address for an object in the OD consists of an index and a sub-index.
The OD does not only contain the application data that is (or can be) exchanged via CAN. The entire administration of a node is stored in the OD. This allows a Master to configure a node by adjusting the correct values in the OD.
In addition to the standardised description of devices’ communication properties in accordance with CiA 301, CANopen defines so-called “Device Profiles” for typical devices with distinct areas of application. These profiles specify the most important parameters, data and functions for each type of device. For example, there are profiles for I/O devices, motor drives and encoders. The profiles define the content of the OD in a standardised manner.
Electronic Data Sheet (EDS)
It should be clear that the contents of the OD are important to the Master. As an OD can be very large – it has a maximum of 65,000 indexes, each with 255 sub-indexes – it is impossible to exchange it with the Master via CAN. For this reason, a node’s OD is recorded in a so-called Electronic Data Sheet (EDS). This contains the data type and function of each item in the OD.
Originally, the EDS was an ASCII file. To enable more flexible and extensible processing of CANopen data, the format has been changed to XML.
Data transfer via SDO and PDO
In principle, there are two different ways to transfer data. The first, the Service Data Objects (SDO), is based on client/server communication. This involves direct addressing of a CANopen object within a node using the index and sub-index. This therefore always involves 1:1 communication, peer-to-peer between the client and the server. An SDO always consists of two (or more) messages. A read request is followed by the response. A write request is followed by the confirmation.
It is used, for example, for device configuration, ad hoc retrieval of information, or the uploading and downloading of larger data blocks.
The second method, Process Data Objects (PDO), enables the efficient transfer of CANopen data based on the producer/consumer model. This means that the data is received by all other nodes, provided they are configured accordingly. The data length is limited to a maximum of eight data bytes, but does not include any protocol overhead. A PDO can contain the values of more than one item from the Object Directory. The contents of a PDO must be defined during initialisation, and only for those nodes that will use the contents of that specific PDO.
In theory, each device can specify up to 512 Receive and Transmit PDOs. The actual maximum number depends on the limitations of the system (memory, processing power) or the network (number of available CAN-IDs).
A PDO is transmitted in response to a remote request (Remote Request), due to an internal event such as a trigger or a timer, or when a (cyclical) synchronous message (SYNC) is received. All CANopen nodes in the network are capable of receiving the message (PDO consumers). During initialisation, the Master determines which nodes will receive a specific PDO.
Emergency call
As CAN (and therefore CANopen) is not a hierarchical master/slave system, and the monitoring of nodes relates only to CAN communication and not to the actual node status, each node requires a high-priority CAN-ID to report fault conditions. This mechanism is referred to as “Emergency Messaging” and the associated communication object as “Emergency Message”. Such a CANopen emergency message consists of eight data bytes with the following format:
The fault codes are specified in the CANopen specification DS-301. Simultaneously with the transmission of the emergency call, the device also writes the fault code to the fault history. The fault register is part of the Object Directory with bit-by-bit encoding of the fault cause.
