CANopen Explained - A Simple Intro (2018)

CANopen Explained Simple Intro Guide Dummies Tutorial

CANopen can be hard to understand:

Object dictionary? PDOs/SDOs? Master/Slave?

That’s why we’ve done a simple intro that truly explains the basics of CANopen for dummies - with lots of visual examples.

We’ll cover the core concepts in the easy-to-understand tutorial style you know from our intros to CAN bus, OBD2 and J1939.

Get ready to finally “get it”!


Before we jump into the technical stuff, let’s start with the basics:

What is CANopen used for?

Multiple examples of CANopen applications exist:

A few comments on the usage of CANopen:

  • CANopen was originally designed for motion-oriented machine control systems
  • The protocol is extensively used in motor control (e.g. stepper/servomotors)
  • In particular, it's core to many industrial automation networks
  • CANopen enables standardized plug & play installation of new devices in device networks
  • Further, it allows for flexible configuration - also after initial installation

Below we explain how CANopen relates to CAN bus.

Servo Motor CANopen Example Application

CANopen - a Higher Layer Protocol

Let’s start with a core point:

CANopen is a “higher layer protocol” - based on CAN bus.

This means that CAN bus (ISO 11898) serves as the “raw” basis for communication, while the CANopen standard specifies how the more “advanced” aspects work - for example various tools for communication.

More specifically, you can look at CANopen from a 7-layer OSI model (see illustration).

In short, the OSI model is a conceptual model standardizing communication functions across diverse protocols. Lower layers describe the very basic communication (e.g. raw bit streams), while higher layers describe things like APIs and data encoding - i.e. things closer to the user.

In CANopen, CAN bus represents the 2 lowest layers (1: Physical & 2: Data Link). This means that CAN simply enables the transmission of basic packages with an 11 bit CAN ID, a remote transmission (RTR) bit and 64 data bits.

In other words, CAN bus plays the same role in CANopen as it does in e.g. the J1939 protocol.

As evident above, CANopen implements the 7th layer of the OSI model (Application) via a set of standards. As part of this, it adds several important concepts that we detail below.

CANopen OSI Model Layer Application Data Link CAN Bus

Six Core CANopen Concepts

Even if you're familiar with CAN bus and e.g. J1939, CANopen adds a range of important new concepts:

The below illustration indicates how the CANopen concepts link together:

CANopen Overview Summary Model Communication Object Dictionary Application

We’ll explain the main concepts step-by-step below.

CANopen Communication Basics

In a CANopen network, several devices need to communicate.

For example, in an industrial automation setup you may have a robot arm with multiple servomotor nodes and a control interface/PC node.

To facilitate communication, three models exist within CANopen - each closely linked to the CANopen protocols that we look at shortly. The models are very similar so we won't deep-dive - but the overview can be helpful for terminology:

As evident, the models are practically identical, but we distinguish between them for terminology consistency.

Next, let’s look at the CANopen CAN frame:

CANopen CAN Frame COB ID

The 11-bit CAN ID is referred to as the Communication Object Identifier (COB-ID) and is split in two parts:
The first 4 bits equal a function code and the next 7 bits contain the node ID.

To understand how the COB-ID works, let’s take outset in the pre-defined allocation of identifiers used in simple CANopen networks (see the table).

Note: We'll refer to COB-IDs and Node IDs in HEX below.

As evident, the COB-IDs (e.g. 381, 581, …) are linked to the communication protocols (transmit PDO 3, transmit SDO, …).

As such, the COB-ID details which node is sending/receiving data - and what protocol is used.

CANopen COB ID Pre Defined Allocation Identifiers

Example: A CANopen device with node ID 5 would transmit an SDO via the 11-bit CAN ID 585.

This corresponds to a binary function code of 1011 and a node ID of 5 (binary: 0000101) - see the illustration.

SDO COB ID Example Transmit

If you need to quickly analyse a CANopen COB-IDs, use the below converter:

CANopen COB-ID Converter

Below we briefly outline the 7 protocol types mentioned, incl. how they utilize the 8 CAN frame data bytes.

CANopen Communication Protocols


Network Management (NMT)

What is it? The NMT protocol is used for changing the state of nodes (e.g. starting, stopping or resetting) and detecting error conditions.

How does it work? To change state, the NMT master node sends out a message with COB-ID 0 (i.e. function code 0 and node ID 0). All slave nodes receive and process this message. The 1st CAN data byte contains the requested state - while the 2nd CAN data byte contains the node ID of the targeted node:

NMT Network Management CAN Bus Data Frame ID

Possible states include Operational (01), Stopped (02), Pre-Operational (80), Reset (81) and Reset Communication (82).


Synchronization (SYNC)

What is it? The SYNC message is used e.g. to synchronize the transmitting of certain data from a range of nodes - typically triggered by the master.

