Hubbry Logo
CANopenCANopenMain
Open search
CANopen
Community hub
CANopen
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
CANopen
CANopen
CANopen
View on Wikipedia
from Wikipedia

CANopen is a communication protocol stack and device profile specification for embedded systems used in automation. In terms of the OSI model, CANopen implements the layers above and including the network layer. The CANopen standard consists of an addressing scheme, several small communication protocols and an application layer defined by a device profile. The communication protocols have support for network management, device monitoring and communication between nodes, including a simple transport layer for message segmentation/desegmentation. The lower level protocol implementing the data link and physical layers is usually Controller Area Network (CAN), although devices using some other means of communication (such as Ethernet Powerlink, EtherCAT) can also implement the CANopen device profile.

The basic CANopen device and communication profiles are given in the CiA 301 specification released by CAN in Automation.[1] Profiles for more specialized devices are built on top of this basic profile, and are specified in numerous other standards released by CAN in Automation, such as CiA 401[2] for I/O-modules and CiA 402[3] for motion control.

Device model

[edit]

Every CANopen device has to implement certain standard features in its controlling software.

  • A communication unit implements the protocols for messaging with the other nodes in the network.
  • Starting and resetting the device is controlled via a state machine. It must contain the states Initialization, Pre-operational, Operational and Stopped. The transitions between states are made by issuing a network management (NMT) communication object to the device.
  • The object dictionary is an array of variables with a 16-bit index. Additionally, each variable can have an 8-bit subindex. The variables can be used to configure the device and reflect its environment, i.e. contain measurement data.
  • The application part of the device actually performs the desired function of the device, after the state machine is set to the operational state. The application is configured by variables in the object dictionary and the data are sent and received through the communication layer.

Object dictionary

[edit]

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

  • Index, the 16-bit address of the object in the dictionary
  • Object name (Object Type/Size), a symbolic type of the object in the entry, such as an array, record, or simple variable
  • Name, a string describing the entry
  • Type, gives the datatype of the variable (or the datatype of all variables of an array)
  • Attribute, which gives information on the access rights for this entry, this can be read/write, read-only or write-only
  • The Mandatory/Optional field (M/O) defines whether a device conforming to the device specification has to implement this object or not

The basic datatypes for object dictionary values such as booleans, integers and floats are defined in the standard (their size in bits is optionally stored in the related type definition, index range 0x0001–0x001F), as well as composite datatypes such as strings, arrays and records (defined in index range 0x0040–0x025F). The composite datatypes can be subindexed with an 8-bit index; the value in subindex 0 of an array or record indicates the number of elements in the data structure, and is of type UNSIGNED8.

For example, the device communication parameters, standardized in the basic device profile CiA 301[4] are mapped in the index range 0x1000–0x1FFF ("communication profile area"). The first few entries in this area are as follows:

Index Object name Name Type Attribute M/O
0x1000 VAR device type UNSIGNED32 ro M
0x1001 VAR error register UNSIGNED8 ro M
...
0x1008 VAR manufacturer device name Vis-String const O
...

Given suitable tools, the content of the object dictionary of a device, based on an electronic data sheet (EDS), can be customized to a device configuration file (DCF) to integrate the device into a specific CANopen network. According to CiA 306[5], the format of the EDS-file is the INI file format. There is an upcoming XML-style format, that is described in CiA 311[6].

Communication

[edit]

Communication objects

[edit]

CAN bus, the data link layer of CANopen, can only transmit short packages consisting of an 11-bit id, a remote transmission request (RTR) bit and 0 to 8 bytes of data. The CANopen standard divides the 11-bit CAN frame id into a 4-bit function code and 7-bit CANopen node ID. This limits the number of devices in a CANopen network to 127 (0 being reserved for broadcast). An extension to the CAN bus standard (CAN 2.0 B) allows extended frame ids of 29 bits, but in practice CANopen networks big enough to need the extended id range are rarely seen.

In CANopen the 11-bit id of a CAN-frame is known as communication object identifier, or COB-ID. In case of a transmission collision, the bus arbitration used in the CAN bus allows the frame with the smallest id to be transmitted first and without a delay. Using a low code number for time critical functions ensures the lowest possible delay.

Contents of a CANopen frame:

COB-ID RTR Data length Data
Length 11 bits 1 bit 4 bits 0-8 bytes

The data frame with an 11-bit identifier is also called "base frame format".

The default CAN-ID mapping sorts frames by attributing a function code (NMT, SYNC, EMCY, PDO, SDO...) to the first 4 bits, so that critical functions are given priority. This mapping can however be customized for special purposes (except for NMT and SDO, required for basic communication).

Function code Node ID
Length 4 bits 7 bits

The standard reserves certain CAN-IDs to network management and SDO transfers. Some function codes and CAN-IDs have to be mapped to standard functionality after device initialization, but can be configured for other uses later.

Predefined Connection Set[7]

[edit]

For simple network structures, CANopen supports a predefined allocation of message identifiers.

The transmit and receive directions are from the device's point of view. So a query to a device on the network would send a 0x600+nodeid and get back a 0x580+nodeid.[1]

Communication object COB-ID(s) hex Slave nodes Specification
NMT node control 000 Receive only CiA 301
Global failsafe command 001 ? CiA 304
Flying master 071 to 076 ? CiA 302-2
Indicate active interface 07F ? CiA 302-6
Sync 080 Receive only CiA 301
Emergency 080 + NodeID Transmit CiA 301
TimeStamp 100 Receive only CiA 301
Safety-relevant data objects 101 to 180 ? CiA 301
PDO 180 + NodeID
200 + NodeID
280 + NodeID
300 + NodeID
380 + NodeID
400 + NodeID
480 + NodeID
500 + NodeID		 1. Transmit PDO
1. Receive PDO
2. Transmit PDO
2. Receive PDO
3. Transmit PDO
3. Receive PDO
4. Transmit PDO
4. Receive PDO		 CiA 301
SDO 580 + NodeID
600 + NodeID		 Transmit
Receive		 CiA 301
Dynamic SDO request 6E0 ? CiA 302-5
Node claiming procedure 6E1 to 6E3 ? CiA 416-1
Node claiming procedure 6F0 to 6FF ? CiA 416-1
NMT node monitoring (node guarding/heartbeat) 700 + NodeID Transmit CiA 301
LSS 7E4
7E5		 Transmit
Receive		 CiA 305

Communication models

[edit]

Different kinds of communication models are used in the messaging between CANopen nodes.

In a master/slave relationship, one CANopen node is designated as the master, which sends or requests data from the slaves. The NMT protocol is an example of a master/slave communication model.

A client/server relationship is implemented in the SDO protocol, where the SDO client sends data (the object dictionary index and subindex) to an SDO server, which replies with one or more SDO packages containing the requested data (the contents of the object dictionary at the given index).

A producer/consumer model is used in the Heartbeat and Node Guarding protocols. In the push-model of producer/consumer, the producer sends data to the consumer without a specific request, whereas in the pull model, the consumer has to request the data from the producer.

Protocols

[edit]

Network management (NMT) protocols

[edit]

The NMT protocols are used to issue state machine change commands (e.g. to start and stop the devices), detect remote device bootups and error conditions.

The Module control protocol is used by the NMT master to change the state of the devices. The CAN-frame COB-ID of this protocol is always 0, meaning that it has a function code 0 and node ID 0, which means that every node in the network will process this message. The actual node ID, to which the command is meant to, is given in the data part of the message (at the second byte). This can also be 0, meaning that all the devices on the bus should go to the indicated state.

COB-ID Data Byte 0 Data Byte 1
0x000 Requested state Addressed node
NMT command code Meaning
0x01 Go to 'operational'
0x02 Go to 'stopped'
0x80 Go to 'pre-operational'
0x81 Go to 'reset node'
0x82 Go to 'reset communication'

The Heartbeat protocol is used to monitor the nodes in the network and verify that they are alive. A heartbeat producer (usually a slave device) periodically sends a message with the binary function code of 1110 and its node ID (COB-ID19 = 0x700 + node ID). The data part of the frame contains a byte indicating the node status. The heartbeat consumer reads these messages. If the messages fail to arrive within a certain time limit (defined in the object dictionary of the devices) the consumer can take action to, for example, reset the device or indicate an error. The frame format is:

COB-ID Data Byte 0
0x700 + node ID State
NMT state code Represented state
0x00 Boot up (Initialising)
0x04 Stopped
0x05 Operational
0x7f Pre-operational

CANopen devices are required to make the transition from the state Initializing to Pre-operational automatically during bootup. When this transition is made, a single heartbeat message is sent to the bus. This is the bootup protocol.

A response/reply-style (pull model) protocol, called node guarding, exists for slave monitoring.

Service Data Object (SDO) protocol

[edit]
Not to be confused with Service Data Objects, a data-as-a-service abstraction.

The SDO protocol is used for setting and for reading values from the object dictionary of a remote device. The device whose object dictionary is accessed is the SDO server and the device accessing the remote device is the SDO client. The communication is always initiated by the SDO client. In CANopen terminology, communication is viewed from the SDO server, so that a read from an object dictionary results in an SDO upload and a write to a dictionary entry is an SDO download.

Because the object dictionary values can be larger than the eight bytes limit of a CAN frame, the SDO protocol implements segmentation and desegmentation of longer messages. Actually, there are two of these protocols: SDO download/upload and SDO Block download/upload. The SDO block transfer is a newer addition to standard, which allows large amounts of data to be transferred with slightly less protocol overhead.

