CANopen is a higher-layer communication protocol built on top of the Controller Area Network (CAN) bus. It is widely used in industrial automation and robotics, particularly for communicating with motor controllers, servo drives, sensors, and other embedded devices.

CAN defines how devices exchange messages over the physical communication network. CANopen builds on top of it by defining standardized message types, device states, parameter access, and mechanisms for exchanging operational data.

On the rover's robotic arm, the Avatar actuators use CANopen to receive commands and provide feedback to the controller.

Core CANopen Concepts

CANopen is built around several key concepts:

• Communication models: Define how devices interact, such as client/server and producer/consumer.
• Communication objects: Define the types of information exchanged between devices, including Service Data Objects (SDOs) and Process Data Objects (PDOs).
• Network management and device states: Define how devices are initialized and controlled within the network.
• Object Dictionary (OD): A standardized structure containing a device's parameters, configuration, and supported functionality.
• Electronic Data Sheet (EDS): A file describing a device's CANopen capabilities and Object Dictionary entries.
• Device profiles: Define standardized behavior and parameters for particular classes of devices.

CANopen Communication Models

CANopen supports different communication models depending on the purpose of the message.

Master/Slave

In network management, a CANopen NMT (Network Management) master controls the network's device states. It can issue commands to initialize devices, start or stop communication, and manage their operational state.

A CANopen network can contain multiple devices, but a typical NMT network uses one active NMT master.

Note that master/slave is not the same as client/server: the NMT master manages device states, while client/server communication is used for services such as accessing the Object Dictionary.

Client/Server

A client initiates a request, and a server processes that request and returns a response.

CANopen uses this model for SDO communication. For example, the controller can request the value of a motor parameter from an actuator, and the actuator responds with the requested value.

The client initiates the exchange, so communication is request-driven.

Producer/Consumer

A producer transmits data that one or more consumers can receive.

Unlike client/server communication, the producer does not necessarily wait for a specific request before transmitting data. This makes producer/consumer communication useful for exchanging operational data efficiently.

CANopen PDOs use this model. For example, an actuator can transmit its current position, which the controller receives and uses for monitoring or control.

CANopen Frames and COB-IDs

CANopen communicates using CAN frames. In a typical CANopen network using Classical CAN, each frame contains a CAN identifier and a data payload of up to eight bytes.

The Communication Object Identifier (COB-ID) identifies a CANopen communication object. It is based on the CAN identifier and may also include configuration flags, depending on the context.

For standard 11-bit CAN identifiers, the predefined CANopen connection set commonly divides the identifier into:

• Function code: 4 bits that identify the communication-object type.
• Node ID: 7 bits that identify the destination or source node, depending on the communication object.

Node IDs typically range from 1 to 127. Node ID 0 is reserved for specific uses, including broadcast NMT commands.

This function-code/node-ID arrangement applies to the predefined connection set. CANopen also permits configurable COB-IDs, so not every identifier must follow this exact division.

A CANopen network can contain several communication-object types, including SDOs, PDOs, and network-management messages.

Service Data Objects (SDOs)

An SDO provides access to entries in another CANopen device's Object Dictionary.

SDOs use the client/server communication model:

• The SDO client initiates the request.
• The SDO server processes the request and responds.

SDOs are commonly used for device configuration, parameter inspection, and diagnostics.

There are two main directions for transferring data:

• SDO upload: Reads data from the server's Object Dictionary.
• SDO download: Writes data to the server's Object Dictionary.

For example, the controller might use an SDO upload to read a motor's configuration parameter, or an SDO download to change a supported parameter.

An interesting comparison is TCP, in the sense that SDO's require a handshake exchange to download data. It has to follow a request/acknowledge pattern, which is why SDOs are reliable but have overhead.

SDO transfer sizes

SDOs support different transfer mechanisms:

• Expedited transfer: Transfers up to four data bytes in a single SDO data frame.
• Segmented transfer: Splits larger data transfers across multiple frames.
• Block transfer: Supports transferring larger amounts of data in blocks when supported by the device and implementation.

SDOs are therefore suitable for configuration and diagnostic tasks, including parameters that cannot fit into a single CAN frame.

However, because an SDO transfer involves request/response communication and may require multiple frames, it is generally less suitable than PDOs for frequent, time-sensitive operational data.

Process Data Objects (PDOs)

PDOs are used to exchange operational data efficiently between CANopen devices.

Unlike SDOs, PDOs are designed for low-overhead data exchange. A PDO can carry multiple mapped application values in a single CAN frame.

For Classical CAN, a PDO carries up to eight data bytes. The values included in those bytes are determined by the PDO mapping configuration.

For example, a motor controller might transmit its actual position and status information in a TPDO. The main controller can receive that information without initiating an individual SDO request for every value.

TPDO and RPDO

PDO names are defined from the perspective of the device being configured:

• Transmit PDO (TPDO): A PDO transmitted by the device.
• Receive PDO (RPDO): A PDO received by the device.

