CANopen Explained - A Simple Intro (2020)

Summary

The video introduces CANopen as a higher-layer communication protocol built on CAN bus. CAN provides the physical and data-link transport; CANopen adds standardized ways for devices, or nodes, to communicate, share data, and be configured. This standardization makes it easier to integrate devices from different vendors and configure them after installation.

CANopen was developed for motion-oriented machine control. It is now used in motor control, robotics, industrial machinery, medical equipment, and various vehicle applications.

Six core CANopen concepts

1. Communication models

   • Master/slave: A master can request information from slave nodes and manage their states.
   • Client/server: A client requests data from a server. Reading an object is called an upload; writing one is called a download.
   • Producer/consumer: A producer sends data that one or more consumers use. Data can be sent in response to a request (pull) or without one (push).

2. Communication protocols: CANopen services support tasks such as device management, configuration, and real-time data transfer.

3. Device states: Nodes can be in states such as pre-operational, operational, or stopped. Network-management commands can start, stop, or reset devices.

4. Object Dictionary (OD): Each node has a standardized collection of parameters that describes its configuration and behavior.

5. Electronic Data Sheet (EDS): A vendor-provided file describing a device’s OD structure and objects.

6. Device profiles: Standard profiles, such as CiA 401 for I/O modules and CiA 402 for motion control, define common device behavior to support interoperability.

CANopen identifiers and services

CANopen uses an 11-bit CAN identifier called the Communication Object Identifier (COB-ID). In the standard allocation described, it combines a function code with a node ID. The COB-ID indicates the communication service and the relevant node. For example, a transmit SDO for node 5 uses COB-ID 585.

The video outlines seven CANopen service types:

• Network Management (NMT): Controls node states, including starting, stopping, and resetting devices.
• Synchronization (SYNC): Coordinates actions such as sampling inputs or updating outputs across devices.
• Emergency (EMCY): Reports serious device errors to the network.
• Timestamp (TIME): Distributes global date and time information.
• Process Data Object (PDO): Transfers real-time operational data.
• Service Data Object (SDO): Reads or changes entries in a node’s Object Dictionary.
• Node monitoring (Heartbeat): Indicates that a node is alive and helps confirm its network state.

Object Dictionary, EDS, and DCF

The Object Dictionary is a standardized structure of device parameters. Each entry is identified by a 16-bit index and an 8-bit subindex. Entries can describe items such as a device name, configuration setting, or operating parameter. They also have attributes such as data type, access permissions, and whether the entry is mandatory or optional.

An EDS is a human- and machine-readable template describing a device’s objects, typically supplied by the manufacturer. When an integrator adds site-specific values or configuration to that template, the result is a Device Configuration File (DCF). The DCF helps prepare a device for use in a particular network.

SDO: Configuration and access

An SDO lets one node access another node’s Object Dictionary over the CAN network. It uses a client/server model:

• An SDO client initiates communication with a specific SDO server.
• An SDO upload reads an object; an SDO download writes one.
• An NMT master may act as the client when reading or changing the ODs of slave nodes.

SDOs are flexible but have communication overhead: requests and responses include control and addressing information, leaving less room for payload. This makes them less suitable for frequent real-time data exchange.

PDO: Efficient real-time data

PDOs are designed to carry operational data efficiently between nodes, such as measured pressure, temperature, position, or torque commands.

• A producer sends data in a Transmit PDO (TPDO).
• A node can receive data in a Receive PDO (RPDO).
• A PDO can carry up to eight data bytes, potentially combining several parameter values in one CAN frame.
• PDO transmission may be triggered by a SYNC message or configured to occur in other ways.
• Consumers need to know how the PDO’s bytes map to the relevant parameters.

Compared with SDOs, PDOs avoid much of the request-and-response overhead, making them better suited to real-time traffic. The video compares PDO mappings to J1939 parameter groups containing multiple signals, while noting that CANopen PDO mappings are often configurable.

CANopen data logging use cases

Logging CANopen traffic can support:

• Analysis of machine operating data.
• Remote monitoring and, in some cases, over-the-air SDO access.
• Monitoring warehouse vehicles such as electric forklifts and automated guided vehicles, including battery state of charge.
• Predictive maintenance by identifying conditions that may lead to equipment failures.
• Black-box diagnostics for investigating rare faults or documenting events in disputes between equipment manufacturers and users.

Speakers and sources featured

• Speaker: An unnamed narrator presenting the tutorial on behalf of CSS Electronics; no other individual speakers are identifiable in the subtitles.
• Standards and technical references: CANopen standards from CAN in Automation (CiA), including CiA 306, CiA 401, and CiA 402; ISO 11898 for CAN; and J1939 as a comparison.
• Other sources and materials: Vendor-provided EDS files, the CANopen introductory article, and CANedge CAN bus data loggers.