The COB-IDs of the respective SDO transfer messages from client to server and server to client can be set in the object dictionary. Up to 128 SDO servers can be set up in the object dictionary at addresses 0x1200 - 0x127F. Similarly, the SDO client connections of the device can be configured with variables at 0x1280 - 0x12FF. However the pre-defined connection set defines an SDO channel which can be used even just after bootup (in the Pre-operational state) to configure the device. The COB-IDs of this channel are 0x600 + node ID for receiving and 0x580 + node ID for transmitting.

To initiate a download, the SDO client sends the following data in a CAN message with the 'receive' COB-ID of the SDO channel.

Byte Nr: Byte 0 Byte 1-2 Byte 3 Byte 4-7
Length: 3 bits 1 bit 2 bits 1 bit 1 bit 2 bytes 1 byte 4 bytes
Meaning: ccs=1 reserved(=0) n e s index subindex data
  • ccs is the client command specifier of the SDO transfer, this is 0 for SDO segment download, 1 for initiating download, 2 for initiating upload, 3 for SDO segment upload, 4 for aborting an SDO transfer, 5 for SDO block upload and 6 for SDO block download
  • n is the number of bytes in the data part of the message which do not contain data, only valid if e and s are set
  • e, if set, indicates an expedited transfer, i.e. all data exchanged are contained within the message. If this bit is cleared then the message is a segmented transfer where the data does not fit into one message and multiple messages are used.
  • s, if set, indicates that the data size is specified in n (if e is set) or in the data part of the message
  • index is the object dictionary index of the data to be accessed, encoded in little endian
  • subindex is the subindex of the object dictionary variable
  • data contains the data to be uploaded in the case of an expedited transfer (e is set), or the size of the data to be uploaded (s is set, e is not set), often encoded in little endian

Process Data Object (PDO) protocol

[edit]

The Process Data Object protocol is used to process real time data among various nodes. You can transfer up to 8 bytes (64 bits) of data per one PDO either from or to the device. One PDO can contain multiple object dictionary entries and the objects within one PDO are configurable using the mapping and parameter object dictionary entries.

There are two kinds of PDOs: transmit and receive PDOs (TPDO and RPDO). The former is for data coming from the device (the device is a data producer) and the latter is for data going to the device (the device is a data consumer); that is, with RPDO you can send data to the device and with TPDO you can read data from the device. In the pre-defined connection set there are identifiers for four TPDOs and four RPDOs available. With configuration, 512 PDOs are possible.

PDOs can be sent synchronously or asynchronously. Synchronous PDOs are sent after the SYNC message whereas asynchronous messages are sent after internal or external trigger. For example, you can make a request to a device to transmit TPDO that contains data you need by sending an empty TPDO with the RTR flag (if the device is configured to accept TPDO requests).

With RPDOs you can, for example, start two devices simultaneously. You only need to map the same RPDO into two or more different devices and make sure those RPDOs are mapped with the same COB-ID.

Synchronization Object (SYNC) protocol

[edit]

The Sync-Producer provides the synchronization-signal for the Sync-Consumer. When the Sync-Consumer receive the signal they start carrying out their synchronous tasks.

In general, the fixing of the transmission time of synchronous PDO messages coupled with the periodicity of transmission of the Sync Object guarantees that sensor devices may arrange to sample process variables and that actuator devices may apply their actuation in a coordinated fashion.

The identifier of the Sync Object is available at index 1005h.

Time Stamp Object (TIME) protocol

[edit]

Usually the Time-Stamp object represents a time as a 6-byte field: a count of milliseconds after midnight (at most 27 bits, stored in a 32-bit field), and an unsigned 16-bit number of days since January 1, 1984. (This will overflow on 7 June 2163.)

Some time critical applications especially in large networks with reduced transmission rates require very accurate synchronization; it may be necessary to synchronize the local clocks with an accuracy in the order of microseconds. This is achieved by using the optional high resolution synchronization protocol which employs a special form of timestamp message to adjust the inevitable drift of the local clocks.

The high-resolution timestamp is encoded as unsigned32 with a resolution of 1 microsecond which means that the time counter restarts every 72 minutes. It is configured by mapping the high resolution time-stamp (object 1013h) into a PDO.

Emergency Object (EMCY) protocol

[edit]

Emergency messages are triggered by the occurrence of a device internal fatal error situation and are transmitted from the concerned application device to the other devices with high priority. This makes them suitable for interrupt type error alerts. An Emergency Telegram may be sent only once per ‘error event’, i.e. the emergency messages must not be repeated. As long as no new errors occur on a device no further emergency message must be sent. By means of CANopen Communication Profile defined emergency error codes, the error register and device specific additional information are specified in the device profiles.

Initialization

[edit]

Sample trace of communications between a master and two pressure transducer slaves configured for id 1 and node ID 2.

CAN ID DATA LENGTH DATA Description
0x0 2 01 00 Master puts all devices on the bus into operational mode
0x80 0 Master sends a SYNC message, which triggers devices to send data
0x181 4 CD 82 01 00 Node at ID 1 (CID-0x180), reading pressure of 0x0182CD (99021) pascals
0x182 4 E5 83 01 00 Node at ID 2 (CID-0x180), reading pressure of 0x0183E5 (99301) pascals

Electronic Data Sheet

[edit]

Electronic Data Sheet (EDS) is a file format, defined in CiA306, that describes the communication behaviour and the object dictionary entries of a device. This allows tools such as service tools, configuration tools, development tools, and others to handle the devices properly.

Those EDS files are mandatory for passing the CiA CANopen conformance test.

Since end of 2007 a new XML based format called XDD is defined in CiA311. XDD is conformant to ISO standard 15745.

Glossary of CANopen terms

[edit]
  • PDO: Process Data Object - Inputs and outputs. Values of type rotational speed, voltage, frequency, electric current, etc.
  • SDO: Service Data Object - Configuration settings, possibly node ID, baud rate, offset, gain, etc.
  • COB-ID: Communication object identifier
  • CAN ID: CAN Identifier. This is the 11-bit CAN message identifier which is at the beginning of every CAN message on the bus.
  • EDS: Electronic Data Sheet. This is an INI style or XML style formatted file.
  • DCF: Device Configuration File. This is a modified EDS file with settings for node ID and baud rate.

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

CANopen

View on Grokipedia
from Grokipedia
CANopen is a high-level communication protocol and network designed for embedded systems, built on the Controller Area Network (CAN) bus standard, which enables robust, real-time data exchange among devices in industrial and automation environments. It standardizes device and application profiles to facilitate interoperability, using communication objects such as Process Data Objects (PDOs) for time-critical cyclic data transmission and Service Data Objects (SDOs) for asynchronous configuration and diagnostics. The protocol supports data rates from 10 kbit/s to 1 Mbit/s, employs an object dictionary for parameter storage, and includes network management (NMT) states to control device operational modes like initialization, pre-operational, operational, and stopped. Developed initially in the early 1990s under the European Esprit project's ASPIC framework as a CAL-based profile for industrial systems, CANopen's first specification (CiA 301 version 1.0) was published by CAN in Automation (CiA) in November 1994, led by contributors including Bosch, Newcastle University, and Philips Medical Systems. By version 3.0 in 1996, it became product-ready, incorporating features like synchronous PDOs, emergency messaging, and heartbeat monitoring, evolving from early CAN remote frames for node guarding. Maintained by CiA, a nonprofit organization founded in 1992, CANopen has grown into a widely adopted standard, with numerous standardized device and application profiles enabling plug-and-play integration. Key to its architecture is the division into a CANopen for network communication, an object dictionary indexing parameters (e.g., 1000h–1FFFh for communication objects), and for device-specific functions, all layered atop CAN's ISO 11898 physical and layers supporting both 11-bit and 29-bit identifiers. This design unburdens developers from low-level hardware details, promoting flexibility in configurations like emergency handling and synchronization. CANopen finds applications in systems for high-precision drive synchronization, medical equipment, off-road vehicles, maritime electronics, railway controls, , and even flight data recording, where its real-time reliability and are critical. Its open standards, managed by CiA with input from global industry stakeholders, ensure broad vendor compatibility and ongoing enhancements, such as extensions for (CiA 304) and gateway functions.

Overview

Purpose and Scope

CANopen is a standardized higher-layer protocol and device profile specification built on the Controller Area Network (CAN), designed to facilitate real-time data exchange and interoperability among embedded devices in automation systems. It defines communication mechanisms, device functions, and application profiles to enable seamless integration of nodes from different manufacturers, particularly in industrial environments where reliable, deterministic messaging is essential. The scope of CANopen encompasses device modeling through standardized profiles, network management services for booting, configuring, and monitoring up to 127 nodes on a single bus, and application-layer services that support modular industrial control applications. It emphasizes flexibility in handling cyclic and event-driven data transmission while maintaining low overhead for real-time operations, making it suitable for fields such as machinery control, medical devices, and . Key benefits include deterministic communication achieved via synchronized messaging, plug-and-play enabled by predefined device profiles that ensure consistent behavior across vendors, and a fault-tolerant design incorporating error detection and emergency signaling to enhance system reliability in harsh environments. CANopen's layered architecture positions the atop the CAN physical and data-link layers, with the object dictionary serving as a central for device parameters and mappings, though detailed implementations are specified elsewhere.

History and Development

