CANopen Explained: Object Dictionary, PDO, SDO, NMT

This article is part of the CAN & CANopen family. If you're new to CAN start with CAN Bus Protocol Explained (arbitration, frames, errors), or the CAN wiring and termination guide for physical-layer rules. For the full family landing with links to CANopen, J1939, DeviceNet, and CAN FD, visit the CAN & CANopen category hub.

CAN gives you frames, arbitration, and error handling — and nothing else. It says nothing about what an identifier means, how to configure a device, or how to move more data than fits in eight bytes. CANopen fills that gap, and it does so with one idea at the centre: every device is a table.

That table is the object dictionary. Configure a device, and you are writing to it. Read a sensor, and the value came from it. Map process data, and you are describing which rows of the table go on the wire. Understand the object dictionary and the rest of CANopen — SDOs, PDOs, heartbeat, device profiles — falls into place as different ways of reaching it.

This guide is based on CiA 301, the CANopen application layer and communication profile maintained by CAN in Automation (CiA), internationally standardized as EN 50325-4.

The object dictionary: the interface between application and network

The standard's own description is precise: the object dictionary is the interface between the application and the communication sub-system. It is a collection of the device's parameter data structures, and it holds three kinds of thing — parameters, application data, and the mapping information that says which application data travels as process data.

Every entry is reached by a 16-bit index and an 8-bit sub-index. That pair is called a multiplexor. Index selects the object; sub-index selects a member within it. So 0x6041 / 0x00 is a specific entry in a specific device, and any CANopen tool can reach it without knowing anything else about the hardware.

The dictionary is divided into defined areas:

The split matters when you are reading a device's documentation. Communication-profile entries behave identically across every CANopen device ever made. Device-profile entries are identical across every device of that type. Manufacturer entries are identical across nothing — they are where vendors put what the profiles didn't anticipate.

Two ways to move data, and they are not interchangeable

CANopen has two main mechanisms for transferring application data: SDO and PDO. Choosing correctly between them is most of what CANopen design consists of. Alongside these sit the supporting communication services — NMT, SYNC, EMCY, TIME and the error-control protocols — covered further down.

SDO — the configuration channel

Service Data Objects access the object dictionary directly. Object entries in remote dictionaries can be read or written — the standard calls these upload and download — using the index and sub-index to address any entry.

SDO communication is client-server, point-to-point between two devices, and confirmed: every SDO message is acknowledged by an appropriate SDO message. It is not fast, and it is not meant to be. This is the channel for setting a motor's acceleration ramp, reading a serial number, or downloading a configuration at startup.

Two transfer modes exist, and the distinction is about payload size:

Expedited transfer. For small amounts of data, the value travels directly in the initialization phase and the exchange ends with the server's acknowledgement. One round trip, done.

Normal transfer. For larger data, the initialization phase carries no data at all. It exists to confirm that both ends are ready. Only after that acknowledgement does the actual data transfer phase begin.

Errors get their own mechanism. The SDO abort service is unconfirmed and records any SDO communication error, returning the reason to the client. An abort code in a commissioning log is CANopen telling you precisely which access failed and why — usually a wrong index, a read-only entry, or a device in the wrong state.

PDO — the process data channel

Process Data Objects carry the values that matter every cycle: positions, speeds, I/O states, setpoints. They are producer-consumer, unconfirmed, and carry no addressing overhead at all — a PDO is just data, and both ends already know what it means because the mapping was configured beforehand.

That prior agreement is the PDO mapping. The mapping objects hold lists of object references together with length information, describing which entries from the object dictionary are packed into the PDO and in what order.

The mapping structure can describe multiple application objects, but a classic CANopen PDO is ultimately limited by the 8-byte CAN payload. The specification's upper bound on mapping entries refers to how many application-object mappings the structure can express — not to 254 objects physically fitting into one classic PDO. In practice you are packing bits and bytes into eight, and that is the constraint that bites.

Each PDO also carries communication parameters separate from its mapping. PDO transmission is controlled by these parameters and by the transmission type. Depending on the configuration, a PDO can be transmitted synchronously with SYNC, periodically, or in response to an event.

The transmission type field encodes more detail than those three words suggest — particularly for synchronous PDOs, where it can specify transmission on every SYNC or on every nth SYNC. Read the device's documentation for the exact values it supports.

The mapping-versus-communication split is worth internalizing, because it is the source of a common confusion. Mapping parameters say what is in the PDO. Communication parameters say when it is sent. They are configured separately, in different objects, and a PDO that appears not to work often has correct mapping and a transmission type nobody set.

Choosing between them