How does it work? The master sends the SYNC message (COB ID 080) to the entire CANopen network (with empty data bytes). Multiple slave nodes may be configured to react to the SYNC and respond by transmitting e.g. operational data.


Emergency (EMCY)

What is it? The emergency protocol is used in case a node experiences a fatal error (e.g. a sensor failure), allowing it to warn the rest of the network.

How does it work? The affected node sends a single EMCY message (e.g. with COB-ID 085 for node 5) to the network with high priority. The data bytes contain information about the error, which can be looked up for details.


Timestamp (TIME) [PDO]

What is it? The timestamp protocol lets you configure a network-specific ‘time of day’, which will be received by all nodes.

How does it work? A master node sends out a CAN frame with COB-ID 100, where the initial 4 data bytes contain time in ms after midnight and the next 2 bytes contain the number of days since January 1, 1984.


Process Data Object [PDO]

What is it? The PDO protocol is used to transfer changing real-time data between nodes - e.g. sensor temperatures, arm positions, torque etc. In this respect it is similar to e.g. broadcasted data parameters in a J1939 application.

How does it work? We’ll deep dive on this further below.


Service Data Object [SDO]

What is it? The SDO protocol is used to access/change values in the object dictionary of a CANopen node - e.g. when a master node needs to change certain configurations of a slave node.

How does it work? We’ll deep dive on this further below.


Node Monitoring (Heartbeat) [SDO]

What is it? The Heartbeat protocol is used to evaluate if each node is able to communicate within the network.

How does it work? A slave node periodically (e.g. every 100ms) sends a CAN message (e.g. with COB-ID 705 for node 5) with the node’s “state” in the 1st data byte

The “consumer” of the heartbeat message (e.g. the master) then reacts if no message is received in a certain time limit (e.g. resetting the node).

The PDO and SDO protocols are particularly important as they form the basis for most CANopen communication.

Below we deep-dive on each of these - but first we need to introduce a core concept of CANopen:
The object dictionary.

CANopen Object Dictionary

All CANopen nodes must have an object dictionary (OD) - but what is it?

The object dictionary is a standardized structure containing all parameters describing the behavior of a CANopen node

All OD entries can be looked up using a 16-bit index and 8-bit subindex. For example, index 1008 (subindex 0) of a CANopen-compliant node’s OD contains the node's device name.

More specifically, an entry in the object dictionary is defined by:

  • A 16-bit index address of the object
  • The object type (e.g. array, variable, …)
  • A name describing the entry (e.g. Device Name)
  • A type, giving the datatype of the variable (or each variable in an array)
  • An attribute with access rights: rw (read/write), ro (read-only), wo (write-only)
  • An M/O field specifying if the object is mandatory/optional for the specification

The object dictionary is split into standardized sections in which some entries are mandatory, while others are fully customizable - see the table.

Importantly, OD entries of a device (e.g. a slave) can be accessed by another device (e.g. a master) via the CAN bus using the SDO or PDO protocol.

For example, this might let a master node change whether a slave node logs data via a specific input sensor - or how often the slave sends a heartbeat.

CANopen Object Dictionary Table

Note: The OD concept can be a bit confusing and high level - you're not alone!

To demystify it, it's helpful to look at the "human-readable form": The Electronic Data Sheet and the Device Configuration File:

Object Dictionary Electronic Data Sheet Device Configuration File

The Electronic Data Sheet (EDS)

In practice, configuring/managing a CANopen node or network can quickly get complex - and software tools are typically used.

To simplify this, the CiA 306 standard defines a human-readable (and machine friendly) INI file format, acting as a "template" for the OD of a device - e.g. the “ServoMotor3000”. This EDS is typically provided by the vendor and contains info on all device objects (but not values).

Device Configuration File (DCF)

Now “BigFactory” has bought a ServoMotor3000 to integrate into their conveyor belt. In doing so, the operator edits the device EDS and adds specific parameter values and/or changes the names of each object described in the EDS.

In doing so, the operator effectively creates what is known as a Device Configuration file (DCF). With this in place, the ServoMotor3000 is ready for integration into the specific CANopen network on-site.

EDS & DCF Example

Reviewing real EDS/DCF examples is one of the best ways to really understand the object dictionary of CANopen - see e.g. the difference between an EDS and DCF object entry below. We recommend checking out the CiA 306 standard to gain a deeper understanding of the OD, EDS and DCF with practical examples.

EDS DCF Example Difference Electronic Data Sheet

As mentioned, the DCF is typically created upon device integration. However, often it will be necessary to read and/or change the object values of a node after initial configuration - this is where the SDO protocol comes into play.

SDO - Configuring the CANopen Network

What is the SDO protocol?

The SDO protocol allows a CANopen node to read/edit values of another node’s object dictionary over the CAN bus