CANopen originated in the early 1990s as an application-layer protocol built upon the Controller Area Network (CAN) standard defined in ISO 11898, addressing the need for a flexible, standardized communication framework in industrial automation systems across . The CAN in Automation (CiA) , founded in March 1992 by six companies and two individuals to promote CAN-based technologies, initiated development of what would become CANopen in 1993 under the European Esprit project , led by Bosch and involving universities and manufacturers. This project focused on creating a CAL-based profile for production cells, which was handed over to CiA after completion. The first version of the CANopen specification, designated CiA 301 version 1.0, was published in November 1994, with a revised communications profile released in to define core device and application interfaces. Key milestones in CANopen's development occurred in the late and early , driven by the demand for interoperable embedded networks in machine control and . In June 2000, CiA released version 4.0.1 of the CiA 301 specification, standardizing the core and communication profile, which facilitated widespread adoption in industrial applications. This was followed by the expansion into device-specific profiles; for example, the CiA DS-401 profile for generic I/O modules was published in May 2002 (version 2.1), enabling consistent implementation of digital and analog inputs/outputs across devices. By the early , CANopen had become a dominant protocol in , supported by CiA's efforts to harmonize with international standards, such as its inclusion in EN 50325-4 in 2003. CANopen continued to evolve in the 2010s with the integration of CAN Flexible Data-rate (CAN FD), introduced in ISO 11898-1:2015, to support higher data rates and larger payloads. In September 2017, CiA published CiA 1301 version 1.0.0, defining the CANopen FD application layer and communication profile, which maps higher-layer protocols to CAN FD's enhanced data link layer while maintaining backward compatibility with classical CANopen. As of 2025, CiA's membership has grown from its initial eight founding participants in 1992 to 758 members, reflecting the protocol's expanding role in global automation. Recent advancements include ongoing enhancements to functional safety features, as discussed in CiA webinars in June 2025, and updates to the CANopen Lift profile, with the 23rd plugfest event held in May 2025 to test interoperability in elevator systems. These developments underscore CiA's commitment to adapting CANopen for modern requirements like higher performance and safety-critical applications in European industries.

Standards and Organization

CAN in Automation (CiA)

CAN in Automation (CiA) is a non-profit association founded in March 1992 in , , with the mission to provide an unbiased platform for developing and standardizing CAN-based higher-layer protocols, particularly for applications. As the international users' and manufacturers' group for the Controller Area Network (CAN), CiA fosters the adoption of CAN technology across industries by promoting and innovation. The organization is structured as a registered association governed by a , a , a Technical Committee (TC), and a Business Committee, with CiA GmbH handling administrative operations. As of November 2025, CiA has 760 member companies worldwide. It operates through specialized working groups coordinated by the TC, such as those focused on device profiles, , and protocol extensions like CANopen FD. CiA also hosts annual conferences, webinars, and member days, including 2025 sessions dedicated to CANopen FD advancements. CiA's primary activities include developing and maintaining technical specifications that cover all layers of CAN-based systems, from physical to application levels. It provides conformance certification for CANopen devices through rigorous testing at its lab, awarding a "Certified" logo to compliant products to assure quality and standards adherence. Additionally, CiA promotes education and knowledge sharing via seminars, free online resources on CAN protocols, and tools like electronic data sheets (EDS) for device integration. Through its efforts, CiA ensures seamless among CANopen devices from different vendors, reducing development costs and enhancing system reliability in industrial applications. The actively influences global standards by participating in ISO and IEC committees, notably contributing to ISO 11898 for CAN physical and data link layers and IEC 62026 for CANopen-based power drive systems.

Key Specifications and Profiles

The core specification for CANopen is defined in CiA 301, titled "CANopen and Communication Profile," which outlines the , communication protocols, and device model for CANopen networks. In its latest version 4.2.0, CiA 301 specifies the object dictionary structure, including communication parameters (indices 1000h to 1FFFh) and manufacturer-specific or standardized application data (2000h to 9FFFh), along with support for process data objects (PDOs), service data objects (SDOs), and . It also details communication objects (COB-IDs) for real-time data exchange, error reporting, and network control, with ranging from 10 kbit/s to 1 Mbit/s, and compatibility with both 11-bit and 29-bit CAN identifiers based on ISO 11898-1. CANopen device profiles extend CiA 301 by defining standardized objects, parameters, and behaviors for specific device types, ensuring across vendors. The base profile, integrated within CiA 301 as DS-301, establishes generic requirements for all CANopen devices, including mandatory PDO mappings, emergency objects, and diagnostic features in the object dictionary (indices 6000h to 9FFFh). For example, DS-401 (CiA 401) specifies profiles for generic I/O modules, mandating objects for digital and analog inputs/outputs, such as status monitoring and control via PDOs. Similarly, DS-402 (CiA 402) targets drives and devices, defining objects for velocity, position, and torque modes, including cyclic operation modes and time for synchronized motion. DS-404 (CiA 404) addresses measuring devices and closed-loop controllers, such as analog transducers with optional digital I/O, by standardizing transmission, parameters, and feedback loops through dedicated object dictionary entries. Additional specifications support implementation and verification. CiA 303 series covers aspects, including network design recommendations (Part 1) for bus lines, grounding, and shielding, as well as LED indicator patterns (Part 3) for device status visualization to aid . CiA 305, version 3.0.0, defines Layer Setting Services (LSS) protocols for dynamic configuration of node-IDs, , and node guarding without predefined addressing. is governed by CiA 310, which provides test plans and tools to verify device compliance with CiA 301 and profiles, ensuring reliable communication interfaces through automated checks of object dictionary and protocol behavior. Recent updates integrate CANopen with emerging technologies. CiA 1301, version 1.1.0, extends the for CANopen FD, supporting flexible data rates up to higher speeds, payloads up to 64 bytes per frame, and with classic CANopen via adjusted COB-IDs and bit timing for 40 MHz clocks. For safety-critical applications, CANopen Safety follows EN 50325-5 (formerly CiA 304), which provides the framework for safety-related communications using safety-related data objects (SRDOs) and black-channel transmission over CAN, achieving SIL 3 compliance per ; profiles like CiA 402-4 incorporate dedicated safety parameters. As of 2025, CiA continues refining these for enhanced in mobile machinery and automation.

Device Model

Object Dictionary

The Object Dictionary (OD) in CANopen serves as the central for devices, acting as an interface between the and the layers. It is a hierarchical that stores all device parameters, communication settings, and application data in a standardized format, enabling uniform access across the network. Each entry in the OD is addressed using a 16-bit index to identify the object and an 8-bit subindex to specify components within complex objects, allowing for up to 65,536 unique indices and 256 subindices per index. This structure ensures that devices can be configured and monitored consistently, regardless of the underlying hardware. The OD organizes entries as simple variables (e.g., Booleans, integers, or floating-point numbers) or as complex types such as arrays and , with supported data types including basic ones like , UNSIGNED8 to UNSIGNED64, INTEGER8 to INTEGER64, REAL32, REAL64, and specialized types like VISIBLE_STRING, TIME_OF_DAY, and DOMAIN for blocks. Access to these entries is governed by attributes such as read-only (RO), read/write (RW), write-only (WO), or constant (CONST, modifiable only during device initialization), which define permissions for network access and local modifications. Default values for OD entries are specified by device profiles or manufacturers and are typically loaded during the device's boot-up to establish initial operational states. The OD is divided into distinct areas based on index ranges to separate concerns: indices 0x0000 to 0x0FFF are reserved for definitions (RO); 0x1000 to 0x1FFF cover communication parameters, including SDO server objects at 0x1200 to 0x127F (defining server parameters like client/server COB-IDs) and PDO communication parameters at 0x1400 to 0x17FF for receive PDOs (RPDOs) and 0x1800 to 0x1BFF for transmit PDOs (TPDOs); indices 0x2000 to 0x5FFF are allocated for manufacturer-specific parameters, such as custom device identifiers or proprietary settings (e.g., a manufacturer-defined node ID configuration starting at 0x2000); and 0x6000 to 0x9FFF host standardized application objects per device profiles. Higher ranges like 0xE000 to 0xFFFF are reserved for future extensions. These divisions facilitate , where communication setup is isolated from application data. In CANopen networks, the OD plays a pivotal role in enabling uniform device configuration, diagnostics, and data exchange by providing a consistent addressing scheme that supports dynamic updates through mechanisms like SDOs, while PDO mappings reference OD entries for efficient real-time communication. This abstraction allows higher-layer applications to interact with devices without knowledge of low-level CAN details, promoting among diverse nodes.

Node Architecture and Profiles

