What is CANopen bus communication protocol

The scope of this article is to understand the basics of the CANopen bus protocol; the object dictionary, services, SDO, PDO and master/slave nodes.

Posted Jul 18, 2025 Updated Jul 18, 2025

CANopen bus logo by CiA

By David Ampurua

17 min read

What is CANopen bus communication protocol

Table of contents
Definition
CANopen protocol on OSI model
Basic CANopen Device Model
Communication models
CANopen CAN frame
Communication objects: Communication protocols and services
Object Dictionary (OD)
- Electronic Data Sheet (EDS): Human-readable form of Object Dictionary (by CiA 306)
Cable connectors (by CiA 303-1)
CANopen history
CAN bus standard overview
References
Useful tools

Definition

CANopen is a CAN based communication protocol. It is a “Layer 7” CAN protocol that defines communication and device functions for CAN-based systems. Designed for very flexible configurable embedded networks. CANopen specifies the basic communication mechanisms and device profiles, but also application profiles with specific support for selected application fields.

Maintained by CAN in Automation (CiA) organization.

Mostly used in Automotive, factory automation, off-road vehicles, maritime electronics, medical equipment, and railways.

These are some of the core specs you should know about CANopen:

Max. Number of Nodes = 127
Baudrates [kBit/sec] = 10-1000
Node’s states
Process Data Object (PDO)
What is an Object Dictionary (OD) and an Electronic Data Sheet (EDS)
Little endian encoding = Multi-byte parameters are always sent LSB first

See an Transfer syntax for data type INTEGERn

octet number	1	2	3	4	5	6	7	8
INTEGER8	b7..b0
INTEGER16	b7..b0	b15..b8
INTEGER24	b7..b0	b15..b8	b23..b16
INTEGER32	b7..b0	b15..b8	b23..b16	b31..b24
INTEGER40	b7..b0	b15..b8	b23..b16	b31..b24	b39..b32
INTEGER48	b7..b0	b15..b8	b23..b16	b31..b24	b39..b32	b47..b40
INTEGER56	b7..b0	b15..b8	b23..b16	b31..b24	b39..b32	b47..b40	b55..b48
INTEGER64	b7..b0	b15..b8	b23..b16	b31..b24	b39..b32	b47..b40	b55..b48	b63..b56

CANopen protocol on OSI model

CANopen (CiA 301) only defines the application layer, based on CAN bus:

CANopen Application layer with CAN protocol layers in relation to the OSI model

CAN acts like a telephone line enabling communication, while CANopen is like the language spoken over that line.

Basic CANopen Device Model

A device is structured like the following:

Communication interface: This part sends and receives data over the network.
Object Dictionary: A list of all data items (information) that controls how the device works and communicates.
Application: The main function of the device for the interaction with the process environment.

Device Model

Communication models

On CANopen three different communication models are used. Each one closely linked to the CANopen communication protocols.

CANopen communication models

Master/Slave

One node (master) controls the communication by requesting or sending data to all other nodes (slaves). This setup is mostly used for tasks like diagnostics, configuration, or managing states. The system can include 0-127 slaves.

Protocol that use it: NMT.

Producer/Consumer

A producer node broadcasts data to the network to zero or more consumer(s). There are two options:

push model: The producer send data without been requested.
pull model: The producer send data by a consumer request.

Protocol that use it: PDO, HEARTBEAT, SYNC, TIME, EMCY.

Client/Server

A client send a request (upload/download) triggering the server to perform a certain task.

Upload: Client read from a server.
Download: Client write to a server.

Protocol that use it: SDO.

CANopen CAN frame

CANopen gives meaning to the arbitration part of a CAN frame and defines how to encode its data part.

CANopen data over CAN frame

The 11 bits of the CAN ID correspond to the CANopen COB-ID, which is divided into two parts: the first 4 bits are the function code, and the remaining 7 bits are the node ID.

See pre-defined COB-IDs used in CANopen.

