CANopen is an open higher-layer communication protocol built on the CAN — Controller Area Network — data-link technology. It adds standardized communication services, device profiles and an Object Dictionary so that industrial devices can exchange process data, parameters, diagnostics and network-management information in a structured way.

In simple terms: CAN defines how messages are transported and arbitrated on the bus; CANopen defines what many of those messages mean and how industrial equipment should expose its data. This is why CANopen is widely used with PLCs, remote I/O, servo drives, VFDs, encoders, measuring devices and motion-control equipment.

What is the difference between CAN and CANopen?

Basic CAN defines frame transmission, identifiers, arbitration and error handling. It does not define that a certain object represents motor speed, encoder position or an acceleration parameter.

CANopen adds an application layer and communication profile on top of CAN. The core CANopen application layer and communication profile are specified by CiA 301.

A device marked only as “CAN” should therefore not automatically be assumed to support CANopen. Two products can use the same CAN_H/CAN_L physical bus and still use completely different higher-level message structures.

What is the CANopen Object Dictionary?

The Object Dictionary is the central data structure of a CANopen device. Communication parameters, device identity, process variables, configuration values and diagnostics are organized as addressable objects.

Each object is generally identified by a 16-bit index and, where required, an 8-bit sub-index. This gives the controller a standardized method for accessing device information.

Common CANopen communication objects are primarily located in the 1000h–1FFFh range. The 2000h–5FFFh area can be used for manufacturer-specific application objects, while standardized device-profile objects commonly occupy the 6000h–9FFFh area.

This structure allows a controller or engineering tool to address a parameter by index/sub-index rather than relying on an undefined proprietary byte sequence.

What is a CANopen Node-ID?

CANopen nodes normally use a unique Node-ID from 1 to 127. The Node-ID is used in many predefined communication-object identifiers and network-management functions.

Two active devices using the same Node-ID can create communication conflicts. Depending on the product, the Node-ID can be configured through rotary switches, DIP switches, engineering software or LSS — Layer Setting Services.

The CANopen Node-ID should not be confused with the raw CAN identifier. CANopen uses Node-ID values as part of its standardized communication model, while the underlying CAN frame still uses CAN identifiers for bus arbitration.

What is PDO in CANopen?

PDO — Process Data Object is used to transfer time-sensitive process data with low protocol overhead.

For example, a servo drive can transmit its Statusword and actual position through a TPDO, while receiving a Controlword, target velocity or target position through an RPDO.

TPDO — Transmit PDO carries process data produced by a device.
RPDO — Receive PDO carries process data consumed by a device.

Which Object Dictionary entries are transferred inside a PDO is defined by PDO mapping. This mechanism is especially useful in distributed I/O and motion-control applications where cyclic process data needs to be transferred efficiently.

What is SDO in CANopen?

SDO — Service Data Object is used to read or write entries in a device's Object Dictionary.

PDO communication is generally optimized for regular process data, while SDO is well suited to configuration, commissioning, diagnostics and parameter access.

For example, a VFD may receive its real-time speed command through a PDO, while an acceleration time, motor parameter or communication setting is read or changed using an SDO service.

CANopen supports several SDO transfer mechanisms for different data sizes, including expedited, segmented and block transfers.

What is CANopen NMT?

NMT — Network Management controls the operating state of CANopen nodes. The basic device states are:

Initialization
Pre-operational
Operational
Stopped

After startup, a node normally finishes initialization and enters the Pre-operational state. Configuration services such as SDO communication can be used, but normal PDO process communication is not yet active.

In the Operational state, normal supported CANopen process communication becomes available. The Stopped state significantly restricts normal application communication.

This matters during commissioning: a device can be visible on the CAN network but still fail to exchange the expected PLC process data simply because it has not been switched to Operational state.

What are Boot-up and Heartbeat messages?

After initialization, a CANopen node can transmit a Boot-up message to indicate that it has completed startup.

Heartbeat messages are transmitted periodically so that other devices can monitor whether a node is still alive and determine its current NMT state.

This is useful in distributed PLC, I/O and drive systems because the controller can detect when a remote device loses power or disappears from the network.