A CANopen node is architected with a layered comprising hardware and software elements that facilitate standardized communication and application interfacing. At the hardware level, the node includes a CAN controller, which manages the physical transmission and reception of CAN frames over the network. The software architecture consists of three primary logical components: the CANopen , the object , and the . The processes incoming and outgoing messages, implementing handlers for core services such as (NMT) in master or slave mode, Service Data Objects (SDO) for configuration, and Process Data Objects (PDO) for real-time data exchange. The object serves as the central mechanism, holding communication parameters and application-specific objects accessible by both the stack and the application. The interfaces with the object's to control hardware, enabling device-specific functionality while adhering to CANopen standards. CANopen profiles define standardized behaviors and object mappings to ensure across devices. The generic profile, specified in CiA DS-301, provides the foundational communication and for basic nodes, mandating a core set of objects for network participation and data handling. Specialized profiles build upon DS-301; for instance, CiA DS-402 targets drives and applications, defining mandatory objects for , position, and torque modes to standardize servo drives, frequency inverters, and stepper motors. These profiles promote plug-and-play integration by requiring vendors to implement specific object dictionary entries, allowing diverse devices to communicate seamlessly without custom adaptations. In a typical CANopen network, nodes assume master or slave roles to manage configuration and operation. The NMT master node oversees network startup, state transitions, and monitoring of slave nodes, using NMT commands to set slaves to operational, pre-operational, or stopped states. Slaves execute application tasks under master direction, responding to configuration via SDO uploads and downloads for parameter setting. While the supports a master-slave hierarchy for centralized control, communication is optional through PDO mappings, enabling direct data exchange between nodes without master intervention. Implementation of CANopen nodes often relies on commercial or open-source protocol stacks from specialized vendors, which abstract the low-level details for developers. Vendors such as MicroControl and port provide ANSI-C based stacks compliant with CiA DS-301, supporting both master and slave functionalities with optimized resource usage for embedded systems. These stacks include modular components for NMT, SDO, and PDO handling, interfacing directly with the object dictionary for application integration. To verify compliance, nodes undergo CiA certification testing, which assesses adherence to profile specifications and ensures reliable in industrial environments.

Communication Fundamentals

Frame Structure and Objects

CANopen employs the frame format of the Controller Area Network (CAN) protocol, utilizing the 11-bit identifier from CAN 2.0A as the standard, with optional support for the 29-bit extended identifier from CAN 2.0B. The CAN identifier in CANopen frames is designated as the Communication Object Identifier (COB-ID), an 11-bit value spanning 0x000 to 0x7FF that encodes both the message function and the node address. The COB-ID structure allocates bits 10–7 for a 4-bit function code (0–15) and bits 6–0 for a 7-bit node ID (0–127), enabling unique identification of up to 128 nodes per function. For example, the COB-ID for the first Transmit Process Data Object (TPDO1) is formed as 0x180 plus the node ID, resulting in values from 0x180 (for node 0, typically reserved) to 0x1FF. Each frame features an 8-byte data field, with the Data Length Code (DLC) indicating the actual length (0–8 bytes). The Remote Transmission Request (RTR) bit signals request frames, while priority is managed through CAN arbitration, where the lowest COB-ID value wins access to the bus, ensuring deterministic behavior for time-critical messages.
Bit PositionsFieldDescription
10–7Function CodeIdentifies the type of communication object (e.g., 0x2 for TPDO1).
6–0Node IDSpecifies the sending or receiving node (0–127).
Communication objects transmitted via these frames fall into categories such as data objects—including Process Data Objects (PDOs) for real-time process variables and Service Data Objects (SDOs) for dictionary access—control objects like (NMT) for state control and (SYNC) for timing alignment, and status objects such as (EMCY) for error reporting and Heartbeat for node monitoring. These categories are distinguished by their assigned function codes within the COB-ID, with predefined codes ensuring standardized across devices. COB-IDs are mapped to specific entries in the device's Object Dictionary, a centralized where like the TPDO1 COB-ID reside at index 0x1400h as a 32-bit value (with the 11-bit ID in the lower bits and control flags in the upper bits). To prevent COB-ID collisions, devices assign unique node IDs during network configuration, and the valid bit (bit 31) in the COB-ID disables transmission if set, while inhibit times (stored in the dictionary, e.g., at 0x1803h for TPDO1) enforce minimum intervals between periodic transmissions to avoid bus saturation.

Predefined Connection Set

The Predefined Connection Set in CANopen defines a standardized allocation of 11-bit Communication Object Identifiers (COB-IDs) for essential communication objects, enabling default among devices on the network without prior configuration.CiA 301 This set is specified in the CANopen and communication profile, distinguishing between broadcast COB-IDs for network-wide messages and COB-IDs that incorporate the node ID (1 to 127) for device-specific addressing.CiA 301 The purpose is to provide a predictable framework for core functions like , , error reporting, and data exchange, reducing setup complexity in simple networks.CiA 301 Broadcast COB-IDs are fixed and do not include node-specific addressing. The Network Management (NMT) object uses COB-ID 0x000 for commands affecting all nodes.CiA 301 The (SYNC) object is assigned 0x080, allowing periodic broadcasting for time-coordinated operations across the bus.CiA 301 COB-IDs are calculated by adding the node ID to a base value, ensuring unique identification for each device. The (EMCY) object, used for error reporting, employs 0x080 + Node ID.CiA 301 Process Data Objects (PDOs) support up to four transmit (TPDO) and four receive (RPDO) mappings per node, with defaults as follows: TPDO1 at 0x180 + Node ID, RPDO1 at 0x200 + Node ID, TPDO2 at 0x280 + Node ID, RPDO2 at 0x300 + Node ID, TPDO3 at 0x380 + Node ID, RPDO3 at 0x400 + Node ID, TPDO4 at 0x480 + Node ID, and RPDO4 at 0x500 + Node ID.CiA 301 Service Data Objects (SDOs), for configuration and diagnostics, use 0x600 + Node ID for client requests (to the server) and 0x580 + Node ID for server responses (to the client).CiA 301 The Heartbeat or Node Guarding message for error control is at 0x700 + Node ID.CiA 301
Object TypeCOB-ID (Broadcast)COB-ID (Peer-to-Peer, + Node ID)
NMT0x000N/A (broadcast only)
SYNC0x080N/A (broadcast only)
EMCYN/A0x080
TPDO1N/A0x180
RPDO1N/A0x200
TPDO2N/A0x280
RPDO2N/A0x300
TPDO3N/A0x380
RPDO3N/A0x400
TPDO4N/A0x480
RPDO4N/A0x500
SDO ClientN/A0x600 (request)
SDO ServerN/A0x580 (response)
HeartbeatN/A0x700
These COB-IDs are stored as 32-bit values in the Object Dictionary (e.g., at indices 0x1400h for RPDO1 COB-ID, 0x1800h for TPDO1), where the lower 11 bits represent the identifier.CiA 301 To invalidate an entry—such as disabling a PDO or SDO—the 31st bit (corresponding to 0x80000000) is set to 1, marking the object as non-existent and preventing bus transmission or reception on that ID.CiA 301 PDO COB-IDs support dynamic reconfiguration via SDO uploads and downloads to the Object Dictionary during the pre-operational state, allowing customization while retaining the predefined set as defaults for initial boot-up and basic operation.CiA 301 This flexibility ensures the Predefined Connection Set serves as a reliable baseline for robust, standards-compliant CANopen networks.CiA 301

Core Protocols

Network Management (NMT)

(NMT) in CANopen provides a master-slave protocol for controlling the operational states of nodes on the network, ensuring coordinated boot-up, state transitions, and error monitoring. It operates using predefined CAN identifiers and follows the structure outlined in the CANopen specification. The NMT state machine defines four primary states for each node: Initialization, Pre-operational, Operational, and Stopped. In the Initialization state, entered upon power-on or reset, the node performs internal self-tests and resets its application and communication parameters before transitioning to Pre-operational. The Pre-operational state enables configuration access while disabling exchange. The Operational state activates full network communication, including process data. The Stopped state halts most communications, retaining only essential monitoring functions, with node-specific application behavior. These states allow the network to progress systematically from setup to active operation. State transitions are initiated by the NMT master through broadcast or messages on COB-ID 0x000, formatted as two bytes: the first byte specifies the command, and the second byte identifies the target node (00h for all nodes). Key command specifiers include 0x01 to start a node or all nodes, transitioning to Operational; 0x02 to stop a node or all nodes, entering Stopped; 0x80 to enter Pre-operational; 0x81 to reset a specific node, returning it to Initialization and reinitializing the application; and 0x82 to reset communications on a node or all nodes, reloading parameters without affecting the application. For example, broadcasting 0x01 with node ID 00h starts all nodes into Operational state. These commands ensure synchronized network control. Error control and monitoring rely on two protocols: the heartbeat consumer and node guarding. The heartbeat protocol involves each slave node periodically transmitting a one-byte message indicating its current state (e.g., 0x04 for Stopped, 0x05 for Operational, 0x7F for Pre-operational) on COB-ID 0x700 + node ID, typically every 1 second as configured in object 0x1017h; upon entering Pre-operational, a boot-up message with value 0x00 is sent to signal readiness. Node guarding uses a master-initiated poll-response mechanism, where the master sends a guard request on COB-ID 0x700 + node ID, and the slave responds with its state and a toggle bit on the same COB-ID, enabling detection of timeouts based on guard time and lifetime factor. The NMT master, typically a designated node, monitors all slaves' states via these protocols, triggering resets or alerts on discrepancies to maintain network integrity; slaves passively report status without initiating transitions.
NMT CommandSpecifier (Byte 1)Node ID (Byte 2)Effect
Start Remote Node0x01Specific or 00h (all)Transition to Operational
Stop Remote Node0x02Specific or 00h (all)Transition to Stopped
Enter Pre-operational0x80Specific or 00h (all)Transition to Pre-operational
Reset Node0x81Specific or 00h (all)Reset to Initialization (app reset)
Reset Communication0x82Specific or 00h (all)Reload communication parameters
StateKey CapabilitiesTransmit Functions Active
InitializationSelf-tests, resetsNone
Pre-operationalConfiguration accessNMT, SDO, EMCY, SYNC
OperationalFull data exchangeAll (PDO, SDO, etc.)
StoppedMinimal monitoringNMT, EMCY, Guarding/Heartbeat

Service Data Objects (SDO)

