CANopen
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.[1] 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.[1] 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.[1] 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.[2] 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.[2] 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.[2] Key to its architecture is the division into a CANopen protocol stack for network communication, an object dictionary indexing parameters (e.g., 1000h–1FFFh for communication objects), and application software for device-specific functions, all layered atop CAN's ISO 11898 physical and data link layers supporting both 11-bit and 29-bit identifiers.[1] This design unburdens developers from low-level hardware details, promoting flexibility in configurations like emergency handling and synchronization.[1] CANopen finds applications in motion control systems for high-precision drive synchronization, medical equipment, off-road vehicles, maritime electronics, railway controls, building automation, and even flight data recording, where its real-time reliability and fault tolerance are critical.[1] Its open standards, managed by CiA with input from global industry stakeholders, ensure broad vendor compatibility and ongoing enhancements, such as extensions for safety (CiA 304) and gateway functions.[1]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.[3][4] 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 building automation.[5] Key benefits include deterministic communication achieved via synchronized messaging, plug-and-play interoperability 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 application layer atop the CAN physical and data-link layers, with the object dictionary serving as a central data store for device parameters and mappings, though detailed implementations are specified elsewhere.[3][6]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 Europe. The CAN in Automation (CiA) nonprofit organization, 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 ASPIC, 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 1995 to define core device and application interfaces.[7][2][8] Key milestones in CANopen's development occurred in the late 1990s and early 2000s, driven by the demand for interoperable embedded networks in machine control and automation. In June 2000, CiA released version 4.0.1 of the CiA 301 specification, standardizing the core application layer 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 2000s, CANopen had become a dominant protocol in Europe, supported by CiA's efforts to harmonize with international standards, such as its inclusion in EN 50325-4 in 2003.[9][10][11] 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.[12][13][14]Standards and Organization
CAN in Automation (CiA)
CAN in Automation (CiA) is a non-profit association founded in March 1992 in Nuremberg, Germany, with the mission to provide an unbiased platform for developing and standardizing CAN-based higher-layer protocols, particularly for automation applications.[13] As the international users' and manufacturers' group for the Controller Area Network (CAN), CiA fosters the adoption of CAN technology across industries by promoting interoperability and innovation.[13] The organization is structured as a registered association governed by a General Assembly, a Board of Directors, a Technical Committee (TC), and a Business Committee, with CiA GmbH handling administrative operations.[13] As of November 2025, CiA has 760 member companies worldwide.[15] It operates through specialized working groups coordinated by the TC, such as those focused on device profiles, functional safety, and protocol extensions like CANopen FD.[13] CiA also hosts annual conferences, webinars, and member days, including 2025 sessions dedicated to CANopen FD advancements.[16] CiA's primary activities include developing and maintaining technical specifications that cover all layers of CAN-based systems, from physical to application levels.[5] 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.[17] 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.[18] Through its efforts, CiA ensures seamless interoperability among CANopen devices from different vendors, reducing development costs and enhancing system reliability in industrial applications.[13] The organization 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.[19]Key Specifications and Profiles
The core specification for CANopen is defined in CiA 301, titled "CANopen Application Layer and Communication Profile," which outlines the application layer, communication protocols, and device model for CANopen networks.[1] 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 network management.[5] It also details communication objects (COB-IDs) for real-time data exchange, error reporting, and network control, with bit rates 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.[20] CANopen device profiles extend CiA 301 by defining standardized objects, parameters, and behaviors for specific device types, ensuring interoperability 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).[21] 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.[22] Similarly, DS-402 (CiA 402) targets drives and motion control devices, defining objects for velocity, position, and torque modes, including cyclic operation modes and interpolation time for synchronized motion.[23] DS-404 (CiA 404) addresses measuring devices and closed-loop controllers, such as analog transducers with optional digital I/O, by standardizing sensor data transmission, calibration parameters, and feedback loops through dedicated object dictionary entries.[24] Additional specifications support implementation and verification. CiA 303 series covers physical layer 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 troubleshooting.[25] CiA 305, version 3.0.0, defines Layer Setting Services (LSS) protocols for dynamic configuration of node-IDs, bit rates, and node guarding without predefined addressing.[26] Conformance testing 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.[27] Recent updates integrate CANopen with emerging technologies. CiA 1301, version 1.1.0, extends the application layer for CANopen FD, supporting flexible data rates up to higher speeds, payloads up to 64 bytes per frame, and backward compatibility with classic CANopen via adjusted COB-IDs and bit timing for 40 MHz clocks.[28] 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 IEC 61508; profiles like CiA 402-4 incorporate dedicated safety parameters.[29] As of 2025, CiA continues refining these for enhanced functional safety in mobile machinery and automation.[30]Device Model
Object Dictionary
The Object Dictionary (OD) in CANopen serves as the central data model for devices, acting as an interface between the application software and the communication protocol layers. It is a hierarchical array 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.[9] The OD organizes entries as simple variables (e.g., Booleans, integers, or floating-point numbers) or as complex types such as arrays and records, with supported data types including basic ones like BOOLEAN, UNSIGNED8 to UNSIGNED64, INTEGER8 to INTEGER64, REAL32, REAL64, and specialized types like VISIBLE_STRING, TIME_OF_DAY, and DOMAIN for binary data 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 process to establish initial operational states.[9][1] The OD is divided into distinct areas based on index ranges to separate concerns: indices 0x0000 to 0x0FFF are reserved for data type 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 modular design, where communication setup is isolated from application data.[9][1] 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 interoperability among diverse nodes.[9]Node Architecture and Profiles
A CANopen node is architected with a layered structure 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 protocol stack, the object dictionary, and the application layer. The protocol stack processes incoming and outgoing messages, implementing handlers for core services such as Network Management (NMT) in master or slave mode, Service Data Objects (SDO) for configuration, and Process Data Objects (PDO) for real-time data exchange. The object dictionary serves as the central data storage mechanism, holding communication parameters and application-specific objects accessible by both the stack and the application. The application layer interfaces with the object's dictionary to control process hardware, enabling device-specific functionality while adhering to CANopen standards.[31] CANopen profiles define standardized behaviors and object mappings to ensure interoperability across devices. The generic profile, specified in CiA DS-301, provides the foundational communication and application layer 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 motion control applications, defining mandatory objects for velocity, 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.[1][6][29] 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 architecture supports a master-slave hierarchy for centralized control, peer-to-peer communication is optional through PDO mappings, enabling direct data exchange between nodes without master intervention.[8][32] 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 GmbH 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 interoperability in industrial environments.[33][34][35]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.[1][9] 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.[9][4] Each frame features an 8-byte data field, with the Data Length Code (DLC) indicating the actual payload 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.[9][1]| Bit Positions | Field | Description |
|---|---|---|
| 10–7 | Function Code | Identifies the type of communication object (e.g., 0x2 for TPDO1). |
| 6–0 | Node ID | Specifies the sending or receiving node (0–127). |
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 interoperability among devices on the network without prior configuration.CiA 301 This set is specified in the CANopen application layer and communication profile, distinguishing between broadcast COB-IDs for network-wide messages and peer-to-peer 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 network management, synchronization, 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 Synchronization (SYNC) object is assigned 0x080, allowing periodic broadcasting for time-coordinated operations across the bus.CiA 301 Peer-to-peer COB-IDs are calculated by adding the node ID to a base value, ensuring unique identification for each device. The Emergency (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 Type | COB-ID (Broadcast) | COB-ID (Peer-to-Peer, + Node ID) |
|---|---|---|
| NMT | 0x000 | N/A (broadcast only) |
| SYNC | 0x080 | N/A (broadcast only) |
| EMCY | N/A | 0x080 |
| TPDO1 | N/A | 0x180 |
| RPDO1 | N/A | 0x200 |
| TPDO2 | N/A | 0x280 |
| RPDO2 | N/A | 0x300 |
| TPDO3 | N/A | 0x380 |
| RPDO3 | N/A | 0x400 |
| TPDO4 | N/A | 0x480 |
| RPDO4 | N/A | 0x500 |
| SDO Client | N/A | 0x600 (request) |
| SDO Server | N/A | 0x580 (response) |
| Heartbeat | N/A | 0x700 |
Core Protocols
Network Management (NMT)
Network Management (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 application layer 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 real-time data 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.[36] State transitions are initiated by the NMT master through broadcast or unicast 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.[36] 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.[36]| NMT Command | Specifier (Byte 1) | Node ID (Byte 2) | Effect |
|---|---|---|---|
| Start Remote Node | 0x01 | Specific or 00h (all) | Transition to Operational |
| Stop Remote Node | 0x02 | Specific or 00h (all) | Transition to Stopped |
| Enter Pre-operational | 0x80 | Specific or 00h (all) | Transition to Pre-operational |
| Reset Node | 0x81 | Specific or 00h (all) | Reset to Initialization (app reset) |
| Reset Communication | 0x82 | Specific or 00h (all) | Reload communication parameters |
| State | Key Capabilities | Transmit Functions Active |
|---|---|---|
| Initialization | Self-tests, resets | None |
| Pre-operational | Configuration access | NMT, SDO, EMCY, SYNC |
| Operational | Full data exchange | All (PDO, SDO, etc.) |
| Stopped | Minimal monitoring | NMT, 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.[8] 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.[4] SDOs target the object dictionary for reading or writing values, supporting asynchronous transfers suitable for setup and diagnostics rather than time-critical applications.[8] The primary services offered by SDOs are upload, for reading data from the server's object dictionary, and download, for writing data to it.[4] These services use confirmed communication, where the server acknowledges each client request.[8] For data up to 4 bytes, expedited transfers complete in a single request-response pair without segmentation.[4] 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.[8] 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.[4] 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.[8] 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.[4] 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.[8] 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.[4] In segmented transfers, a toggle bit in the command specifier alternates between 0 and 1 across segments to detect lost or duplicated frames.[8] 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.[4] 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.[8] These codes provide diagnostic information, such as protocol timeouts (0x05040000) or access violations, allowing the client to retry or report issues.[4]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.[9] 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.[9] 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 parameters 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 payload size up to 8 bytes. To manage bus load, an inhibition time parameter 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 parameters during operation.[9]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.[9] The SYNC message uses a fixed COB-ID of 0x080, ensuring high-priority transmission on the CAN bus, 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 producers, 0 for consumers), enabling any node to assume the producer role while others act as consumers. Only one node should be configured as producer to avoid conflicts, and the protocol supports network-wide synchronization by having consumers detect and respond to these pulses.[9][36][37] In usage, the SYNC protocol primarily triggers the transmission of synchronous Process Data Objects (PDOs) in consumer nodes operating in SYNC mode, where devices wait for the pulse before sending or updating data 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 timer 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 synchronization, where SYNC aligns position or velocity updates.[9][36][37] 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 jitter 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 CAN bus arbitration and transmission delays. Configuration occurs via Service Data Objects (SDOs) during network initialization, ensuring all nodes agree on cycle parameters for interoperability.[9][36]| Object Index | Name | Type | Access | Default Value | Description |
|---|---|---|---|---|---|
| 0x1005h | COB-ID SYNC Message | UNSIGNED32 | rw | 0x00000080 (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=producer). Bit 31 reserved. |
| 0x1006h | Communication / Cycle Period | UNSIGNED32 | rw | 0x00000000 | SYNC transmission interval in µs; 0 disables production. Mandatory for producers. |
| 0x1019h | Synchronous Counter Overflow Value | UNSIGNED8 | rw | 0x00 (profile-specific) | Specifies counter wrap-around (0=no byte, 2–240=byte included); resets counter to 1 on overflow. |