Cloud Login
A sensor changes state, a drive needs a new setpoint, and a controller need to know what is happening without delay. This is where CANopen is used. It gives CAN-based networks a more structured way to handle device data, configuration, status and control. It adds object dictionaries, device profiles, PDOs, SDOs, network management, heartbeat monitoring and synchronization on top of CAN.
Need a simple, practical intro to CANopen?
In this guide we explain CANopen, incl. what it is, how it works on top of CAN, how it is different from J1939, and why concepts like object dictionaries, PDOs, SDOs, NMT and heartbeat messages are important.
CANopen is used in automation, machinery, medical equipment, maritime electronics, off-highway vehicles, lifts, robotics and other embedded control systems. It is normally used where different devices need to communicate in a predictable and structured way.
At AutoPi, we mostly work with vehicle data access, telematics and CAN data logging. But in CANopen-based projects, AutoPi hardware can also be used where CANopen traffic needs to be logged, monitored, forwarded or processed on the edge.
What is CANopen?
CANopen is a higher-layer protocol built on top of CAN.
CAN itself defines how frames are sent on the bus. It handles the physical communication, arbitration and error handling. But CAN does not define what the data means in the full system.
CANopen adds this structure.
It defines how devices are configured, addressed, monitored and controlled. It also defines common communication objects, device profiles, network management and a standard way to expose parameters through an object dictionary.
In simple terms:
- CAN: The bus and frame system that defines how messages are sent on the network.
- CANopen: The communication structure used on top of CAN to explain what the messages mean.
CANopen was developed for machine control and automation. Today it is used in many systems where embedded devices need to exchange control data in a reliable way.
Typical examples include:
- Motor drives: Used to control speed, torque, position and status feedback in motion systems.
- Sensors: Used to send measured values like position, pressure, temperature or distance to the network.
- I/O modules: Used to connect digital and analog inputs and outputs to the CANopen network.
- Hydraulic controllers: Used in mobile machines where valves, pumps and actuators need controlled communication.
- Medical equipment: Used where embedded devices need predictable communication and controlled device behaviour.
- Mobile machinery: Used in off-highway and special machines where several controllers must work together.
- Maritime systems: Used in marine electronics and control systems where robust communication is needed.
A key idea in CANopen is interoperability. A device exposes its parameters through an object dictionary. The device can also be described with an Electronic Data Sheet, or EDS file. This makes it easier for tools and controllers to understand how the device should be configured and used.
How CANopen works in practice
A CANopen device is normally an embedded device with CANopen communication software inside it. The actual device can be a drive, sensor, valve controller, I/O module or something else.
CANopen defines how this device should behave on the network.
One important part is the Network Management state machine, also called NMT. A CANopen node can normally be in one of these states:
- Initialization: The node starts up and prepare its communication.
- Pre-operational: The node can be configured, but process data is normally not running yet.
- Operational: The node exchange process data and works as part of the active network.
- Stopped: The node is stopped and only limited communication is normally possible.
During pre-operational state, the device is normally configured. This is often done through Service Data Objects, also called SDOs.
During operational state, the device normally exchange real-time process data. This is usually done through Process Data Objects, also called PDOs.
NMT messages are used by an NMT master to start, stop or reset nodes on the network. For example, the master can start a device after configuration is done.
Key CANopen concepts
CANopen adds several important concepts on top of CAN. These are the parts that makes CANopen more structured than using raw CAN frames alone.
Object dictionary: A structured table inside each CANopen node. It contains configuration parameters, device information, communication settings and process data.
PDOs: Process Data Objects. They are used for fast process data, like sensor values, status words, control words and drive setpoints.
SDOs: Service Data Objects. They are used to read and write entries in the object dictionary, normally for configuration and less time-critical data.
NMT: Network Management. It is used to control device states and reset nodes or communication.
EDS files: Electronic Data Sheets. These files describe the device, its object dictionary and the communication behaviour it supports.
CANopen, CAN bus and J1939 compared
CANopen is built on CAN. It is not built on J1939.
Both CANopen and J1939 use CAN as the base technology, but they are different higher-layer protocols. They are also normally used in different types of systems.
CANopen vs. CAN bus
CAN bus is the foundation. It defines how frames are transmitted, how arbitration works and how errors are handled at the bus level.
But raw CAN does not define device profiles, configuration objects or a common application model. The meaning of the CAN IDs and data bytes is normally project-specific.
CANopen adds a higher-layer structure. It defines communication objects, object dictionaries, device profiles, network management and a standard way to configure and monitor devices.
In practice, raw CAN is very flexible. CANopen is more structured. It is useful when devices from different vendors need to follow the same communication model.
CANopen vs. J1939
J1939 is also built on CAN. It is mainly used in heavy-duty vehicles, buses, agricultural machinery, construction equipment and marine engines.
J1939 is organized around PGNs, SPNs, source addresses and diagnostic messages.
CANopen is more common in automation and embedded control. It is organized around object dictionaries, PDOs, SDOs, device profiles and network management.
Both protocols are robust and widely used, but they solve different problems. J1939 is strong in heavy-duty vehicle communication. CANopen is strong in machine automation and configurable device networks.
| Feature | Raw CAN | CANopen | SAE J1939 |
|---|---|---|---|
| Base technology | CAN physical and data-link layers | Higher-layer protocol on CAN | Higher-layer protocol on CAN |
| Message structure | 11-bit or 29-bit CAN IDs defined by designer | 11-bit CAN IDs with function code and node ID in predefined ranges | 29-bit CAN IDs with PGN, priority, source address, and related fields |
| Data model | Project-specific | Object dictionary, PDOs, SDOs, device profiles | PGNs, SPNs, diagnostic messages, transport protocol |
| Typical domains | Custom embedded systems and ECU communication | Industrial automation, drives, robotics, medical devices, off-highway machinery | Trucks, buses, agricultural machinery, construction equipment, marine engines |
| Configuration | Defined by system designer | Object dictionary and EDS/device profiles | Standard PGNs/SPNs plus OEM-specific messages |
Develop with AutoPi
Use AutoPi hardware for vehicle data logging, CAN monitoring, edge processing and integration with cloud or custom backend systems.
What is the CANopen protocol?
The CANopen protocol defines a set of communication objects and rules used by CANopen devices.
The most common objects are:
- PDO: Used for real-time process data, like sensor values, control words and status feedback.
- SDO: Used for reading and writing configuration values in the object dictionary.
- NMT: Used for starting, stopping and resetting nodes on the network.
- SYNC: Used to synchronize communication between devices.
- EMCY: Used when a device need to report an internal error.
- TIME: Used for time information in CANopen systems that support it.
- Heartbeat: Used to check if a node is still present on the network.
Each CANopen message uses a CAN identifier. In CANopen this is often called a COB-ID.
In the default 11-bit identifier scheme, the COB-ID is normally built from a function code and a node ID. This gives CANopen a predictable message layout, which makes it easier to understand the network traffic.
CANopen supports both configuration traffic and real-time process data. Configuration is normally handled through SDOs. Time-critical process data is normally handled through PDOs.
Error handling and diagnostics are also part of the protocol. Emergency messages, called EMCY, can report internal device errors. Heartbeat messages help detect if nodes are still alive on the network.
Common CANopen communication objects
PDO: Process Data Object. Used for real-time input and output data.
SDO: Service Data Object. Used for reading and writing object dictionary entries.
NMT: Network Management. Used for controlling node states.
SYNC: Synchronization message. Used to coordinate synchronous PDO transmission.
EMCY: Emergency message. Used to report device-internal faults.
Heartbeat: Periodic status message. Used to monitor if nodes are still present.
LSS: Layer Setting Services. Used for configuration of node ID and bit rate in supported devices.
Basic principles of CANopen communication
CANopen uses different communication models depending on the task.
Some traffic is controlled by a master. Some traffic is client/server based. Other traffic is producer/consumer based.
Master/Slave
Used for Network Management. The NMT master can start, stop or reset nodes on the network.
Client/Server
Used by SDO communication. An SDO client reads from or writes to the object dictionary of an SDO server.
Producer/Consumer
Used for PDOs, heartbeat messages and similar traffic. One node produce data, and one or more nodes consume it.
These models make CANopen flexible. Configuration, real-time process data, status monitoring and synchronization are handled in different ways because they have different timing and reliability requirements.
How CANopen message format works
CANopen messages are carried in normal CAN frames. Most CANopen systems use 11-bit CAN identifiers.
The identifier layout in CANopen gives a clear relation between the message function and the node ID.
In the default identifier scheme, the COB-ID is based on a function code and a node ID. The node ID is 7 bits. This gives node IDs from 1 to 127. Node ID 0 is reserved for certain network management functions.
This structure makes it easier to see what type of message is being sent. For example, default SDO and PDO identifiers follow predictable ranges based on the node ID.
- COB-ID: The CAN identifier used for a CANopen communication object.
- Function code: Defines the type of CANopen message, such as PDO, SDO, NMT or heartbeat.
- Node ID: Identifies the device on the network.
- Payload: Contains the actual process data, configuration data or status information.
CANopen and the OSI model
CANopen is normally described as a higher-layer protocol on top of CAN. CAN provides the physical layer and the data link layer. CANopen defines the application-layer behaviour used by devices and tools.
In practical terms, CANopen specifies how devices are configured, how real-time process data is exchanged, how nodes are started and stopped, and how device status and errors are reported.
The most important CANopen specifications are maintained by CAN in Automation, also called CiA.
CiA 301 defines the CANopen application layer and communication profile. Device profiles such as CiA 401 and CiA 402 define behaviour for specific device classes, for example I/O modules and drives.
The CANopen application layer
The CANopen application layer is where the protocol becomes useful for real devices.
It defines how a drive, sensor, controller or I/O module exposes data and configuration to the network.
Object dictionary
The object dictionary is a structured table inside a CANopen device.
It contains communication parameters, configuration values, process data, diagnostics and device-specific objects.
Each entry has a 16-bit index and can have an 8-bit sub-index. This gives a consistent way to access parameters across different devices.
For example, a motor drive can expose control words, status words, velocity settings, acceleration limits, error registers and manufacturer-specific parameters through the object dictionary.
SDOs are used to read and write object dictionary entries. PDOs are used to send selected object dictionary values efficiently as process data.
Service Data Objects (SDO)
SDOs are used for configuration and parameter access. They are not normally used for fast cyclic process data.
An SDO client sends a request to an SDO server. The server responds with the requested value or confirms that a write operation has been done.
By default, an SDO client-to-server request uses 600h + Node ID, and the server-to-client response uses 580h + Node ID.
Small values can be transferred in one message using expedited transfer. Larger values can be transferred using segmented or block transfer, depending on what the device support.
Process Data Objects (PDO)
PDOs are used for real-time process data. They are efficient because they do not have the same request and response overhead as SDO communication.
A node can transmit a TPDO when data changes, at a fixed interval or after a SYNC message. Another node can receive the same data as an RPDO and use it directly in its application.
PDO configuration and mapping are stored in the object dictionary. Configuration defines when and how the PDO is sent. Mapping defines which object dictionary entries are included in the PDO payload.
PDOs are commonly used for drive control, sensor values, I/O states, valve commands and status feedback.
Using AutoPi with CANopen data
AutoPi devices can be used in projects where CANopen traffic needs to be observed, logged or forwarded.
The exact setup depends on the application, bus speed, connector, signal requirements and if the system uses standard CANopen profiles or manufacturer-specific objects.
Typical AutoPi-related use cases include:
- Logging PDO traffic: Capture real-time process data from devices on the CANopen network.
- Capturing raw CAN frames: Store the original CAN traffic for later decoding or troubleshooting.
- Monitoring device behaviour: Follow how devices behave over time and detect changes in status or operation.
- Forwarding selected data: Send useful CANopen data to a cloud platform or customer backend.
- Edge processing: Run local logic on the device before the data is sent further.
For CANopen development or troubleshooting, the important first steps are to identify the node IDs, bit rate, PDO mapping, EDS files and the object dictionary entries that are relevant.
When this is known, the data can be logged and processed in a more structured way.
The AutoPi CAN FD Pro can be used where high-volume CAN or CAN FD logging is required. The AutoPi TMU CM4 is useful when edge logic, Linux tooling or custom integrations are part of the project.
For CANopen projects, AutoPi can help with data access and integration. But the project should still be planned around the actual device profiles, EDS files and communication requirements of the network.