Service Data Objects (SDOs) provide a client-server protocol for accessing entries in a CANopen device's object dictionary, enabling non-real-time configuration, parameterization, and data transfer between devices on the network. In this model, an SDO client, typically a master device, initiates requests to an SDO server on a target node, which responds with the requested data or confirmation of the operation. SDOs target the object dictionary for reading or writing values, supporting asynchronous transfers suitable for setup and diagnostics rather than time-critical applications. The primary services offered by SDOs are , for reading data from the server's object dictionary, and , for writing data to it. These services use confirmed communication, where the server acknowledges each client request. For data up to 4 bytes, expedited transfers complete in a single request-response pair without segmentation. Larger data employs segmented transfers, dividing the content into 7-byte payloads per CAN frame, with the client or server requesting confirmation after each segment to ensure reliable delivery. Introduced in CiA 301 version 4 and later, block transfer mode enhances efficiency for very large data by grouping up to 127 segments into a block, confirmed as a unit, optionally with CRC for integrity. SDO frames follow an 8-byte format transmitted over CAN, consisting of a communication object identifier (COB-ID), command specifier, object dictionary index and sub-index, and data field. The COB-ID is calculated as 0x600 + node ID for client-to-server requests (e.g., 0x605 for node 5) and 0x580 + node ID for responses. The command specifier byte defines the service and transfer type; for example, 0x40 initiates an upload request, while 0x23 initiates an expedited download of 4 bytes. Bytes 2-3 hold the 16-bit index (little-endian), byte 4 the 8-bit sub-index, and bytes 5-8 the data or reserved fields, addressing specific object dictionary entries. In segmented transfers, a toggle bit in the command specifier alternates between 0 and 1 across segments to detect lost or duplicated frames. Error conditions during SDO transfers are handled by aborting the service and transmitting a 4-byte abort code in the response frame with command specifier 0x80. Standardized abort codes in CiA 301 include 0x05040001 for an invalid or unknown client/server command specifier and 0x05030000 for a toggle bit that did not alternate correctly. These codes provide diagnostic information, such as protocol timeouts (0x05040000) or access violations, allowing the client to retry or report issues.

Process Data Objects (PDO)

Process Data Objects (PDOs) facilitate efficient, real-time cyclic data exchange in CANopen networks, enabling the transmission of application-specific process data between nodes with minimal protocol overhead. Unlike service-oriented protocols, PDOs support high-speed I/O operations by directly mapping object dictionary entries into CAN frames, allowing for asynchronous or synchronous communication without acknowledgments or retries. Each PDO consists of up to 8 bytes of user data, making it suitable for control and measurement applications in industrial automation. CANopen defines two types of PDOs: Receive PDOs (RPDOs), which serve as inputs to a receiving node, and Transmit PDOs (TPDOs), which act as outputs from a transmitting node. The predefined connection set limits nodes to up to 4 RPDOs and 4 TPDOs each, though the specification permits up to 512 of each for extended implementations. PDO mapping is configurable through the object dictionary, where communication parameters (e.g., index 0x1400 for RPDO1 COB-ID and index 0x1800 for TPDO1 COB-ID) define the frame identifiers, and mapping parameters (e.g., index 0x1600 for RPDO1 and 0x1A00 for TPDO1) specify the source or destination objects, including their bit length and position within the PDO data bytes. This mapping allows flexible assembly of process data from various dictionary entries, such as status flags or sensor values, into a single frame. Transmission of TPDOs can be event-driven, triggered by internal application events; time-triggered, using an event timer to enforce periodic rates; or synchronous, aligned with the SYNC protocol for coordinated network updates. Key include the COB-ID for unique identification (e.g., predefined values starting from 0x200 + node ID for RPDO1), transmission type (cyclic or acyclic modes), and size up to 8 bytes. To manage bus load, an inhibition time sets the minimum interval (in multiples of 100 µs) between consecutive transmissions, while the event timer (in multiples of 1 ms) initiates sends if no event occurs within the specified period. PDOs support dynamic reconfiguration of these during operation.

Supporting Protocols

Synchronization (SYNC)

The Synchronization (SYNC) protocol in CANopen serves as the foundational mechanism for achieving coordinated real-time behavior across network nodes, enabling precise timing for distributed operations such as data acquisition and actuation. By broadcasting periodic synchronization pulses, it allows devices to align their actions, particularly for time-critical applications like motion control, without relying on a central clock master for absolute time distribution. This protocol is defined in the CANopen application layer specification, where a designated SYNC producer—typically a master node—transmits an empty message to trigger synchronized responses in consumer nodes. The SYNC message uses a fixed COB-ID of 0x080, ensuring high-priority transmission on the , and contains no data bytes in its basic form, though it may include a single-byte counter if configured for overflow tracking. The transmission interval, known as the communication cycle period, is configurable via object dictionary entry 0x1006h as an UNSIGNED32 value in microseconds (default 0, disabling SYNC production), allowing periods from 0 µs (asynchronous mode) up to approximately 4.29 seconds for typical implementations, though longer durations are possible. Object 0x1005h defines the COB-ID for the SYNC message and includes a generation flag (bit 30 set to 1 for s, 0 for consumers), enabling any node to assume the role while others act as consumers. Only one node should be configured as to avoid conflicts, and the protocol supports network-wide by having consumers detect and respond to these pulses. In usage, the SYNC protocol primarily triggers the transmission of synchronous Process Objects (PDOs) in consumer nodes operating in SYNC mode, where devices wait for the before sending or updating to ensure temporal alignment across the network. For cycle tracking, the SYNC producer increments an internal counter with each transmission, starting from 1; if object 0x1019h (synchronous counter overflow value) is set greater than 1 (range 2–240), this counter byte is appended to the SYNC message, and it resets to 1 upon reaching the overflow threshold or when the node transitions from the NMT stopped state. This counter aids in detecting missed cycles or sequence errors, with consumers using it to synchronize every nth SYNC as configured in their PDO parameters (e.g., transmission type 1 for every cycle, or higher for subsampling). Modes include free-run operation, where nodes generate PDOs independently based on an internal matching the expected cycle period; SYNC mode, which relies on received messages for triggering; and profile-specific variants, such as in CiA 402 for drive , where SYNC aligns position or updates. Handling of SYNC reception involves optional capture of a local time stamp upon message arrival, configurable via object 0x1013h for high-resolution timing if supported, to measure or latency in real-time systems. Overflow resets ensure continuous operation without indefinite counter growth, and if no SYNC producer is present, nodes may default to free-run mode using the 0x1006h period as a reference. The protocol's simplicity—requiring no acknowledgments—minimizes bus load while providing robust synchronization for up to 127 nodes, though actual performance depends on arbitration and transmission delays. Configuration occurs via Service Data Objects (SDOs) during network initialization, ensuring all nodes agree on cycle parameters for .
Object IndexNameTypeAccessDefault ValueDescription
0x1005hCOB-ID SYNC MessageUNSIGNED32rw0x00000080 (11-bit) or 0x80000080 (29-bit)Defines SYNC COB-ID (bits 0–28/10) and flags for frame format (bit 29) and generation (bit 30: 1=). Bit 31 reserved.
0x1006hCommunication / Cycle PeriodUNSIGNED32rw0x00000000SYNC transmission interval in µs; 0 disables production. Mandatory for .
0x1019hSynchronous Counter Overflow ValueUNSIGNED8rw0x00 (profile-specific)Specifies counter wrap-around (0=no byte, 2–240=byte included); resets counter to 1 on overflow.

Emergency (EMCY)

The (EMCY) protocol in CANopen enables devices to report internal errors asynchronously to other nodes on the network, facilitating rapid detection and response to faults. It operates as a producer-consumer service where the affected node acts as the , transmitting a single message upon error occurrence without requiring acknowledgment from consumers. This mechanism ensures timely error signaling while avoiding network overload, as no further EMCY messages are sent for the same error until it is cleared or a new one arises. EMCY messages use a fixed Communication Object Identifier (COB-ID) configured via object 0x1014, with the default value of 0x080 plus the node's ID (ranging from 0x080 to 0x0FF for node-IDs 1 to 127). The 8-byte payload consists of a 2-byte emergency error code, a 1-byte error register mirroring object 0x1001, and 5 bytes of manufacturer-specific data that may include additional diagnostic details like register contents. Transmission is event-driven and follows an unconfirmed push model, with Remote Transmission Requests (RTR) prohibited to maintain efficiency. To prevent message flooding, an optional inhibit time (object 0x1015, in multiples of 100 µs) can be set, delaying subsequent transmissions from the same producer. Error codes are structured into classes and specific values as defined in the CANopen application layer specification. Classes include generic errors (e.g., 0xFF00 for manufacturer-specific issues), communication errors (e.g., 0x81xx for CAN-related faults like bus-off at 0x8210), and device or application errors (e.g., 0x60xx for temperature issues or 0xFF00 for generic application faults). Representative codes encompass 0x1000 for generic errors, 0x8110 for CAN overrun, 0x8120 for error passive mode, and 0xFF00 for device-specific problems, allowing for extensible manufacturer definitions. The error register byte provides further categorization, with bits indicating generic (bit 0), communication (bit 1), device profile (bit 2), and additional errors (bit 3). Consumers, configured via object 0x1028, receive and process EMCY messages by or storing the details for diagnostics, with reactions determined by the application (e.g., triggering alerts or state changes). No standardized response protocol exists, emphasizing flexibility for network managers. EMCY transmission is permitted in Pre-operational, Operational, and Stopped NMT states but not during Initialization, and can be cleared through object dictionary access or NMT reset commands. History of recent is maintained in object 0x1003 for retrieval via Service Data Objects (SDO).