Older CANopen installations may also use Node Guarding, although Heartbeat is the more commonly recommended approach for current implementations.

What is an EMCY message?

EMCY — Emergency is a high-priority CANopen communication object used by a device to report an important fault or diagnostic event.

For example, a servo drive may report overcurrent, encoder loss or DC-bus faults through its CANopen diagnostic mechanisms. A HMI can display the resulting fault status to the operator.

The same diagnostic information can be collected by a SCADA system through the PLC or communication gateway for alarm history and maintenance analysis.

What is SYNC in CANopen?

SYNC provides a common communication reference that CANopen devices can use to coordinate synchronous process-data transmission.

This can be useful for distributed I/O and selected servo applications where several devices need to update process values relative to the same communication event.

What is a CANopen EDS file?

EDS — Electronic Data Sheet is a device-description file that tells configuration software which Object Dictionary entries, data types and communication capabilities are supported by a CANopen device.

EDS files are useful when adding third-party drives, I/O devices, encoders or measuring equipment to a CANopen controller.

CiA also defines a DCF — Device Configuration File format for describing configured device settings.

What are CANopen device profiles?

One of the strongest parts of CANopen is its collection of standardized device profiles. A profile defines common application objects and behaviour for a particular class of automation equipment.

CiA 401: Digital and analog I/O devices.
CiA 402: Drives and motion-control devices.
CiA 404: Measuring devices and closed-loop controllers.
CiA 406: Encoders.
CiA 442: Motor starters.
CiA 453: Power supplies.

These profiles create natural links between CANopen and real field equipment: sensors and measuring devices, encoders, servo systems, frequency inverters, power supplies and intelligent motor-control equipment can all have standardized CANopen application models.

Why is CiA 402 important?

CiA 402 is the CANopen profile family for drives and motion control. It applies to servo controllers, frequency inverters and stepper-motor control equipment.

It defines concepts such as Controlword, Statusword, drive states and standardized operating modes for torque, velocity and position control.

This can simplify integration between a compatible controller and different brands of servo drive or VFD because the basic drive state machine and object structure follow a standardized model.

Compatibility should still be checked carefully. Two CiA 402 devices do not necessarily implement every optional operation mode or manufacturer-specific object in the same way.

How is CANopen used with encoders?

CiA 406 defines the CANopen device profile for linear and rotary encoders, including process values such as position and other encoder-specific parameters.

A CANopen absolute encoder sends position information digitally through CAN messages. This is fundamentally different from a conventional incremental encoder producing A/B/Z pulses.

When selecting an encoder, mechanical size and resolution are therefore not the only considerations. The encoder output and communication type must match the controller.

TTL, HTL or RS-422 A/A− and B/B− signals are electrical pulse interfaces; CANopen is a digital fieldbus protocol carrying structured position information.

How is CANopen used with sensors and measuring devices?

CANopen is not limited to motor-control applications. CiA 404 covers measuring devices and closed-loop controllers used for physical variables such as temperature and pressure.

An intelligent pressure, load, temperature or position sensor can publish process measurements through PDOs while configuration and calibration parameters remain accessible through SDOs.

This allows measurement devices to be integrated with PLC and control systems without converting every process value into a separate 0–10 V or 4–20 mA signal.

Can CANopen be used with power supplies?

Yes. CiA 453 defines a CANopen device profile for power supplies and power converters.

A compatible power system can expose operating status, voltage, current and diagnostic parameters through standardized CANopen objects. This is useful in distributed machine electronics, test systems and equipment requiring centralized DC-power monitoring.

Can CANopen be used with motor starters and switchgear?

The CANopen profile family also covers motor starters and other energy-related equipment. CiA 442, for example, specifies a profile for IEC 61915-2-compatible motor starters.

This allows intelligent motor starters and selected switchgear and protection devices to provide status and diagnostic information to the control system rather than operating only as isolated hardwired components.

Is CANopen used in robotics?

Yes. CANopen can be found in mobile robots, AGVs, auxiliary axes, grippers and other industrial robotics subsystems.

CiA has also defined profiles for service-robot control systems. A machine or robot can use a faster dedicated network for its main synchronized servo axes while using CANopen for peripheral motors, sensors or auxiliary mechanisms.

