CANopen is a communication protocol used for embedded systems in the automation of processes. As such, it can be used for networking within complex devices. This standard is composed of an addressing, several small communication protocols and an application layer which is defined by a device. The communication protocols support the network management, the device monitoring and the communication between different nodes. As a rule, the lower level of CANopen for implementing the data connection is the controller area network (CAN). However, devices based on other communication protocols (such as Ethernet, Powerlink, EtherCAT) also can handle the CANopen profile.

The CANopen devices and communication profiles are managed in the CiA 301 specification of “CAN in Automation”. The main distribution area is Europe, however it is also making advances in North America and Asia. Profiles for more specialized devices are built on this basic profile and are listed in many other standards that are published in “CAN in Automation”.

Device model

Every CANopen device must support certain standard functions in its software.

  • A communication unit implements the protocols for messages to the other nodes in the network.
  • The starting and resetting of the device take place via a controlled status control unit. It must include the states “initialization”, “pre-operational”, “the task itself”, and “stop”. The transitions between the states are established by network management (NMT).
  • The object directory is a field of variables with a 16 bit index. Furthermore, each variable can have an 8 bit subunit. The variables can be used to configure the device.
  • The application part carries out the actual application to be executed after the status control unit has granted the release. The application is defined by variables in the object directory and the data are transmitted and received via the communication layer.

Object directory

CANopen devices must have an object directory which is used for the configuration and communication with the device. An entry in the object directory is defined by:

  • Index: A 16-bit address of the object in the directory
  • Object name
  • Name: A character string describing the entry
  • Type: Specifies the data type of the variable (or the data type of all variables of an array)
  • Attribute variable: Provides information concerning access rights This can be read-and-write, read-only or write-only
  • Mandatory/Optional (M/O): Specifies whether the device can execute the required task according to the device specifications or not

Communication objects

The CAN bus, the physical basis of the CANopen can only transmit short packets. This is composed of an 11-bit ID, a remote transmission request (RTR) bit and 0 to 8 data bytes. The CANopen standard subdivides the 11-bit CAN ID into a 4-bit function code and a 7-bit node ID. This limits the number of devices in a CANopen network to 127. An expansion to the CAN bus standard CAN 2.0 B permits up to 29 bits, however in practice, CANopen networks are mostly large enough, so that the expanded ID range is only rarely required.

In CANopen, the 11 bit ID is known as the communication object identifier, COB-ID. In case of a transmission error, this permits the device with the smallest ID to transmit the data first and without a delay. As such, time-critical information should always be given a low code number.

Communication models

Different kinds of communication can be used in the transfer of messages between different devices.

  • In a maser/slave method, one node is defined as a master that requests data from a slave or which sends data to the slave. The NMT protocol is an example for master/slave communication.
  • A client/server relation is used in the SDO protocol, where the SDO client sends data to an SDO server that answers the requested data with one or more SDO packets.
  • A producer/consumer model is used with the “heartbeat and node guarding protocol”. In the push mode, the producer sends data to the consumer without a specific inquiry, while in the pull mode, the consumer requests the data from the producer.

Communication objects

The following communication services are available:

  • Network management objects (NMT) for controlling the status controller and for monitoring nodes.
  • Service data objects (SDO) for defining of object directory entries
  • Process data objects (PDO) for transmitting real-time data
  • Synchronization object (SYNC)
  • Time stamp and error message system (EMCY)

Electronic data sheets

CANopen devices require electronic data sheets (so-called EDS files) for their operation. These exist in a standardized text format which describes the most important object parameters and the physical parameters. This is used for example to define the supported baud rates. EDS files can be read with the aid of communication tools. This permits communication with the respective device. On the basis of this, a configuration can also take place. Freely available software can be used for checking for correct syntax.
Since 2007, an XML-based format has also been available. This XDD format is standardized in ISO 15745 and it permits a detailed description of the different functions of the devices. As such, the application is described independently of the protocol. A free editor is also available for this new XDD format.