Time Stamp (TIME)

The in CANopen provides a mechanism for distributing a synchronized across the network, enabling devices to maintain a common temporal framework. A designated master node acts as the TIME , broadcasting the time stamp object periodically or as needed using an unconfirmed service in a producer-consumer model. The message uses a default COB-ID of 0x100, which can be configured via object dictionary entry 0x1012h, ensuring high-priority access to the bus for timely delivery. The consists of 6 bytes in TIME_OF_DAY format: bytes 0-3 represent since midnight (UNSIGNED28, 0 to 86,399,999 ms, with 4 MSBs reserved as 0), and bytes 4-5 represent days since January 1, 1984 (UNSIGNED16, 0 to 65,535 days), providing a resolution of 1 . The time starts from January 1, 1984 (00:00:00), providing a network-wide common time base without UTC adjustments or handling. Slave devices consume these TIME messages to adjust their local clocks, implementing the synchronization logic specific to their design without requiring acknowledgment. For enhanced precision, particularly in relation to periodic SYNC messages, object 0x1013h stores a high-resolution time stamp as a 32-bit value in microseconds, representing the elapsed time since the last received TIME message; this can be used by slaves to capture precise timestamps upon SYNC receipt, such as for PDO-related events. The protocol operates independently of SYNC but complements it by offering absolute time values rather than relative cycles, with slaves potentially updating their internal time bases based on received TIME data to minimize drift. Despite its utility, the has inherent limitations that affect its precision and applicability. It does not account for leap seconds, treating time as a continuous count without adjustments for irregularities, which suits non-real-time UTC applications but may require external compensation for long-term accuracy. Overall accuracy relies on the master's clock stability and network latency, introducing potential on the order of transmission delays, typically in the range for environments. In small networks without distributed timing needs, the protocol is often optional, as local device clocks suffice without global . In practice, the supports applications requiring temporal coordination, such as event logging in industrial control systems where devices record occurrences with network-consistent timestamps, or synchronized actions in distributed automation setups like sequences. For instance, in a multi-axis robotic system, slaves might use TIME-derived stamps to log triggers or coordinate responses, ensuring traceability and analysis of system behavior over time.

Layer Setting Services (LSS)

Layer Setting Services (LSS) enable the dynamic configuration of layer 2 parameters, such as node ID and bit timing, for unaddressed CANopen nodes, facilitating plug-and-play integration without physical reconfiguration or power cycling. This master-slave protocol, specified in CiA 305, allows an LSS master—typically a configuration host or network manager—to interact with LSS slaves (the CANopen devices) prior to Network Management (NMT) boot-up, thereby avoiding node ID conflicts and ensuring consistent bit rates across the network. By operating at a low protocol level, LSS supports the assignment of unique 7-bit node IDs (1 to 127) and bit rates ranging from 10 kbit/s to 1 Mbit/s, using the CAN bus for all communications. The LSS protocol employs two fixed Communication Object Identifiers (COB-IDs): 0x7E5 for master-to-slave commands and 0x7E4 for slave-to-master responses, both utilizing 8-byte data frames for simplicity and compatibility with basic CAN controllers. Services include mode switching between transparent (all slaves process commands) and selective (targets specific slaves via identity matching), identity inquiries to retrieve the 128-bit LSS —comprising ID, product code, revision number, and from object dictionary entry 0x1018—and node ID configuration, where the master assigns a value that the slave stores in object 0x1000. Additional services cover bit timing , allowing the master to set parameters like baud rate and sample point before issuing a network-wide switch command, with slaves delaying until all are ready to prevent communication disruptions. These operations ensure slaves remain in an LSS configuration state until explicitly released. Node ID assignment relies on selective addressing to identify unconfigured slaves without prior knowledge of their identities. In bit monitoring, the master sends inquire commands probing specific bits or bit positions of the 128-bit LSS address; matching slaves respond with a zero-data-length acknowledgment frame (a "ping") on COB-ID 0x7E4, enabling the master to iteratively narrow down unique identities through binary-like elimination, with response timeouts (e.g., 10-30 ms) ensuring only the fastest replying slave is acknowledged to avoid collisions. The fastscan service optimizes this for multiple nodes by dividing the LSS address into 32 four-bit and scanning stage-by-stage (33 stages total), where slaves respond on distinct CAN IDs (0x7D0 to 0x7DF) based on their nibble value, completing identification of up to 29 devices in under 25 seconds with a 25 ms timeout. Once isolated, the master configures the node ID, verifies it via a store command, and releases the slave to proceed with NMT initialization. This approach is essential for scalable networks with identical or interchangeable devices, such as in industrial automation, where hardware-based addressing like DIP switches is impractical. LSS version 3.0, released in 2013, introduced enhancements like fastscan for efficiency, while extensions in CiA 1305 support bit rates up to 8 Mbit/s. After LSS completion, nodes boot into NMT pre-operational state for application-layer configuration.

Configuration and Management

Network Initialization

The initialization of a CANopen network begins upon power-on, where all nodes enter the Initialization state as defined by the Network Management (NMT) protocol. In this phase, nodes perform internal resets and basic setup, transitioning through sub-states such as Reset Application and Reset Communication before reaching the Pre-operational state. If node addressing is not pre-configured, Layer Setting Services (LSS) may be used at this stage to assign unique node-IDs, ensuring no duplicates on the bus. Upon entering Pre-operational, each slave node broadcasts a boot-up using the Communication (COB-ID) 0x700 + its node-ID, with a single data byte of 0x00, signaling readiness to the NMT master. The master then issues NMT commands to maintain or set slaves in Pre-operational state, enabling configuration via Service Data Objects (SDO) for parameters such as Process Data Object (PDO) mappings and communication settings. Once configuration is complete, the master sends a Start Remote Node command (NMT command specifier 0x01) to transition all nodes to the Operational state, activating PDO and SYNC communications for real-time data exchange. The NMT master holds primary responsibility for orchestrating these transitions, broadcasting commands like Enter Pre-operational (0x80) or Stop Remote Node (0x02) as needed, while monitoring slave heartbeats or node-guarding to verify liveness. Slaves respond to these commands and continue sending periodic heartbeats in Operational state to confirm their status. In case of errors, such as detected faults during configuration, the master can reset affected nodes to Pre-operational for reconfiguration or recovery. Common troubleshooting issues during initialization include node-ID conflicts, which arise when multiple devices claim the same ID, leading to ignored messages or bus errors; resolving this requires isolating and reassigning IDs via LSS or manual dip switches. Baud rate mismatches between nodes and the master cause increased error frames and failed boot-up detections, often indicated by CAN error counters exceeding thresholds; verification involves checking all device settings against the network's configured rate (e.g., 500 kbit/s).

Electronic Data Sheets (EDS)

Electronic Data Sheets (EDS) serve as standardized, vendor-supplied files that describe the functional and parametric properties of unconfigured CANopen devices, enabling offline network , , and configuration. These files detail the device's object dictionary, which encompasses communication parameters per CiA 301, application objects from device profiles (e.g., CiA 401 for I/O modules), and manufacturer-specific entries, without including runtime-specific configurations like node IDs or . The EDS format follows an INI-style structure with sections denoted by square brackets and key-value pairs, as specified in CiA 306-1; an XML-based variant, introduced via CiA 311 in , enhances interoperability by aligning with ISO 15745 for industrial device descriptions. This XML format, known as XML Device Description (XDD), supports richer , including complex parameter dependencies and profile unification across CANopen and related protocols. Legacy EDS files use the .eds extension in the text-based INI format, while XDD files provide a forward-compatible alternative mandatory for CANopen FD implementations. Key structural elements include the [FileInfo] section for file metadata (e.g., EDS version, typically "4.0" or later), the [DeviceInfo] section for identification details such as vendor ID (16-bit unique code), product code, revision number, and supported profiles (e.g., CiA 402 for drives). Parameter descriptions in the [Object list] or equivalent XML elements specify object indices (e.g., 0x1000 for device type), types, access rights, default values, and limits (minimum, maximum, actual). Communication sections, like [COB-ID] or XML equivalents, outline default COB-IDs for services such as PDOs (e.g., 0x180 + node ID for TPDO1) and supported PDO mappings linking application objects to CAN frames. These elements collectively describe dictionary contents and PDO mappings without delving into online initialization sequences. In practice, EDS and XDD files are imported into engineering tools like Vector CANalyzer or CANeds for tasks such as generating device configuration files (DCFs), simulating network behavior, and validating PDO assignments during design. Submission of compliant EDS files is mandatory for CiA certification, ensuring devices adhere to profile specifications and facilitating interoperability in multi-vendor systems. For instance, an EDS for a generic CiA 401 digital input device would specify supported inputs, heartbeat intervals, and emergency object mappings, allowing tools to auto-populate network parameters.

Extensions and Variants

CANopen FD