Communication object	Function code [bin]	Node ID [bin (hex)]	Generic COB-ID [hex]	Resulting COB-ID [dec (hex)]	Communication Parameters at Index
NMT	0000	0	0h	0	-
SYNC	0001	0	80h	128 (80h)	1005h, 1006h, 1007h
TIME STAMP	0010	0	100h	256 (100h)	1012h, 1013h
EMERGENCY	0001	0000001 (1h) – 1111111(127h)	80h + Node ID	129 (81h) – 255 (FFh)	1014h, 1015h
TPDO1	0011	0000001 (1h) – 1111111(127h)	180h + Node ID	385 (181h) – 511 (1FFh)	1800h
RPDO1	0100	0000001 (1h) – 1111111(127h)	200h + Node ID	513 (201h) – 639 (27Fh)	1400h
TPDO2	0101	0000001 (1h) – 1111111(127h)	280h + Node ID	641 (281h) – 767 (2FFh)	1801h
RPDO2	0110	0000001 (1h) – 1111111(127h)	300h + Node ID	769 (301h) – 895 (37Fh)	1401h
TPDO3	0111	0000001 (1h) – 1111111(127h)	380h + Node ID	897 (381h) – 1023 (3FFh)	1802h
RPDO3	1000	0000001 (1h) – 1111111(127h)	400h + Node ID	1025 (401h) – 1151 (47Fh)	1402h
TPDO4	1001	0000001 (1h) – 1111111(127h)	480h + Node ID	1153 (481h) – 1279 (4FFh)	1803h
RPDO4	1010	0000001 (1h) – 1111111(127h)	500h + Node ID	1281 (501h) – 1407 (57Fh)	1403h
TSDO	1011	0000001 (1h) – 1111111(127h)	580h + Node ID	1409 (581h) – 1535 (5FFh)	1200h
RSDO	1100	0000001 (1h) – 1111111(127h)	600h + Node ID	1537 (601h) – 1663 (67Fh)	1200h
HEARTBEAT (NMT Error Control)	1110	0000001 (1h) – 1111111(127h)	700h + Node ID	1793 (701h) – 1919 (77Fh)	1016h, 1017h

Communication objects: Communication protocols and services

Process Data Object (PDO)

Used for real-time data transfer. PDO can contain 8 bytes of data and multiple object parameter values in a single frame.

‘Consumer/producer’ protocol is used and there are two kinds of PDO:

Transmit-PDO (TPDO) -> Node acts as producer
Receive-PDO (RPDO) -> Node acts as consumer

The following PDO transmission modes are distinguished:

Synchronous transmission (in response to a SYNC)
- Cyclic: Transmission is triggered periodically after every 1, 2 or up to 240 SYNC messages
- Acyclic: Synchronized with SYNC
Asynchronous
- Event-driven transmission (e.g. periodically, with an application event…)
- Remotely requested PDO (Legacy, no recommended)

CANopen PDO transmission modes

Data type and mapping of application objects into a PDO is determined by a corresponding default PDO mapping structure within the Object Dictionary (OD).

If variable PDO mapping is supported the configuration process is done by the SDO services to the corresponding objects of the OD.

Service Data Object (SDO)

Used to provide direct access to entries in a node’s object dictionary, allowing transfer of data of any size/type between a client and server.

Transfer Types:

Expedited: For small data sets (up to 4 bytes, fast single transfer during initialization), transfers the full payload in a single initialization/confirmation flow.
Segmented: First is an initialization/confirmation step an then data is sent as a sequence of smaller parts (7 bytes of data segments).
Block Transfer: For large data sets, groups segments into blocks (up to 127 segments per block) for faster transfer, with initialization and finalization/check phases.

sequenceDiagram
    Client->>Server: Initiate SDO expedited download (Request)
    Server-->>Client: Initiate SDO expedited download (Confirmation)
    Note over Client,Server: Can be download or upload
    Client->>Server: Initiate SDO expedited upload (Request)
    Server-->>Client: Initiate SDO expedited upload (Confirmation)

sequenceDiagram
    Client->>Server: Initiate SDO segmented download (Request)
    Server-->>Client: Initiate SDO segmented download (Confirmation)
    Client->>Server: SDO download segment 1
    Server-->>Client: SDO download segment (Confirmation)
    Client->>Server: SDO download segment 2
    Server-->>Client: SDO download segment (Confirmation)
    Note over Client,Server: After n segments | Where n_max = 7
    Client->>Server: SDO download segment 7 (End)
    Server-->>Client: Final SDO download segment (Confirmation)

    Note right of Server: Can be<br/>download or upload