The rule is simple and rarely violated once understood: SDO for anything you do occasionally, PDO for anything you do every cycle.

Using an SDO to read a position in a control loop works, and it is the classic beginner mistake — the confirmed round trip and the object-dictionary addressing overhead cost far more than the same value arriving as three bytes of a PDO. Conversely, mapping a rarely-changed configuration parameter into a PDO wastes bus bandwidth on every cycle for data nobody reads.

NMT: controlling node states

Every CANopen node runs a state machine, and network management (NMT) controls it. An NMT master commands transitions; each node reports and obeys. CiA 301 defines four states:

Initialisation. The node powers up, sets its object dictionary to default or stored values, and moves on automatically. Nothing is communicating yet.

Pre-operational. SDO communication works. This is where configuration happens — writing parameters, setting up PDO mapping, adjusting communication parameters. PDOs do not transmit in this state.

Operational. Everything works. PDOs transmit and are received, SDOs still function, and the node is doing its job.

Stopped. The node is largely silent. It accepts NMT commands and the error-control protocols, but normal communication is halted — used to take a device out of service without powering it down.

The practical consequence catches out nearly everyone new to CANopen: a node that is not Operational will not send PDOs. The classic symptom is a network where every SDO read works perfectly, the configuration looks correct, and no process data ever arrives. The nodes are sitting in pre-operational because nobody sent the NMT command to start them.

That state dependency is also why the standard commissioning sequence runs: bring nodes up, configure over SDO in pre-operational, then command Operational and expect PDOs to start.

SYNC: a common timing reference

SYNC provides the shared timing reference for synchronous CANopen communication. A SYNC producer periodically sends synchronization messages, allowing nodes to coordinate when synchronous PDOs are produced or consumed.

The reason this matters is sampling. Without SYNC, each node samples its inputs and applies its outputs on its own schedule, so a "simultaneous" reading across ten devices is actually spread across whatever their timers happened to do. With SYNC, inputs are captured and outputs applied in step with the SYNC message.

For distributed motion and coordinated I/O, that is the difference between axes that move together and axes that nearly move together. It is also why SYNC configuration appears in every multi-axis CANopen commissioning checklist.

Device monitoring: heartbeat and EMCY

Two mechanisms tell a CANopen network what its devices are doing.

Heartbeat is the life-sign. Devices monitor each other: heartbeat producers generate life-signs, and heartbeat consumers receive them. What makes it flexible is that a consumer configures in its own object dictionary which producers it wants to monitor. If an expected heartbeat fails to arrive, a heartbeat event is generated at the consumer.

That design means monitoring is not centralized. A safety-relevant node can watch the two devices it depends on without the master being involved, and each device decides what it cares about.

EMCY — the emergency object — is the exception report. Emergency messages are triggered by the occurrence of a device internal error situation, and they are producer-consumer like PDOs: the failing device announces its problem to whoever is listening, rather than waiting to be polled.

The combination covers both failure modes. Heartbeat detects loss of communication; EMCY reports an internal device or application error while the node is still able to communicate. Neither replaces the other, and a well-designed CANopen network uses both.

Device profiles: why CANopen devices are interchangeable

This is one of CANopen's strongest features and a major reason it is widely used in machine automation.

The standard puts it plainly: device profiles are one of the core elements of CANopen, specifying uniform functions and standardized parameters and objects for different application areas or device groups. Because of these profiles, a great degree of vendor compatibility is achieved through interoperability and interchangeability of devices from different manufacturers.

Profiles already exist for the major device types used in automation engineering:

• Digital and analogue I/O devices
• Drives
• Valves
• Programmable controls
• Encoders

The practical consequence: a drive implementing the standard drive profile exposes the same object indices for the same functions as any other drive implementing it. Control word, status word, target position, actual velocity — same index, same meaning, different vendor. Swapping a drive for a competitor's does not necessarily require rewriting the control code.

"Not necessarily" is doing real work in that sentence. Vendors add manufacturer-specific objects alongside the profile, and applications that use them lose portability. The profile guarantees the standard parts behave identically; it guarantees nothing about the extras.

What CANopen inherits from CAN

CANopen sits on the CAN data link layer, so everything in the CAN bus protocol guide applies underneath it: identifier-based arbitration, dominant-over-recessive, error counters and bus-off, and the eight-byte classic frame limit that PDO mapping is designed around.

Two inherited properties shape CANopen design directly.

Identifier priority is real priority. Because CAN arbitration favours lower identifiers, the identifiers assigned to a device's PDOs determine what wins the bus during a busy moment. Emergency messages, synchronization, and critical process data get low identifiers by convention for exactly this reason.