CANopen FD represents an extension of the classic CANopen protocol, adapted to leverage the capabilities of the Controller Area Network with Flexible Data-rate () physical and data-link layers as defined in ISO 11898-1:2015. This adaptation is specified in the CAN in Automation (CiA) standard CiA 1301, originally released in September 2017, which enables higher data rates and larger payloads while maintaining compatibility with existing CANopen infrastructure. The protocol supports arbitration bit rates up to 1 Mbit/s and data bit rates up to 8 Mbit/s, allowing for efficient transmission in embedded networks. Key modifications in CANopen FD include the adoption of the 29-bit extended Communication Object Identifier (COB-ID) from CAN FD, which expands addressing capacity, and a flexible Data Length Code (DLC) that accommodates payloads from 0 to 64 bytes per frame, compared to the 8-byte limit in classic CANopen. Process Data Objects (PDOs) can now map up to 64 bytes, enabling the transmission of more complex data structures without fragmentation in many cases. Despite these enhancements, CANopen FD remains backward compatible with classic CANopen devices through the use of CAN FD's dual-speed frame format, where arbitration occurs at legacy speeds and data phases accelerate when supported by all nodes. Core protocols such as Service Data Objects (SDOs) retain segmented transfers for larger objects, and PDO mapping follows the established object dictionary model. The primary benefits of CANopen FD lie in its increased throughput, which supports applications requiring rapid exchange of voluminous data, such as image processing or multi-sensor fusion in industrial automation. This results in reduced latency and higher bandwidth utilization—up to eight times that of classic CANopen—while preserving the protocol's real-time and plug-and-play features. For instance, in systems, larger PDOs facilitate the simultaneous transmission of position, , and data across multiple axes, enhancing in robotic applications. As of 2025, CANopen FD adoption is expanding in sectors like and (IIoT), driven by the need for scalable networking in smart factories and connected devices. The CiA offers and for CANopen FD devices, ensuring through procedures outlined in CiA 1310-1, with certified products increasingly available from vendors supporting advanced medical equipment and automation systems.

Safety and Other Extensions

CANopen Safety, standardized as EN 50325-5, extends the core protocol to support in critical applications by enabling certified communication up to Safety Integrity Level 3 (SIL 3) and Performance Level e (PL e) according to and ISO 13849-1, respectively. This extension employs a black channel approach, treating the underlying CAN physical and data link layers as untrusted while ensuring safety through higher-layer mechanisms, including redundant transmission of safety-related data frames and cyclic redundancy checks (CRC) for integrity verification. Safety Relevant Data Objects (SRDOs) facilitate secure exchange of process and configuration data, with each safety message duplicated in consecutive CAN frames containing identical payloads but offset identifiers, alongside time stamps and CRCs to detect transmission errors or delays. The protocol incorporates fault detection and response mechanisms, such as heartbeat monitoring and signaling adapted for contexts, ensuring that safety-related events trigger immediate shutdowns or safe states in systems like industrial machinery or elevators. Compliance testing for CANopen Safety involves pre-certified stacks and hardware, such as dual-channel CAN controllers, to verify adherence to SIL 3/PL e through rigorous simulation of fault scenarios and redundancy validation by bodies like Rheinland. As of 2025, CANopen Safety sees increased adoption in construction and earth-moving machinery, as demonstrated at the Bauma 2025 . Beyond safety, CANopen supports extensions for non-traditional networks, including CiA 309, which defines gateways for accessing CANopen segments via TCP/IP-based Ethernet, enabling remote configuration, diagnostics, and integration with higher-level systems through protocols like /TCP, ASCII commands, or RESTful HTTP/ mappings. This facilitates applications in distributed IoT environments, such as subsea monitoring, where physical CAN cabling is impractical. Wireless variants are addressed by CiA 457, which outlines interface profiles for gateways bridging CANopen to transmission media, supporting virtual networks with services like SDO uploads/downloads, emergency production, and heartbeat monitoring while relying on lower-layer tunneling per CiA 315 for diagnostic data transfer. Gateway profiles, such as those in CiA DS-416 for subsystems, standardize interactions for device control and status reporting across interconnected networks, including door locking and alarm handling with address claiming procedures. CANopen's integration with OPC UA has advanced IIoT capabilities, enabling seamless from CANopen object dictionaries to OPC UA address spaces via dedicated servers and gateways, thus supporting secure, platform-independent in industrial ecosystems. These extensions undergo additional testing beyond standard conformance, including validation with OPC UA companions and safety-specific audits to ensure robustness in hybrid networks.

Applications

Industrial and Automation Use

CANopen finds extensive application in factory , where it connects programmable logic controllers (PLCs), sensors, and actuators to streamline manufacturing processes such as assembly lines and . In these setups, sensors provide on environmental conditions or machine states, while actuators execute precise control commands, often in environments like breweries or airports for conveyor systems. For , the CiA 402 device profile (DS-402) standardizes interfaces for servo drives, frequency inverters, and stepper motors, enabling synchronized operations in industrial machinery. This profile supports state machines for power sequencing and fault handling, ensuring reliable performance in dynamic systems. In , CANopen supports systems like elevators through the CANopen Lift profile (CiA 417), which defines communication for lift controllers, doors, and safety devices, supporting up to eight parallel lift units. This enables interoperability among components from different manufacturers, facilitating condition monitoring and fault diagnostics. Practical examples include robotic arms in automation lines, where process data objects (PDOs) transmit position feedback for coordinated motion, and generic I/O modules compliant with DS-401 manage inputs and outputs in conveyor belts for logistics sorting. CANopen's advantages in industrial settings include cost-effective wiring via a single twisted-pair bus that reduces cabling complexity compared to point-to-point systems, real-time communication capabilities with cycle times as low as under 1 ms at 1 Mbps bit rates, and robustness against electromagnetic interference (EMC) as specified in ISO 11898. These features make it suitable for harsh environments like factories with high electrical noise. In 2025 trends aligned with Industry 4.0, CANopen integrates with AI-driven gateways for predictive maintenance, where connected sensors preprocess data to forecast equipment failures and minimize downtime. Case studies highlight its practical impact: Siemens SIMATIC S7-1200 PLCs use CM CANopen gateways to interface with networks for automated guided vehicles (AGVs), enabling backbone communication in material transport. Similarly, retrofits in logistics centers employ these gateways with S7-1200 controllers to upgrade conveyor belts, achieving seamless data exchange for sorting and routing. For elevators, CiA 417 implementations in controllers like the ASP116 Evolution support up to 32 floors with dual CANopen interfaces for reliable operation.

Automotive and Specialized Implementations

In automotive applications, CANopen is employed in heavy-duty vehicles such as trucks and trailers, where it facilitates communication through gateways to networks, enabling interoperability between add-on devices and the vehicle's primary control systems. Specifically, the CiA 413 series defines CANopen interfaces for these gateways, allowing integration of auxiliary equipment like or specialized sensors without disrupting the J1939 backbone. In electric vehicles, CANopen supports battery management systems (BMS) by standardizing interfaces for battery modules and chargers, as outlined in the CiA 418 device profile, which ensures safe monitoring of voltage, current, and state-of-charge parameters across modules. This complements classic CAN protocols like J1939, providing a higher-layer abstraction for non-powertrain functions while leveraging the robustness of the underlying in harsh environments. In , CANopen supports flight data recorders for real-time logging of flight parameters in harsh environments, ensuring reliable data capture for safety analysis. Beyond automotive, CANopen finds specialized use in medical devices through profiles like CiA 412, which specify interfaces for equipment such as collimators and dose measurement systems, ensuring precise control and data exchange in clinical settings. In , while primary tractor-implement communication often relies on ISOBUS (ISO 11783), CANopen integrates for auxiliary systems like precision farming sensors and automated implements, supporting rugged operation in field conditions. For marine and rail sectors, CANopen is used in ruggedized applications; in rail, profiles such as CiA 423 for power drive systems and CiA 424 for door controls accommodate vibration, temperature extremes, and through robust CAN transceivers and error-handling mechanisms. These implementations prioritize environmental resilience, with devices often certified to standards like for rail applications. Key tools for developing and debugging CANopen networks in these domains include analyzers like PCAN-View from PEAK-System, which monitors raw CAN traffic and supports basic CANopen message decoding for quick diagnostics in vehicle testing. Vector's provides advanced protocol analysis, including filtering, graphing, and simulation of CANopen objects, essential for validating automotive integrations. Protocol stacks such as EmSA's CANopen offer modular, portable implementations for embedded controllers, simplifying compliance with profiles like CiA 418 in battery systems. For simulation, Vector's with CANopen plugins enables virtual network modeling, allowing engineers to test interactions between EV components or rail door controls without physical hardware. As of 2025, challenges in these implementations include enhancing cybersecurity, with CiA developing guidelines for secure CANopen configurations to mitigate risks like unauthorized access in connected vehicles and medical devices, building on efforts such as CANsec for and . Migration to CANopen FD addresses bandwidth limitations in data-intensive applications like EV BMS, offering up to 64-byte payloads while maintaining , though it requires hardware upgrades. Implementation costs remain a hurdle compared to alternatives like , as CANopen's simplicity yields lower per-node expenses (often under $10 for basic transceivers) but may necessitate gateways for high-speed needs, increasing overall system complexity in specialized setups.