sequenceDiagram
    Client->>Server: SDO block download initiate (Request)
    Server-->>Client: SDO block download initiate (Confirmation)
    Client->>Server: SDO block 1 download segment 1
    Note over Client,Server: After n segments | Where n_max = 127
    Client->>Server: SDO block 1 download segment 127
    Server-->>Client: SDO block download (Confirmation)
    Client->>Server: SDO block 2 download segment 1
    Note over Client,Server: After n segments
    Client->>Server: SDO block 2 download segment 127
    Server-->>Client: SDO block download (Confirmation)
    Note over Client,Server: After n blocks
    Client->>Server: SDO block n download segment 1
    Note over Client,Server: After n segments
    Client->>Server: SDO block n download segment 42
    Server-->>Client: SDO final block download (Confirmation)
    Client->>Server: SDO block download end (Request)
    Server-->>Client: SDO block download end (Confirmation)

    Note right of Server: Can be<br/>download or upload

CANopen generic Transmission-SDO frame example

All services are defined on CiA 301 section 7.2.4.2. To see every frames you can go here CANopen high-level protocol for CAN-bus

Special Protocols

Network Management (NMT)

Used to control the state of CANopen nodes. To request a state change, the NMT master sends a 2-byte message with COB-ID = 0: the first data byte specifies the desired state, and the second byte identifies the target node by its node ID.

Node ID = 0 indicates a broadcast command.

CANopen NMT frame example

Node states machine

CANopen node state machine

Synchronization Object (SYNC)

Periodically broadcasts a synchronization (SYNC) object that provides the basic network synchronization mechanism. Nodes that operate synchronously may use the SYNC object to synchronize their timing with the SYNC producer.

This synchronization is usually triggered by the application master.

The SYNC frame has the COB-ID = 080. And the data field may include a SYNC counter, used to explicitly associate the current SYNC cycle with PDO transmission.

Using the SYNC counter several groups of synchronously operating devices can be configured.

Time Stamp Object (TIME)

This function is used to provide global network time.

The frame has COB-ID = 100 and contains 6 data bytes: the first four bytes represent the time in milliseconds since midnight, and the next two bytes show the number of days since January 1, 1984.

Emergency Object (EMCY)

Used in case a device experiences a fatal error, sending broadcasts frame to indicate this to the rest of the network.

Take into account that the EMCY is optional.

See data bytes emergency error code classes.

Error code	Description
00xxh	Error reset or no error
10xxh	Generic error
20xxh	Current
21xxh	Current, CANopen device input side
22xxh	Current inside the CANopen device
23xxh	Current, CANopen device output side
30xxh	Voltage
31xxh	Mains voltage
32xxh	Voltage inside the CANopen device
33xxh	Output voltage
40xxh	Temperature
41xxh	Ambient temperature
42xxh	CANopen device temperature
50xxh	CANopen device hardware
60xxh	CANopen device software
61xxh	Internal software
62xxh	User software
63xxh	Data set
70xxh	Additional modules
80xxh	Monitoring
81xxh	Communication
82xxh	Protocol error
90xxh	External error
F0xxh	Additional functions
FFxxh	CANopen device sp

See data bytes emergency error codes.

Error code	Description
0000h	Error reset or no error
1000h	Generic error
2000h	Current – generic error
2100h	Current, CANopen device input side – generic
2200h	Current inside the CANopen device – generic
2300h	Current, CANopen device output side – generic
3000h	Voltage – generic error
3100h	Mains voltage – generic
3200h	Voltage inside the CANopen device – generic
3300h	Output voltage – generic
4000h	Temperature – generic error
4100h	Ambient temperature – generic
4200h	Device temperature – generic
5000h	CANopen device hardware – generic error
6000h	CANopen device software – generic error
6100h	Internal software – generic
6200h	User software – generic
6300h	Data set – generic
7000h	Additional modules – generic error
8000h	Monitoring – generic error
8100h	Communication – generic
8110h	CAN overrun (objects lost)
8120h	CAN in error passive mode
8130h	Life guard error or heartbeat error
8140h	recovered from bus off
8150h	CAN-ID collision
8200h	Protocol error - generic
8210h	PDO not processed due to length error
8220h	PDO length exceeded
8230h	DAM MPDO not processed, destinationobject not available
8240h	Unexpected SYNC data length
8250h	RPDO timeout
9000h	External error – generic error
F000h	Additional functions – generic error
FF00h	Device specific – generic error