As mentioned under 'communication models', the SDO protocol utilizes the "client/server" terminology.

Specifically, an SDO "client" initiates access to the object dictionary of an SDO "server".

The purpose can be to update an OD entry (called an "SDO download") or read an entry ("SDO upload").

In most practical cases, the master node will act as the client to read/edit OD entries from slave nodes.

SDO Receive Transmit Example

Example: The client node can initiate an SDO download to node 5 by broadcasting below CAN frame - which will trigger node 5 (and be ignored by other nodes). The SDO 'receive' (i.e. request) CAN frame looks as below:

SDO Receive CAN Frame CCS Command Byte

There are a lot of variables in the SDO message - below we briefly explain them:

  • First, COB-ID 605 reflects the use of an ‘SDO receive’ (COB-ID 600 + node ID).
  • The CCS (client command specifier) is the transfer type (e.g. 1: Download, 2: Upload)
  • n is the #bytes in data bytes 4-7 that do not contain data (valid if e & s are set)
  • If set, e indicates an “expedited transfer” (all data is in a single CAN frame)
  • If set, s indicates that data size is shown in n
  • Index (16 bits) and subindex (8 bits) reflect the OD address to be accessed
  • Finally, bytes 4-7 contains the data to be downloaded to node 5

Once the CAN frame is sent by the master (client), the slave node 5 (server) responds via an ‘SDO transmit’ with COB-ID 585. The response contains the index/subindex and 4 empty data bytes. Naturally, if the client node requested an upload instead (i.e. reading data from the node 5 OD), node 5 would respond with the relevant data contained in bytes 4-7.

A few comments:

  • As evident, each SDO uses 2 identifiers, creating an “SDO channel”
  • The example is simplified as it’s “expedited” (data is contained in the 4 bytes)
  • For larger data scenarios, SDO segmentation/block transfers can be used

SDOs are flexible, but carry a lot of overhead - making them less ideal for real-time operational data.
This is where the PDO comes in.

PDO - Operating the CANopen Network

First of all: What is the CANopen PDO protocol?

The PDO protocol is used for effectively sharing real-time operational data across CANopen nodes

For example, the PDO would carry pressure data from a pressure transducer - or temperature data from a temperature sensor.

But wait: Can’t the SDO protocol just do this?

Yes, in principle the SDO protocol could be used for this. However, a single SDO response can only carry 4 data bytes due to overhead (command byte and OD addresses). Further, let’s say a master node needed two parameter values (e.g. "SensTemp2" and "Torque5") from Node 5 - to get this via SDO, it would require 4 full CAN frames (2 requests, 2 responses).

CANopen SDO vs PDO Protocol

In contrast, a PDO message can contain 8 full bytes of data - and it can contain multiple object parameter values within a single frame. Thus, what would require at least 4 frames with SDO could potentially be done with 1 frame in the PDO protocol.

The PDO is often seen as the most important CANopen protocol as it carries the bulk of information.

How does the PDO protocol work?

For PDOs, the consumer/producer model terminology is used. Thus, a slave ‘produces data’, which it transmits to a ‘consumer’ (master) using a transmit PDO (TPDO). Conversely, it may receive data from the consumer via a receive PDO (RPDO).

Producer nodes may e.g. be configured to respond to a SYNC trigger broadcasted by the consumer every 100 ms. Node 5 may then e.g. broadcast below transmit PDO with COB-ID 185:

CANopen PDO Message Frame Structure

Note how the data bytes are packed with 3 parameter values. These values reflect real-time data of specific OD entries of node 5. The nodes that use this information (the consumers) of course need to know how to interpret the PDO data bytes.

Isn’t the PDO protocol a bit similar to J1939 PGNs & SPNs?

Yes, to some extent this is similar to how a specific J1939 PGN will contain multiple SPNs/signals (aka data parameters) in the 8 data bytes. The J1939 CAN frame does not need to waste data bytes on “decoding” information because this is known by the relevant nodes (and by external tools via e.g. J1939 DBC files or the J1939 PDF standards). The wrinkle is that in CANopen, these “PDO mappings” are often configurable and can be changed during the creation of the DCF and/or via the SDO protocol.

For more details on PDOs, see this article (p. 5).

Logging CANopen Data

Since CANopen is based on CAN (ISO 11898), a CAN bus data logger can easily be connected to a CANopen node network to record all data traffic.

This has a number of applications - for example:

Check out our article below to learn more - incl. data from the awesome Rakka 3000!


Closing Remarks

We hope this has helped you get ready to log your CANopen data!

Check out our GUIDES section for more intros, guides & use cases.

Want to log data from your robotics, machinery or other CANopen application?
Then learn more about using the CLX000 CAN logger in CANopen applications below!

Liked this article? Please share!


We use cookies to improve our site (see our privacy policy)