Wiring rules are CAN's rules. Termination, stub lengths, and speed-versus-distance come straight from the physical layer — see the CAN wiring and termination guide. A CANopen network with a missing terminator behaves exactly like any other CAN network with a missing terminator: it mostly works, until it doesn't.

Where CANopen fits

CANopen is the machine-automation member of the CAN family. It appears in medical devices, laboratory equipment, off-highway vehicles, maritime systems, lifts, and — most visibly — motion control, where standardized drive profiles such as CiA 402 are widely used.

Compared with its siblings:

Versus J1939: J1939 standardizes message content through parameter group numbers, with a fixed catalogue of signals. CANopen standardizes device structure through the object dictionary and lets profiles define meaning per device class. J1939 is strongly associated with commercial vehicles, engines, and vehicle networks, while CANopen is widely used in machines and embedded control systems.

Versus DeviceNet: both are CAN-based device buses with object models. DeviceNet uses CIP objects and carries 24 V power on the same cable, and is closely associated with Rockwell Automation and CIP-based industrial networks. CANopen has no bus power in the base specification but a far broader device-profile catalogue and a wider vendor base outside North America.

Commissioning notes

A short list of things that catch people out.

Configuration order matters. PDO mapping generally cannot be changed while the PDO is active. The pattern is: disable, remap, re-enable. Tools handle this automatically; hand-written masters often do not.

A silent PDO usually has a communication-parameter problem. Check the transmission type, the inhibit and event timers, SYNC configuration, whether the PDO is enabled, and — first of all — whether the node is actually in the Operational state. Mapping and communication parameters are separate objects, so a perfectly mapped PDO can still be one nobody told when to transmit.

Read the abort code. SDO aborts carry the reason for failure. That code is more informative than any amount of guessing, and it distinguishes "wrong index" from "object is read-only" from "device is in the wrong state."

Heartbeat is configured on the consumer. If a device is not being monitored, look at the watcher's object dictionary, not the watched device's.

Manufacturer objects are portability debt. They work, they are legitimate, and every one you use ties the application to that vendor. Know which you are relying on.

FAQ

What is the CANopen object dictionary?

The interface between a device's application and the network — a table of all its parameters, application data, and PDO mapping information. Every entry is addressed by a 16-bit index and an 8-bit sub-index, and all configuration access goes through it.

What is the difference between SDO and PDO?

SDO is confirmed client-server access to individual object dictionary entries, addressed by index and sub-index — used for configuration and diagnostics. PDO is unconfirmed producer-consumer transfer of pre-mapped process data with no addressing overhead — used for cyclic real-time values. SDO for setup, PDO for running.

What is PDO mapping?

The configuration that says which object dictionary entries are packed into a PDO and in what order. Mapping objects hold lists of object references with length information. The mapping structure can describe multiple application objects, but a classic CANopen PDO is limited by the 8-byte CAN payload — that, not the mapping-entry count, is the practical constraint.

What are the CANopen NMT states?

Initialisation, pre-operational, operational, and stopped. SDO communication works in pre-operational, which is where configuration happens. PDOs only transmit in operational — so a node left in pre-operational answers every SDO read while sending no process data at all.

What is SYNC used for?

Providing a shared timing reference. A SYNC producer sends periodic synchronization messages so nodes coordinate when synchronous PDOs are produced or consumed, meaning distributed devices sample inputs and apply outputs in step rather than on independent timers.

What is the difference between expedited and normal SDO transfer?

Expedited transfer carries small data directly in the initialization phase — one exchange and done. Normal transfer sends no data during initialization; it confirms both ends are ready, then the actual data transfer phase follows. Payload size decides which is used.

What is CANopen heartbeat?

A monitoring mechanism where producers emit periodic life-signs and consumers watch for them. Each consumer configures in its own object dictionary which producers to monitor, and generates a heartbeat event if one fails to arrive.

What is an EMCY message?

An emergency object, triggered by a device-internal error situation and broadcast producer-consumer style. It is how a failing device announces a problem rather than waiting to be asked. Heartbeat catches a device that went quiet; EMCY catches one that is still running but faulted.

Are CANopen devices from different vendors interchangeable?

For the parts covered by a standardized device profile, largely yes — that is the point of profiles, and the standard cites interoperability and interchangeability as the goal. Vendors also add manufacturer-specific objects, and any application depending on those loses portability.

Is CANopen the same as CAN?

No. CAN is the data link layer — frames, arbitration, error handling — and specifies nothing above it. CANopen is an application layer built on CAN, adding the object dictionary, SDO and PDO communication, device monitoring, and standardized device profiles.