NMT Error Control: Node Guarding and Heartbeat

To know nodes status, CANopen uses Node Guarding and Heartbeat to ensure devices are operational and to alert the system if communication fails. At least one mechanism is required for network reliability.

Node guarding

The NMT master periodically sends out guarding requests to each slave. If a slave device responds within a specified time window, it is considered healthy and connected.

Some systems support life guarding, allowing the slave to monitor if the master is still communicating. If not, the slave alerts its own local application.

NMT Node Guarding communication workflow

HEARTBEAT

In this system, devices assigned as heartbeat producers send out a special “heartbeat” broadcasts message at regular intervals and heartbeat consumers, listen for these messages.

NMT HEARTBEAT communication workflow

Object Dictionary (OD)

Attribute Description rw read and write access wo write only access ro read only access const read only access

Standardized structure that contain node’s all parameters describing its behavior. All nodes must have one. OD entries are looked up via a 16-bit index and 8-bit subindex.

Each entry is described by:

Index: 16-bit base address of the object
Object name: Manufacturer device name
Object code: Array, variable, record…
Data type: BOOL, UNSIGNED32, Record Name…
Access attributes: rw (read/write), ro (read-only), wo (write-only)…
Category: Indicates if this parameter is mandatory/optional (M/O)

See General Object dictionary index structure.

Index	Object
0000h	not used
0001h – 001Fh	Static data types (standard data types, e.g. Boolean, Integer16)
0020h – 003Fh	Complex data types (predefined structures composed of standard data types, e.g. PDOCommPar, SDOParameter)
0040h – 005Fh	Manufacturer-specific complex data types
0060h – 025Fh	Device profile specific data types
0260h – 0FFFh	reserved
1000h – 1FFFh	Communication profile area (e.g. Device Type, Error Register, Number of PDOs supported)
2000h – 5FFFh	Manufacturer-specific profile area
6000h – 9FFFh	Standardised Device Profile Area (e.g. "DSP-401 Device Profile for I/0 Modules" [3]: Read State 8 Input Lines, etc.)
A000h – BFFFh	Standardized network variable area
C000h – FFFFh	reserved

>Don't be confused by all the 'data types' located in the OD at indices below 0FFF; they're there mainly or definition purposes only. The relevant range of a node's OD lies between 1000 and 9FFF.

See Object dictionary objects definitions.

Object code	Object name	Definition
00h	NULL	An object with no data fields
02h	DOMAIN	Large variable amount of data (e.g.executable program code)
05h	DEFTYPE	Denotes a type definition such as a BOOLEAN, UNSIGNED16, FLOAT...
06h	DEFSTRUCT	Defines a new record type (e.g. the PDO mapping structure at 21h)
07h	VAR	Variable of a single data type (BOOL, UNSIGNED16, INTEGER8…)
08h	ARRAY	Array of variables of the same data type
09h	RECORD	Array of variables with different data types. Sub-index 0 has always data type UNSIGNED8 and conatins the number of elements

See Object dictionary data types.