Which bit rates and bus lengths are used with CANopen?

For classic CANopen CC networks, CiA provides the following common bit-rate and approximate maximum bus-length combinations:

1 Mbit/s: 25 m
800 kbit/s: 50 m
500 kbit/s: 100 m
250 kbit/s: 250 m
125 kbit/s: 500 m
50 kbit/s: 1000 m
20 kbit/s: 2500 m
10 kbit/s: 5000 m

Actual usable distance also depends on cable characteristics, transceivers, oscillator tolerance, topology and stub lengths. Higher bit rates require shorter physical networks because signal-propagation delay becomes increasingly important.

How is a CANopen network terminated?

A typical high-speed ISO 11898-2 CANopen network should use a linear bus with approximately 120 Ω termination at both physical ends of the main trunk.

Termination resistors should not be fitted at every node. Long star branches and excessive stubs can create reflections, especially at higher bit rates.

Device power also needs to be checked separately. The CAN_H/CAN_L data pair does not automatically provide operating power to the PLC, drive, encoder or sensor. Industrial nodes often receive their supply from a separate 24 VDC power system.

Is there a universal CANopen C API?

No. CANopen does not define universal C functions called `canopen_init()`, `canopen_send()` or `canopen_close()`.

The software interface depends on the actual microcontroller, operating system, CAN controller, PLC and CANopen protocol stack being used.

A request such as “send value 1000 to Node-ID 5” is also incomplete from a CANopen point of view. The application first needs to define which Object Dictionary index/sub-index represents that value and whether it should be transferred through PDO or SDO communication.

In a PLC system, the CANopen master/controller is commonly configured through engineering software. PDO objects are mapped into controller variables, while SDO services are accessed through vendor-provided communication blocks or libraries.

What is CANopen FD?

CANopen FD is the newer CANopen application and communication profile operating on the CAN FD data-link layer. Its core profile is specified in CiA 1301.

Because CAN FD provides a larger frame payload than Classical CAN, CANopen FD can transfer more application or service data within one frame and can improve efficiency in modern embedded-control applications.

CiA is also extending device profiles for CANopen FD, including I/O and drive/motion applications.

What is CANopen Safety?

Ordinary CANopen communication is not automatically a certified functional-safety protocol. Safety-related CANopen communication is defined separately through CANopen Safety.

A normal PDO containing a stop bit should therefore not automatically be treated as an emergency-stop safety channel. Machine safety still requires appropriate safety controllers, safety I/O, certified drive functions and the relevant machine-safety architecture.

Why does a CANopen network fail to communicate?

Start with the physical CAN bus: check CAN_H/CAN_L polarity, cable continuity, the two end terminators and power to every node.

Next verify that all devices use the same bit rate and that every active node has a unique Node-ID.

If a device remains in Pre-operational state, normal PDO process data may not appear. Check NMT state, Boot-up and Heartbeat messages.

If PDO communication exists but the values are wrong, inspect PDO mapping and the relevant Object Dictionary index/sub-index values.

If a servo drive or VFD is online but will not run, check the CiA 402 state machine, Controlword, Statusword and selected operating mode.

In cabinets containing large drives, contactors and switchgear, also inspect CAN cable routing, shielding and grounding. A communication fault can be created by poor EMC practice even when software settings are correct.

Practical CANopen troubleshooting checklist

1. Are CAN_H and CAN_L connected correctly?

2. Is the main bus terminated at both physical ends?

3. Are all devices configured for the same bit rate?

4. Does every node have a unique Node-ID from 1 to 127?

5. Is the device in NMT Operational state?

6. Are Boot-up and Heartbeat messages visible?

7. Is PDO mapping consistent with the Object Dictionary?

8. On CiA 402 drives, are Controlword, Statusword and operating mode correct?

Related CAN and Industrial Communication Guides

CAN Communication · Industrial Communication · EtherCAT · Modbus

Related Field and Automation Pages

PLCs · HMI Panels · SCADA · Sensors · Encoders · Encoder Output Signals · Servo Systems · Motion Control · Industrial Robotics · AC Drives and VFDs · Power Supplies · Switchgear · Controllers