For example, a motor actuator may transmit its current position through a TPDO, which the main controller receives. The controller may send a target-position command to the actuator through an RPDO.

TPDO and RPDO refer to the direction of data flow relative to the device, not to separate communication protocols.

PDO transmission types

PDOs can be configured to transmit under different conditions, depending on device support and configuration.

• Synchronous transmission: PDO communication is coordinated with a SYNC event. Depending on the configured transmission type, data may be sent at each SYNC event or after every nth SYNC events.
• Event-driven or asynchronous transmission: PDOs are transmitted in response to configured events, changes, or timing conditions rather than being tied to every SYNC event.

The appropriate transmission type depends on the application's timing and control requirements.

PDO mapping

PDO mapping defines which Object Dictionary entries are included in a PDO and how they are arranged within its data payload.

For example, a PDO could be configured to carry an actuator's actual position and status information together, provided the selected entries fit within the available payload and the device supports the mapping.

A device typically provides default PDO mappings. Depending on its implementation, some mappings may be configurable through SDOs, while others may be fixed or restricted.

The CANopen Object Dictionary

The Object Dictionary (OD) is a standardized structure containing the parameters and data objects that describe a CANopen device's configuration, state, and functionality.

Each entry is identified by a 16-bit index and, where applicable, an 8-bit sub-index.

For example, a controller might access an actuator's Object Dictionary to read its actual position, inspect its status, or configure a supported operating parameter.

Object Dictionary entry attributes

An Object Dictionary entry can be described using several attributes:

• Index: The 16-bit identifier of the object.
• Sub-index: Identifies a particular element within an object, such as an array or record member.
• Name: A descriptive name for the parameter or object.
• Object type: Defines the structure, such as a variable, array, or record.
• Data type: Defines how the value is represented, such as an unsigned integer or visible string.
• Access type: Defines the permitted access, such as read-only (ro), read/write (rw), or write-only (wo).
• PDO mapping: Indicates whether the entry can be mapped into a PDO, where applicable.

The exact attributes and restrictions depend on the object and the device's implementation.

Standardized Object Dictionary ranges

CANopen reserves ranges of Object Dictionary indexes for different purposes. In the commonly used CANopen application-layer specification, these include:

• 0x1000–0x1FFF: Communication-profile parameters.
• 0x2000–0x5FFF: Manufacturer-specific parameters.
• 0x6000–0x9FFF: Standardized device-profile parameters.

These ranges help make device configuration more consistent, although manufacturer-specific objects and supported features vary between devices.

Accessing the Object Dictionary

Object Dictionary entries can be accessed remotely through SDO communication when the device supports the requested operation.

For example, the controller can read an entry using an SDO upload or change a writable entry using an SDO download.

PDOs provide another way to exchange selected Object Dictionary values. Rather than requesting each value individually, the controller and actuator can configure PDO mappings to transmit the required operational data efficiently.

When we say PDO mappings, we mean the OD entries hold the mappings of what a PDO payload could carry. For example, bytes 0-3 in the payload is configured mapping for position (as stated in OD), so if a PDO payload has written in bytes 0-3, the device understands what is being requested.

This distinction is important:

• SDOs provide access to Object Dictionary entries for configuration and other request-driven transfers.
• PDOs exchange mapped application data efficiently during operation.

Electronic Data Sheets (EDS)

An Electronic Data Sheet (EDS) is a standardized file format describing a CANopen device's communication capabilities and Object Dictionary.

An EDS file can provide information about supported parameters, data types, access permissions, and communication features. It helps configuration tools and developers understand how a device is intended to be used.

An EDS is a description of a device's capabilities, not the device's live configuration or current operating state. Some devices may also have an associated device configuration file, which can describe a particular configuration of the device.

When working with a new CANopen actuator, the manufacturer's EDS file is a useful reference for identifying the available Object Dictionary entries and supported functionality.

Network Management and Device States

CANopen devices use a Network Management (NMT) state machine to control their communication state.

The main NMT states are:

• Initialization: The device initializes its communication and application components.
• Pre-operational: The device can communicate using SDOs and perform configuration tasks, but normal PDO communication is not enabled.
• Operational: The device can perform normal operational communication, including PDO communication.
• Stopped: Normal application communication is restricted, and only certain communication services remain available.

The NMT master can send commands to change a device's state. For example, an actuator may be configured while pre-operational and then switched to operational when it is ready for normal communication.

Being in the operational state does not necessarily mean a motor is enabled or ready to move. The actuator may have additional application-level states and enable conditions that must also be satisfied.

Device Profiles

CANopen device profiles define standardized parameters and behavior for particular classes of devices.

They help different devices expose similar functionality through consistent Object Dictionary entries and communication conventions.

For example, the CANopen device profile for drives and motion control is commonly associated with CiA 402. It defines standardized concepts for drive operation, including control and status words and operating modes.

However, not every CANopen actuator implements the same device profile. The relevant profile, supported objects, and operating modes must be confirmed using the manufacturer's documentation.

Resources

• https://www.csselectronics.com/pages/canopen-tutorial-simple-intro