CANopen Explained - A Simple Intro [2022]
Need a simple, practical intro to CANopen?
In this guide we introduce the CANopen protocol basics incl. the object dictionary, services, SDO, PDO and master/slave nodes.
Note: CANopen can seem complex - so this tutorial is a visual intro in layman's terms.
Read on below to fully understand CANopen.
See also our CANopen intro video above - or get the PDF.
In this article
What is CANopen?
CANopen is a CAN based communication protocol.
The CANopen standard is useful as it enables off-the-shelf interoperability between devices (nodes) in e.g. industrial machinery. Further, it provides standard methods for configuring devices - also after installation.
CANopen was originally designed for motion-oriented machine control systems.
Today, CANopen is extensively used in motor control (stepper/servomotors) - but also a wide range of other applications:
Medical
X-ray generators, injectors, patient tables & dialysis devices
CANopen - higher layer protocol
The following is important to understand:
CANopen is a "higher layer protocol" based on CAN bus.
This means that CAN bus (ISO 11898) serves as the 'transport vehicle' (like a truck) for CANopen messages (like containers).
You can view CANopen from a 7-layer OSI model, see below.
The OSI model is a conceptual model standardizing communication functions across diverse communication technologies. Lower layers describe basic communication (e.g. raw bit streams), while higher layers describe things like segmentation of long messages and services like initiating, indicating, responding, and confirming of messages.
CAN bus represents the two lowest layers (1: Physical, 2: Data Link). This means that CAN simply enables the transmission of frames with an 11 bit CAN ID, a remote transmission (RTR) bit and 64 data bits (fields relevant to higher-layer protocols).
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.
It's worth noting, that CANopen could also be adapted to other data link layer protocols than CAN (e.g. EtherCAT, Modbus, Powerlink).
To fully understand CAN bus vs. CANopen, see also our CAN bus intro tutorial.
In this article we primarily focus on CANopen based on Classical CAN. However, it is worth noting that as CANopen FD.
Six core CANopen concepts
Even if you're familiar with CAN bus and e.g. J1939, CANopen adds a range of important new concepts:
Communication Models
There are 3 models for device/node communication: Master/slave, client/server and producer/consumer
Communication Protocols
Protocols are used in communication, e.g. configuring nodes (SDOs) or transmitting real-time data (PDOs)
DeviceStates
A device supports different states. A 'master' node can change state of a 'slave' node - e.g. resetting it
Object Dictionary
Each device has an OD with entries that specify e.g. the device config. It can be accessed via SDOs
Electronic Data Sheet
The EDS is a standard file format for OD entries - allowing e.g. service tools to update devices
Device Profiles
Standards describe e.g. I/O modules (CiA 401) and motion-control (CiA 402) for vendor independence
The below illustration shows how the CANopen concepts link together - and we will detail each 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. See below for a brief introduction:
Master/Slave
One node (e.g. the control interface) acts as application master or host controller. It sends/requests data from the slaves (e.g. the servo motors). This is used in e.g. diagnostics or state management. There can be 0-127 slaves in standard applications. Note that in a single CANopen network, there can be different host controllers sharing the same data link layer.
Service example: NMT
Client/Server
A client sends a data request to a server, which replies with the requested data. Used e.g. when an application master needs data from the OD of a slave. A read from a server is an "upload", while a write is a "download" (the terminology takes a "server side" perspective).
Service example: SDO
Consumer/Producer
Here, the producer node broadcasts data to the network, which is consumed by the consumer node. The producer either sends this data on request (pull model) or without a specific request (push model).
Service example: Heartbeat
As evident, the models are practically identical, but we distinguish between them for terminology consistency.
The CANopen frame
To understand CANopen communication, it is necessary to break down the CANopen CAN frame:
The 11-bit CAN ID is referred to as the Communication Object Identifier (COB-ID) and is split in two parts:
By default, 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 services (transmit PDO 3, transmit SDO, ...).
As such, the COB-ID details which node is sending/receiving data - and what service is used.
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:
CANopen COB-ID converter
Online CANopen COB-ID converter
Our COB-ID converter lets you quickly look up a CANopen COB-ID to return basic details incl. function code and node ID.
CANopen communication protocols/services
Below we briefly outline the 7 service types mentioned, incl. how they utilize the 8 CAN frame data bytes.
What is it? The NMT service is used for controlling the state of CANopen devices (e.g. pre-operational, operational, stopped) by means of NMT commands (e.g. start, stop, reset).
How does it work? To change state, the NMT master sends a 2-byte message with CAN ID 0 (i.e. function code 0 and node ID 0). All slave nodes 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. The node ID 0 indicates a broadcast command.
Possible commands include transition to operational (state 01), to stopped (state 02), pre-operational (state 80) as well as reset application (81) and reset communication (82).
What is it? The SYNC message is used e.g. to synchronize the sensing of inputs and actuation of several CANopen devices - typically triggered by the application master.
How does it work? The application master sends the SYNC message (COB ID 080) to the CANopen network (with or without SYNC counter). Multiple slave nodes may be configured to react to the SYNC and respond by transmitting input data captured at the very same time or by setting the output at the very same time as the nodes participating in the synchronous operation. Using the SYNC counter several groups of synchronously operating devices can be configured.
What is it? The emergency service is used in case a device experiences a fatal error (e.g. a sensor failure), allowing it to indicate this to 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.
What is it? With this communication service a global network time can be distributed. The TIME service contains a 6-byte date & time information.
How does it work? An application master sends out the TIME message with CAN 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.
What is it? The PDO service is used to transmit real-time data between devices - e.g. measured data such as position or command data such as torque requests. In this respect it is similar to e.g. broadcasted data parameters in J1939.
How does it work? We'll deep dive on this further below.
What is it? The SDO services are used to access/change values in the object dictionary of a CANopen device - e.g. when an application master needs to change certain configurations of a CANopen device.
How does it work? We'll deep dive on this further below.
What is it? The Heartbeat service has two purposes: To provide an 'alive' message and to confirm the NMT command.
How does it work? An NMT slave device periodically sends (e.g. every 100ms) the Heartbeat message (e.g. with CAN ID 705 for node 5) with the node's "state" in the 1st data byte
The "consumer" of the Heartbeat message (e.g. the NMT master and optionally any other device) then reacts if no message is received in a certain time limit.
The PDO and SDO services 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.
OD entries are looked up via a 16-bit index and 8-bit subindex. For example, index 1008 (subindex 0) of a CANopen-compliant node OD contains the node device name.
Specifically, an entry in the object dictionary is defined by attributes:
- Index: 16-bit base address of the object
- Object name: Manufacturer device name
- Object code: Array, variable, or record
- Data type: E.g. VISIBLE_STRING, or UNSIGNED32 or Record Name
- Access: rw (read/write), ro (read-only), wo (write-only)
- Category: Indicates if this parameter is mandatory/optional (M/O)
OD standardized sections
The object dictionary is split into standardized sections where some entries are mandatory and others are fully customizable.
Importantly, OD entries of a device (e.g. a slave) can be accessed by another device (e.g. a master) via CAN using e.g. SDOs.
For example, this might let an application master change whether a slave node logs data via a specific input sensor - or how often the slave sends a heartbeat.
Link to Electronic Data Sheet and Device Configuration File
To understand the OD, it is helpful to look at the 'human-readable form': The Electronic Data Sheet and Device Configuration File.
The Electronic Data Sheet (EDS)
In practice, configuring/managing complex CANopen networks will be done using adequate software tools.
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)
Assume a factory 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.
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.
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 CANopen SDO service comes into play.
SDO - configuring the CANopen network
What is the SDO service?
The SDO service allows a CANopen node to read/edit values of another node's object dictionary over the CAN network.
As mentioned under 'communication models', the CANopen SDO services utilize a "client/server" behavior.
Specifically, an SDO "client" initiates the communication with one dedicated SDO "server".
The purpose can be to update an OD entry (called an "SDO download") or read an entry ("SDO upload").
In simple master/slave networks, the node with NMT master functionality acts as the client for all NMT slave nodes reading or writing to their ODs.
Example: Client node SDO download
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, see above illustration). The SDO 'receive' (i.e. request) CAN frame looks as below:
- 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 contain 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 service?
The CANopen PDO service 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 service just do this?
Yes, in principle the SDO service 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 needs 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).
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 service.
The PDO is often seen as the most important CANopen protocol as it carries the bulk of information.
For PDOs, the consumer/producer terminology is used. Thus, a producer '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:
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 service a bit similar to J1939 PGNs & SPNs?
Yes, to some extent this is similar to how a specific J1939 parameter group (PG) 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 service.
For more details on PDOs, see this article (p. 5).
CANopen data logging - use case examples
Since CANopen is a CAN-based protocol, it is possible to record raw CANopen frames using a CAN bus data logger.
As an example, the CANedge lets you record CANopen data to an 8-32 GB SD card. Simply connect it to your application to start logging - and process the data via free software/APIs.
CANopen data loggerAs CANopen is based on CAN bus, you can store your CANopen decoding rules in the standardized CAN database format, a CAN DBC file. With this, you can directly decode your raw CANopen data in open source software/API tools for the CANedge, including the asammdf GUI, telematics dashboards and Python API tools.
Note that you may not have a CANopen DBC file readily available, but rather your CANopen frame decoding rules may be stored in your EDS/DCF or in a PDF. In such a case you can take outset in our DBC intro to learn how to construct a CANopen DBC file from scratch using various free editor tools.
Solutions like the CANedge enable several CANopen logging use cases:
Logging CANopen node data
Generally, logging CANopen data can be used to e.g. analyze operational data. WiFi CAN loggers can also be used for e.g. over-the-air SDOs
CANopen logger
Warehouse fleet management
CANopen is often used in EV forklifts/AGVs in warehouses, where monitoring e.g. SoC helps reduce breakdowns and improve battery life
warehouse telematics
Predictive maintenance
Industrial machinery can be monitored via IIoT CAN loggers in the cloud to predict and avoid breakdowns based on the CANopen data
predictive maintenance
Machinery diagnostic blackbox
A CAN logger can serve as a 'blackbox' for industrial machinery, providing data for e.g. disputes or rare issue diagnostics
can bus blackboxFor more intros, see our guides section - or download the 'Ultimate Guide' PDF.
Need to log/stream CANopen data?
Get your CAN logger today!