Index	Object	Name
0001h	DEFTYPE	BOOLEAN
0002h	DEFTYPE	INTEGER8
0003h	DEFTYPE	INTEGER16
0004h	DEFTYPE	INTEGER32
0005h	DEFTYPE	UNSIGNED8
0006h	DEFTYPE	UNSIGNED16
0007h	DEFTYPE	UNSIGNED32
0008h	DEFTYPE	REAL32
0009h	DEFTYPE	VISIBLE_STRING
000Ah	DEFTYPE	OCTET_STRING
000Bh	DEFTYPE	UNICODE_STRING
000Ch	DEFTYPE	TIME_OF_DAY
000Dh	DEFTYPE	TIME_DIFFERENCE
000Eh	reserved
000Fh	DEFTYPE	DOMAIN
0010h	DEFTYPE	INTEGER24
0011h	DEFTYPE	REAL64
0012h	DEFTYPE	INTEGER40
0013h	DEFTYPE	INTEGER48
0014h	DEFTYPE	INTEGER56
0015h	DEFTYPE	INTEGER64
0016h	DEFTYPE	UNSIGNED24
0017h	reserved
0018h	DEFTYPE	UNSIGNED40
0019h	DEFTYPE	UNSIGNED48
001Ah	DEFTYPE	UNSIGNED56
001Bh	DEFTYPE	UNSIGNED64
001Ch – 001Fh	reserved
0020h	DEFSTRUCT	PDO_COMMUNICATION_PARAMETER
0021h	DEFSTRUCT	PDO_MAPPING
0022h	DEFSTRUCT	SDO_PARAMETER
0023h	DEFSTRUCT	IDENTITY
0024h – 003Fh	reserved
0040h – 005Fh	DEFSTRUCT	Manufacturer-specific Complex Data types
0060h – 007Fh	DEFTYPE	Device profile specific Standard Data types 1 st logical device

See Access attributes for data objects

Attribute	Description
rw	Read and write access
rww	An accessory definition of CiA 306 v1.2, read and write access to an object where writing affects directly a process output. Objects with this attribute can be mapped in a devices RPDO
rwr	An accessory definition of CiA 306 v1.2, read and write access to an object where reading reads a process input. Objects with this attribute can be mapped in a devices TPDO
wo	Write only access
ro	Read only access
const	Read only access, but the value is always the same, it's constant

Exaple of an PDO records specification

PDO communication parameter record ↴

Index	Sub-index	Name	Data type
0020h	00h	Highest sub-index supported	UNSIGNED8
	01h	COB-ID	UNSIGNED32
	02h	Transmission type	UNSIGNED8
	03h	Inhibit time	UNSIGNED16
	04h	reserved	UNSIGNED8
	05h	Event timer	UNSIGNED16
	06h	SYNC start value	UNSIGNED8

PDO mapping parameter record ↴

Index	Sub-index	Name	Data type
0021h	00h	Number of mapped objects in PDO	UNSIGNED8
	01h	1st object to be mapped	UNSIGNED32
	02h	2nd object to be mapped	UNSIGNED32
	…
	04h	2nd object to be mapped	UNSIGNED32

Electronic Data Sheet (EDS): Human-readable form of Object Dictionary (by CiA 306)

An INI file format, acting as the ‘template’ for the OD of a device and contains info on all device objects (PDOs, SDOs, specific objects defined in the device profiles…)

See an example of an EDS's one RPDO definition

