CANopen is the application layer and set of device profiles that the CAN in Automation association defines on top of the CAN bus, standardised as EN 50325-4. Every node publishes its functionality in an object dictionary addressed by index and sub-index, and exchanges process data in PDO frames of up to eight bytes.
Where CANopen shows up on the plant floor
CANopen is rarely the network that spans a plant: it is the internal bus of a machine. You find it in drives and servos following the CiA 402 device profile, in electric axes, in mobile machinery (agriculture, construction, forklifts and industrial vehicles), in medical equipment and in subsystems of machines bought as a whole. The usual way to discover it is opening a machine cabinet and finding a two-wire bus with termination resistors at both ends linking the controller to its drives. Its appeal has not changed since the 1990s: cheap cabling, high electrical robustness, and profiles that make drives from different vendors parameterise in equivalent ways.
CANopen versus CAN
The most frequent confusion is not with another bus but with its own foundation. CAN, standardised in ISO 11898, defines only the physical and data-link layers: differential signalling, frame format, and the non-destructive bitwise arbitration by which the frame with the lowest identifier value wins the medium without collisions or retransmissions. CAN says nothing whatsoever about what those bytes mean. CANopen is the layer that supplies the meaning: it assigns identifiers to functions and nodes, defines the object dictionary where every parameter lives, and specifies the network management, synchronisation, emergency and heartbeat services a master uses to supervise bus state. Put differently, mutually incompatible protocols can be built on CAN; CANopen is one of them, and the usual one in European industrial automation.
Getting data out of a CANopen bus
CANopen has a property no master/slave bus shares: CAN is a multi-master broadcast medium where every node receives every frame. An interface configured in listen-only mode transmits not a single bit, not even the receive acknowledgement, so it can be attached to a bus in production without altering load or timing. For a data layer it is the least invasive capture route among all fieldbus protocols.
The work lies in interpretation. What arrives are frames of up to eight bytes whose identifier encodes function and node number; the payload is a flat block whose composition is defined by each device’s PDO mapping. That mapping comes from one of two places: the device description file plus the project configuration, or a live read of the object dictionary itself, since both the communication parameters and the mapping of every PDO are standardised, queryable entries. The second route is more reliable when the original integrator’s documentation is missing, which is the norm on machines with years of service.
Reading individual parameters requires the other channel, the SDO service, which is client/server and does transmit. Using it means occupying a free node address and adding bus load, so it is best confined to configuration and diagnostic reads rather than continuous sampling. The rate at which process data arrives is not the listener’s decision: the device sets it according to whether it is configured as event-driven, timer-driven or synchronised by the SYNC frame.
Two physical constraints decide whether the intervention needs a stop. The bus requires 120-ohm termination at both ends and short stubs: a badly made connection degrades the signal for the whole segment. And the bit rate must be set correctly on the device you attach, because a node in normal mode running at the wrong rate generates continuous error frames and can render the bus unusable. With a listen-only interface that risk disappears, since it cannot transmit. Bit rate also bounds length: roughly 25 metres at 1 Mbit/s against some 500 metres at 125 kbit/s.
Related terms
The CANopen object dictionary is reused as a mailbox protocol inside EtherCAT, and its role as a bus below the controller is comparable to PROFIBUS DP for I/O or IO-Link for the last stretch to the sensor. Captured data is normally normalised on an edge computing node before publication. At Captia Connect it is a case of heterogeneous systems interoperability: reading the internal bus of a machine without intervening in its control.