CANopen

What it is

CANopen is a CAN-based communication system. In the words of CAN in Automation (CiA), it comprises higher-layer protocols and profile specifications. SMB TECHNICS is a CiA member; the definitions on this page follow that organisation's own publications.

Understanding CANopen means separating two layers. Underneath sits CAN: a short-frame, multi-drop, electrically robust serial bus. On top sits CANopen itself — the body of rules describing how devices recognise one another, how data is addressed and how a drive is expected to behave. Connecting a drive to CANopen is not merely landing a cable; it is adopting a shared device model.

At the centre of that model is the object dictionary. CiA 301 — in the organisation's words, the CANopen application layer and communication profile — specifies the data types, encoding rules and object dictionary objects. On the drive side the CiA 402 series takes over: the CANopen device profile for drives and motion control.

How it works

Two kinds of traffic exist on a CANopen network, and keeping them apart is the key to predicting how a system will behave.

The first is process data: PDOs, Process Data Objects. These are the short, pre-mapped messages a drive exchanges every cycle — target position, actual position, status word, control word. PDO mapping is decided during commissioning, so at run time the meaning of every byte is already fixed. The message stays small and the overhead low.

The second is parameter access: SDOs, Service Data Objects. These read and write any parameter in the object dictionary by addressing it explicitly — gain settings, limits, mode selection. SDO is far more flexible, but it is not a per-cycle mechanism: PDO for process data, SDO for configuration.

On data rate, CiA's own statement is unambiguous: CANopen CC bit timing is specified in CiA 301 and allows the adjustment of data rates from 10 kbit/s to 1000 kbit/s. In practice the rate you can use is judged together with the physical length of the bus; the longer the bus, the lower the achievable rate. That is not a defect of CANopen but the nature of a serial bus, and it belongs in the machine design rather than in a surprise during commissioning.

The practical consequence is this: total cycle time on a CANopen network is directly related to how many PDOs must be carried each cycle. As the axis count rises, the same bandwidth is shared among more messages and the cycle time grows. This does not make CANopen “slow”; it means it scales differently.

Commissioning has one concrete convenience: device descriptions travel as EDS files. A configuration tool reads the EDS file and learns the drive's object dictionary, its PDO options and its parameter ranges, instead of having them typed in by hand.

When to choose it

CANopen remains the sound choice on machines with a moderate axis count where the cycle-time budget is not squeezed into microseconds. It is electrically robust, the wiring is simple, and because it has been in the field for many years both the commissioning tools and the engineering knowledge are widespread.

Another strength is that drives can share one bus with other classes of device: CANopen was built as a system for a family of devices, not for a single product type.

Against that, on applications demanding many tightly synchronised axes — contouring, electronic cam, coordinated kinematics — the binding constraint is bandwidth, and there EtherCAT's scaling behaviour fits better. The question is never “which is better” but “what is this machine's cycle budget”.

At SMB

In the SMB catalogue CANopen is represented by variants of the SD-LP and SDE series. The fact that the SD-LP family offers the same drive in CANopen, EtherCAT and Modbus RTU variants matters here too: a machine built on CANopen can move to EtherCAT within the same family when tighter synchronisation is needed later.

For commissioning, EDS files are published in the SMB download centre. These are the device descriptions your configuration tool needs in order to recognise the drive, and they can be downloaded directly.

The product list below is generated live from the CANopen node of the catalogue; it is never typed into the page.

Common questions

Should I use PDO or SDO? Both, for different jobs. Process data that repeats every cycle — target position, actual position, status and control words — travels as PDOs: pre-mapped, short, low overhead. Parameters such as gains, limits and mode selection are read and written from the object dictionary with SDOs. Putting SDO traffic inside the cycle is the most common cause of performance trouble on CANopen networks.

Which data rate should I pick? In CiA's own words, CANopen CC bit timing is specified in CiA 301 and allows the adjustment of data rates from 10 kbit/s to 1000 kbit/s. The choice is made together with the physical length of the bus: the longer the bus, the lower the achievable rate. The sound order of work is to settle the real topology of the machine first and choose the rate second.

What is an EDS file, and do I really need one? The EDS is the drive's device description: your configuration tool reads it and learns the object dictionary, the PDO options and the parameter ranges. You can work without one, but then every object has to be entered by hand — slow, and easy to get wrong. The EDS files published in the SMB download centre can be downloaded directly.

What is the difference between CiA 301 and CiA 402? CiA 301 is the CANopen application layer and communication profile; it specifies the data types, encoding rules and object dictionary objects — how devices speak. CiA 402 is the device profile for drives and motion control — what a drive says and how it behaves. One is the grammar, the other the vocabulary.

What happens as the axis count rises? The same bandwidth is shared among more PDOs and the cycle time grows. That is scaling behaviour, not a defect; when the cycle budget starts to bind, the right move is to change the field layer rather than to push CANopen harder.