```ini [...] [1402] ParameterName=Receive PDO Communication Parameter 2 ObjectType=0x9 SubNumber=4 [1402sub0] ParameterName=Number of entries ObjectType=0x7 DataType=0x0005 AccessType=ro DefaultValue=5 PDOMapping=0 LowLimit=0x02 HighLimit=0x05 [1402sub1] ParameterName=COB ID ObjectType=0x7 DataType=0x0007 AccessType=rw DefaultValue=0x400+$NODEID PDOMapping=0 LowLimit=0x00000001 HighLimit=0xFFFFFFFF [1402sub2] ParameterName=Transmission Type ObjectType=0x7 DataType=0x0005 AccessType=rw DefaultValue=1 PDOMapping=0 [1402sub5] ParameterName=Event Timer ObjectType=0x7 DataType=0x0006 AccessType=rw DefaultValue=0 PDOMapping=0 [...] [1602] ParameterName=Receive PDO Mapping Parameter 2 ObjectType=0x9 SubNumber=5 [1602sub0] ParameterName=Number of entries ObjectType=0x7 DataType=0x0005 AccessType=rw DefaultValue=4 PDOMapping=0 LowLimit=0 HighLimit=8 [1602sub1] ParameterName=PDO Mapping Entry ObjectType=0x7 DataType=0x0007 AccessType=rw DefaultValue=0x20000910 PDOMapping=0 [1602sub2] ParameterName=PDO Mapping Entry ObjectType=0x7 DataType=0x0007 AccessType=rw DefaultValue=0x20000a10 PDOMapping=0 [1602sub3] ParameterName=PDO Mapping Entry ObjectType=0x7 DataType=0x0007 AccessType=rw DefaultValue=0x20010110 PDOMapping=0 [1602sub4] ParameterName=PDO Mapping Entry ObjectType=0x7 DataType=0x0007 AccessType=rw DefaultValue=0x20010210 PDOMapping=0 [...] [2000] ParameterName=Reception Element 2 ObjectType=0x9 SubNumber=11 [2000sub0] ParameterName=NrOfObjects ObjectType=0x7 DataType=0x0005 AccessType=rww DefaultValue=10 PDOMapping=0 [...] [2000sub9] ParameterName=i_sp_lim_pow ObjectType=0x7 DataType=0x0006 AccessType=rww PDOMapping=1 [2000subA] ParameterName=i_sp_lim_pow_ef ObjectType=0x7 DataType=0x0006 AccessType=rww PDOMapping=1 [2001] ParameterName=Reception Element 3 ObjectType=0x9 SubNumber=11 [2001sub0] ParameterName=NrOfObjects ObjectType=0x7 DataType=0x0005 AccessType=rww DefaultValue=10 PDOMapping=0 [2001sub1] ParameterName=rcw_gen_10 ObjectType=0x7 DataType=0x0006 AccessType=rww PDOMapping=1 [2001sub2] ParameterName=rcw_gen_11 ObjectType=0x7 DataType=0x0006 AccessType=rww PDOMapping=1 [...] ```

Cable connectors (by CiA 303-1)

Despite CiA 303-1 list a lot of connector pin assignment for general and special purpose, here I am going to focus on DB9 connector, de facto standard for general purpose CAN bus.

D-SUB 9-pin connector pin assignment

CANopen history

gantt
    title CANopen bus history milestones
    dateFormat  YYYY-MM-DD
    axisFormat %Y
    todayMarker off

    CiA (CAN in Automation) founded                         :milestone, 1992-01-01, 0d
    CiA 301 v1.0, CAN Application Layer (CAL) protocol is released      :milestone, 1994-01-01, 0d
    The standard is given the name "CANopen"                :milestone, 1995-01-01, 0d
    CiA 401 released (device profiles for generic I/O modules)          :milestone, 1996-01-01, 0d
    CiA 402 released (device profiles for drives and motion control)    :milestone, 1997-01-01, 0d
    CiA 303-1 v1.0 released (connectors and cabling)        :milestone, 1999-01-01, 0d
    CANopen v4.01 internationally standardized (EN 50325-4) :milestone, 2002-01-01, 0d
    CiA 306 v1.3.0 released (EDS, DCF)                      :milestone, 2005-01-01, 0d
    CiA 1301 released (CANopen FD)                          :milestone, 2017-01-01, 0d
    CiA 510 released (mapping CANopen protocols to J1939)   :milestone, 2020-01-01, 0d

CAN bus standard overview

CiA develops and publishes technical documents. Specifications contain functional requirements and permissions to be implemented in hardware or software. These are the most important:

CiA 301: CANopen application layer and communication profile
CiA 302: CANopen additional application layer functions
CiA 303-1: Device and network design - Part 1: CANopen physical layer
CiA 305: CANopen layer setting services (LSS) and protocols
CiA 306: CANopen electronic data sheet (EDS)
CiA 401: CANopen profile for I/O devices
CiA 402: CANopen device profile for drives and motion control

References

CiA standard 301: CANopen application layer and communication profile
CANopen CC – The standardized embedded network
CANopen fundamentals
CANopen Explained - A Simple Intro
CANopen EDS File Explained - A Simple Intro
CANopen history
https://en.wikipedia.org/wiki/CANopen
https://atlas.web.cern.ch/Atlas/GROUPS/DAQTRIG/DCS/CANINFO/canproto.html
CANopen high-level protocol for CAN-bus

Useful tools

Field bus, Communication

what is can canopen

This post is licensed under CC BY 4.0 by the author.