9 destinations
← CAN bus guides

August 27, 2026

CANopen Object Dictionary, SDO, PDO and NMT

Understand CANopen object-dictionary addressing, SDO configuration, PDO process data, NMT state and a reproducible capture checklist.

Build a reliable CANopen bench workflow by separating the object dictionary, SDO configuration, PDO process data and NMT state—then recording the exact EDS and device revision used.

Start with the CANopen device model

CAN in Automation describes a CANopen device as three logical parts: the CANopen protocol stack, the application software and the object dictionary between them. That separation is useful during troubleshooting because a valid CAN frame does not prove the application is in the expected state, and a correct parameter name does not prove the correct node answered.

1. Treat the object dictionary as the device contract

Each object-dictionary entry is addressed by a 16-bit index and an 8-bit sub-index. The dictionary holds communication parameters and application parameters, with standardized, manufacturer-specific and device-profile ranges.

Before querying a device, collect:

  • vendor, product code, revision and serial identity where available;
  • the matching EDS or DCF file and its source;
  • node ID and network bitrate;
  • expected NMT state;
  • which entries are safe to read and which writes require a controlled procedure.

An EDS from a related product may load successfully while describing different data types, limits or mappings. Match identity first.

2. Separate SDO configuration from PDO process traffic

Service Data Objects (SDOs) provide access to object-dictionary entries and are commonly used for configuration and inspection. Process Data Objects (PDOs) carry mapped process data with lower overhead for cyclic or event-driven communication.

When a value is missing from a PDO, do not immediately assume the sensor is absent. Check:

  • whether the PDO is enabled;
  • the transmission type and inhibit/event timing;
  • the current mapping entries;
  • the device’s NMT state;
  • whether another node already uses the same identifier.

Preserve the mapping before making changes. A mapping write can change the interpretation of every later capture.

3. Read NMT state as part of every observation

CANopen Network Management controls communication state. A node that is booting, pre-operational, operational or stopped can expose different communication behavior. Record boot-up and heartbeat traffic before investigating application PDOs.

A disciplined sequence is:

  1. power only the intended bench network;
  2. capture boot-up and heartbeat frames;
  3. confirm node ID and identity through an authorized tool;
  4. record NMT state;
  5. read the relevant communication and application entries;
  6. only then compare PDO traffic with the recorded mapping.

4. CANopen capture checklist

  • raw timestamped CAN log;
  • bitrate, cable topology and termination state;
  • node ID and identity values;
  • EDS/DCF filename, checksum or revision;
  • NMT state and heartbeat behavior;
  • SDO requests and responses, including abort codes;
  • PDO communication and mapping entries;
  • every write performed during the session.

If the bench contains motion, power conversion or other hazardous outputs, separate CAN observation from actuation and follow the equipment maker’s safe-state procedure.

Bring a specific CANopen case

The MallMars pilot targets a local CANopen inspection workflow, not universal device configuration. In a pilot request, name the device profile, EDS source, operating system, bitrate and whether you need read-only capture or controlled SDO access.

Primary reference