What is CANopen? CAN bus with a common language
CAN moves frames between devices but says nothing about what they mean. CANopen is the layer on top that gives those frames a shared structure, so a drive, a sensor and an I/O module from different makers can work together without custom glue. Here is what it adds and how the pieces fit.
CANopen is a higher-layer protocol that runs on top of CAN and gives every device a shared way to be addressed, configured and monitored. CAN itself only carries frames and decides which frame wins the bus. It says nothing about what a device is, what settings it holds or how to read them. CANopen fills that gap with a standard map of each device, a fixed scheme for message identifiers and a small set of services for moving data and managing the network. The payoff is interoperability: kit from different vendors can share one network without bespoke code for each part.
| Concern | Raw CAN | CANopen |
|---|---|---|
| What it defines | how frames are sent and arbitrated | what those frames mean in a system |
| OSI layers | physical and data link | the layers above, up to application |
| Addressing | identifiers chosen per project | node IDs and a predefined ID scheme |
| Device description | none, you decide | an object dictionary, shared by EDS file |
| Configuration | custom, per device | standard services, even after install |
| Vendor mixing | needs bespoke glue | off-the-shelf interoperability |
| Typical setting | anything CAN based | machines, drives, medical, off-highway |
The problem CANopen solves
Plain CAN is flexible, which is also its weakness in a multi-vendor build. Two engineers can both follow the CAN standard and still produce devices that cannot talk to each other, because nothing fixes which identifier carries which value, how a setting is read or what state a device is in. On a project with one team that is fine. On a machine built from drives, sensors and controllers bought from different suppliers, every pairing would need its own custom code.
CANopen removes that work by standardising the parts CAN leaves open. Each device publishes a structured list of everything it exposes, identifiers follow a predefined scheme so they rarely clash, and a small set of services covers reading settings, streaming live values and starting or stopping nodes. With that shared model in place, a controller can configure a drive it has never seen before, as long as both follow CANopen. The developer does not have to deal with CAN details such as bit timing or acceptance filtering, since the protocol handles them underneath.
The idea is not new. A prototype grew out of the Bosch-led ASPIC project in the early 1990s, built on the earlier CAN Application Layer, and CAN in Automation published the CANopen profile in 1995. The core specification is CiA 301, also standardised in Europe as EN 50325-4. It was aimed first at motion-oriented machine control, which still shows in how much of the standard centres on drives and motors.
That heritage spread well beyond its first home. CANopen now turns up in industrial automation and machinery, motor drives of every size, robotics and conveyor lines, medical equipment such as X-ray generators and infusion pumps, off-highway and agricultural vehicles, railway systems, marine electronics, lifts and building automation. Wherever devices from several makers must cooperate predictably on a low-cost bus, it tends to appear.
The object dictionary
If one idea sits at the centre of CANopen, it is the object dictionary. Every device holds one. It is a structured table of everything the device exposes: its type, its settings, its live values and its diagnostics. Anything another device might read or change lives here, which is why the object dictionary, not the wiring, is where most CANopen work actually happens.
Each entry is found by a 16-bit index and an 8-bit sub-index, so the address of a value reads like a row and a column. The table is split into fixed ranges by purpose. Indices from 0x1000 to 0x1FFF hold communication parameters, the part that is common to all CANopen devices. The range from 0x6000 to 0x9FFF holds standardised device-profile entries, so the same value sits at the same place on every device of that class. Between them, 0x2000 to 0x5FFF is left for manufacturer-specific entries.
Those device profiles are what make parts interchangeable. CiA 401 describes generic input and output modules, CiA 402 describes motion control and drives, and there are many more. A controller that understands a profile can drive any compliant device, because it knows where each value will be. To save reading a device entry by entry, its object dictionary is shipped as an Electronic Data Sheet, a standard text file. An EDS does for a CANopen device what a DBC file does for raw CAN traffic, or an LDF for a LIN network: it tells a tool what is there and how to read it.
Devices are told apart by a node ID from 1 to 127, a 7-bit number assigned when the network is built. That single number, as the next section shows, also decides most of the message identifiers a device will use.
Communication objects and the COB-ID
Every message in CANopen is a communication object, or COB. Each one still travels in an ordinary CAN frame, so it carries an 11-bit identifier and up to eight data bytes. What CANopen adds is meaning. The identifier is split into a 4-bit function code, which says what kind of message it is, and a 7-bit node ID, which says which device it concerns. Together they form the COB-ID, the value that actually appears on the bus, and every COB-ID on a network must be unique.
Because CAN arbitration always lets the lowest identifier win, the function code also sets priority. Network management sits right at the top with function code 0 and COB-ID 0, so a command sent to every node beats ordinary traffic. Emergency messages rank high, live process data sits in the middle, and slower configuration traffic ranks below it.
To avoid assigning every identifier by hand, CANopen ships a predefined connection set. Once a device has a node ID, the default COB-ID for each of its messages follows by adding that node ID to a fixed base for the message type. The calculator works through exactly that split.
PDO, SDO and network management
Two services do most of the talking, and the difference between them is the single most useful thing to learn about CANopen. A Process Data Object, or PDO, carries live operational data. It is one CAN frame of up to eight bytes, broadcast from a producer to whoever is listening, with no reply. That makes it fast and light, which is what you want for values that change constantly, such as a motor's speed or the state of an input. What each byte means is fixed beforehand by a mapping held in the object dictionary, so no addressing overhead rides along with the data.
A Service Data Object, or SDO, is the opposite kind of exchange. It reaches into another device's object dictionary to read or write a setting, and it is confirmed: the client sends a request, the server sends a response, so every transfer is acknowledged. Two identifiers are used, one each way. An SDO can also move more than eight bytes by splitting the value across several frames. The trade is overhead and speed, which is why SDOs are used for configuration and occasional reads rather than for streaming. A short way to hold the two apart: PDO broadcasts a value with no reply, SDO asks a question and waits for the answer.
Sitting above both is network management, or NMT. One node acts as the NMT master and moves the others between states with a tiny two-byte message on COB-ID 0. The states are Initialisation, Pre-operational, Operational and Stopped. The detail that ties it back to the services is simple: SDOs work in Pre-operational and Operational, but PDOs flow only in Operational. So a controller typically configures a device with SDOs while it is pre-operational, then starts it to let the live PDO data begin. A boot-up message announces a device as it enters pre-operational, and a cyclic heartbeat lets the network confirm it is still alive.
Which object carries what?
Once the services make sense, choosing between them on a real network is mostly a matter of two questions: is this live data or a one-off, and is it about a device's values or the network's state? Live values that repeat go in PDOs. One-off reads and writes of settings go in SDOs. State changes, faults and liveness each have their own object. Work through a few common tasks below.
CANopen is CAN plus a shared rulebook. An object dictionary describes each device, a predefined scheme hands out identifiers, PDOs stream live data and SDOs read and write settings. That is what lets parts from different makers run on one bus without custom code.
CANopen FAQ
What is CANopen in simple terms?
It is a higher-layer protocol that runs on top of CAN. CAN moves the frames, and CANopen gives those frames a shared structure, so a device can be addressed, configured and monitored in a standard way. The point is interoperability: kit from different makers can share one network without bespoke code for each part.
What is the difference between CAN and CANopen?
CAN defines how frames are sent on the bus, how arbitration picks a winner and how errors are caught. It says nothing about what a device is or what its values mean. CANopen adds that layer, with object dictionaries, device profiles, a scheme for identifiers and a set of services. CAN is the road, CANopen is the rules of the traffic.
What is the object dictionary?
A standard table held in every CANopen device that lists everything it exposes, from settings to live values, each addressed by a 16-bit index and an 8-bit sub-index. It is the heart of CANopen. A device's object dictionary is shared as an Electronic Data Sheet, much as a DBC file describes raw CAN signals.
What is the difference between a PDO and an SDO?
A PDO broadcasts live operational data in a single frame with no reply, which makes it fast and suited to values that change constantly. An SDO reads or writes a setting in another device's object dictionary and is confirmed, with a request and a response. In short, a PDO sends a value, an SDO asks a question and waits for the answer.
How many nodes can a CANopen network have?
Up to 127, each given a node ID from 1 to 127. That node ID also sets the default identifiers for the device's messages through the predefined connection set, so much of the addressing follows automatically once the ID is assigned.
Can Influx Technology loggers record CANopen?
CANopen travels as ordinary CAN frames, so the data loggers from Influx Technology capture CANopen traffic at the CAN level for later analysis, alongside other CAN based protocols on the same network.
Written by the engineering team at Influx Technology. CANopen behaviour follows the CiA 301 specification. Confirm details against the specification for your devices.
Capture CANopen alongside the rest of your CAN traffic
The data loggers from Influx Technology record CAN networks to a standard format, capturing CANopen frames at the CAN level so they sit in the same log as everything else on the bus. The REXGEN and REBEL ranges cover the common channels, and REXDESK and DIALOG help you review what was recorded.