References

  1. https://www.can-cia.org/can-knowledge/canopen
  2. https://www.can-cia.org/can-knowledge/canopen-history
  3. https://www.can-cia.org/canopen/
  4. https://media.hms-networks.com/image/upload/v1701953901/Documents/Whitepapers/Ixxat_CANopen-Protocol-Whitepaper_EN.pdf
  5. https://www.can-cia.org/cia-groups/technical-documents
  6. https://www.ni.com/en/shop/seamlessly-connect-to-third-party-devices-and-supervisory-system/the-basics-of-canopen.html
  7. https://www.can-cia.org/about-us/the-cia-story
  8. https://www.csselectronics.com/pages/canopen-tutorial-simple-intro
  9. https://forum.opencyphal.org/uploads/short-url/mNWuvY23DYckSFoSbfam0ji3YWn.pdf
  10. https://static.assets-stash.eet-china.com/album/old-resources/Blog/2008/4/1/8fac5e94-8da2-4264-a22f-d737740cc1fd.pdf
  11. https://www.can-cia.org/can-knowledge/history-of-can-technology
  12. https://www.can-cia.org/fileadmin/cia/documents/proceedings/2020_yao_pfeiffer.pdf
  13. https://www.can-cia.org/about-us
  14. https://www.youtube.com/watch?v=GAwTm4oVDa0
  15. https://www.can-cia.org/services/publications/can-community-news/16-2025
  16. https://www.can-cia.org/about-us/member-services/cia-member-days-2025
  17. https://www.can-cia.org/services/canopen-device-conformance-testing
  18. https://www.can-cia.org/can-knowledge
  19. https://www.can-cia.org/cia-groups/international-standardization
  20. https://www.can-cia.org/can-knowledge/canopen-lower-layers
  21. https://www.can-cia.org/can-knowledge/generic-device-profiles/
  22. https://www.can-cia.org/can-knowledge/cia-401-series-i/o-device-profile/
  23. https://www.can-cia.org/can-knowledge/cia-402-series-canopen-device-profile-for-drives-and-motion-control/
  24. https://www.can-cia.org/can-knowledge/cia-404-canopen-device-profile-for-measuring-devices-and-closed-loop-controllers
  25. https://www.can-cia.org/can-knowledge/cia-303-series-canopen-related-documents
  26. https://www.can-cia.org/can-knowledge/cia-305-layer-setting-services-lss
  27. https://www.can-cia.org/services/canopen-conformance-test-tool
  28. https://www.can-cia.org/can-knowledge/standardized-higher-layer-protocols
  29. https://www.can-cia.org/can-knowledge/cia-402-series-canopen-device-profile-for-drives-and-motion-control
  30. https://www.can-cia.org/services/publications/can-community-news/06-2025
  31. https://www.can-cia.org/can-knowledge/canopen-internal-device-architecture
  32. https://www.nanotec.com/us/en/knowledge-base-article/canopen-motors-controllers
  33. https://www.microcontrol.net/en/portfolio/protocol-stacks/canopen/
  34. https://www.port.de/en/products/canopen/software/ansi-c-canopen-library.html
  35. https://www.can-cia.org/fileadmin/cia/documents/publications/cnlm/june_2022/cnlm_22-2_p08_open-source_canopen_protocol_stack_extended_olga_fischer_cia.pdf
  36. https://workarea.ego-gw.it/ego2/ego/itf/software/301_canopen.pdf
  37. https://www.can-cia.org/can-knowledge/sync-protocol
  38. https://cdn.vector.com/cms/content/know-how/_application-notes/canopen/AN-ION-1-1100_Introduction_to_the_CANopen_Protocol.pdf
  39. https://www.can-cia.org/fileadmin/cia/documents/publications/cnlm/june_2020/20-2_p32_cnlm_node-id_assignment_using_lss_olaf_pfeiffer_emsa.pdf
  40. https://www.can-cia.org/fileadmin/cia/documents/proceedings/2008_pfeiffer.pdf
  41. https://magna-power.com/assets/docs/html_alx/_common-firmware/lib/firmware/rst/anybus_documentation/outputs/can_magnaload_full_docs.html
  42. https://infosys.beckhoff.com/content/1033/bk51x0/2519229963.html
  43. https://www.ni.com/docs/en-US/bundle/ni-industrial-communications-canopen/page/troubleshooting-canopen-applications.html
  44. https://www.can-cia.org/can-knowledge/cia-306-series-electronic-device-description-edd
  45. https://www.can-cia.org/can-knowledge/cia-311-xml-schema-definition
  46. https://www.can-cia.org/fileadmin/cia/documents/proceedings/2017_gedenk.pdf
  47. https://forum.opencyphal.org/uploads/short-url/8yIusmKPLzadtXbQcGp8dE1NBva.pdf
  48. https://www.csselectronics.com/pages/canopen-eds-file-electronic-data-sheet
  49. https://www.emotas.de/en/software-products-by-emotas/canopen-software-products
  50. https://www.emotas.de/en/news-articles/improved-performance-with-canopen-fd
  51. https://kvaser.com/why-and-how-to-migrate-to-canopen-fd/
  52. https://www.can-cia.org/can-knowledge/canopen-fd-the-art-of-embedded-networking
  53. https://ebyteiot.com/ru/blogs/ebyte-iot-blog/canopen-fd-technology-introduction
  54. https://copperhilltech.com/blog/classical-can-vs-canfd-in-automotive-medical-devices-robotics-key-differences-and-usage/
  55. https://www.can-cia.org/services/canopen-device-conformance-testing-1
  56. https://www.can-cia.org/fileadmin/cia/documents/proceedings/2017_rupprecht.pdf
  57. https://www.controleng.com/network-safety-standard-european-standard-en-50325-5/
  58. https://www.can-cia.org/fileadmin/cia/documents/brochures/can_dictionary_v12.pdf
  59. https://www.isit.fr/fr/page/isit-canopen-safety-certifiable-stack-sil-2-sil-3.php
  60. https://www.eetimes.com/canopen-safety-chip-simplifies-safety-related-development/
  61. https://en.canopen-lift.org/wiki/CANopen-Safety-Chip_CSC02_certified_by_T%25C3%259CV
  62. https://www.can-cia.org/fileadmin/cia/documents/publications/cnlm/june_2025/25-2_cnlm.pdf
  63. https://www.can-cia.org/can-knowledge/cia-309-series-accessing-canopen-via-tcp
  64. https://www.can-cia.org/can-knowledge/cia-457-canopen-interface-profile-for-wireless-transmission
  65. https://www.can-cia.org/can-knowledge/cia-416-series-canopen-application-profile-for-building-door-control
  66. https://esd.eu/en/news/secure-and-fast-data-exchange-with-can-opc-ua-server
  67. https://www.hms-networks.com/p/ab7560-f-anybus-x-gateway-iiot-canopen-slave-opc-ua-mqtt
  68. https://www.isit.fr/fr/page/isit-canopen-safety-stack.php
  69. https://www.can-cia.org/fileadmin/cia/documents/proceedings/1998_gallus.pdf
  70. https://www.quicksilvercontrols.com/SP/AN/QCI-AN060_CiA402-CANopenDrivesAndMotionControlProfile.pdf
  71. https://www.can-cia.org/can-knowledge/cia-417-series-profile-for-lift-control-systems
  72. https://kvaser.com/canopen-lift/
  73. https://www.youtube.com/watch?v=eUDLWlnFeLg
  74. https://www.hms-networks.com/about-hms/case-studies/case-study/retrofit-for-conveyor-belts-in-logistics-centers-with-canopen-plc-expansion
  75. https://www.simmasoftware.com/canopen-explained/
  76. https://www.sontheim-electronic-systems.com/expertise/standards/fieldbus-systems/can-iso-11898/
  77. https://www.can-cia.org/fileadmin/cia/documents/publications/cnlm/september_2024/24-03_cnlm.pdf
  78. https://www.can-cia.org/fileadmin/cia/documents/publications/cnlm/march_2024/cnlm_24-1_p07_canopen_feeds_ai_holger_zeltwanger_cia.pdf
  79. https://www.hms-networks.com/about-hms/case-studies/case-study/canopen-bus-as-a-backbone-network-in-a-siemens-plc-environment
  80. https://en.canopen-lift.org/wiki/Product_Guide
  81. https://www.can-cia.org/fileadmin/cia/documents/publications/cnlm/december_2022/cnlm_22-4_p6_history_and_trends_non-automotive_can_applications_olga_fischer_cia.pdf
  82. https://www.iwavesystems.com/news/protocol-stacks-to-speed-up-industrial-and-automotive-product-development/
  83. https://www.can-cia.org/can-knowledge/cia-418-canopen-device-profile-for-battery-modules
  84. https://delta-q.com/company-news/delta-q-technologies-includes-j1939-to-support-electric-vehicle-manufacturers/
  85. https://www.sonnepowercontrol.com/company-news/canopen-vs-j1939:-key-differences-and-application-guide.html
  86. https://www.can-cia.org/fileadmin/cia/documents/publications/cnlm/june_2022/cnlm_22-2_p18_can_in_air_and_space_cindy_weissmueller_cia.pdf
  87. https://www.can-cia.org/can-knowledge/cia-412-canopen-profiles-for-medical-devices
  88. https://www.can-cia.org/fileadmin/cia/documents/publications/cnlm/september_2025/25-3_cnlm.pdf
  89. https://www.can-cia.org/can-knowledge/application-profiles
  90. https://www.can-cia.org/can-knowledge/cia-424
  91. https://www.railwaypro.com/wp/canopen-in-the-application-field-of-rail-vehicles/
  92. https://forum.peak-system.com/viewtopic.php?t=7402
  93. https://www.youtube.com/watch?v=B-qXyzJAbIY
  94. https://www.esacademy.com/en/downloads.html
  95. https://www.vector.com/gb/en/products/products-a-z/software/canoe/option-canopen/
  96. https://can-cia.org/services/publications/can-community-news/09-2025
  97. https://dewesoft.com/blog/what-is-ethercat-protocol
  98. https://promwad.com/news/integrating-ethercat-canopen-and-coe
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.