What Is a CANopen COB-ID?
When you first look at a CANopen trace, the raw CAN identifiers seem cryptic until you learn that CANopen assigns them by a simple, predictable scheme built from a function code and a node number. That scheme is the COB-ID, and knowing how it decomposes lets you read a CANopen bus at a glance and configure PDOs correctly. This page explains what a COB-ID is, how the predefined connection set derives default identifiers from the node ID, and why that structure matters when you map objects into a monitoring system.
CANopen COB-ID in one line: A COB-ID (Communication Object Identifier) is the CAN identifier CANopen assigns to each message, and in the standard predefined connection set it is built from a function code in the high bits plus the device's node ID in the low seven bits. That structure means the COB-ID tells you both what kind of message it is and which node it belongs to, so you can decode a CANopen bus directly from the identifiers.
How a COB-ID Encodes Node and Function
CANopen does not use raw CAN identifiers arbitrarily; it structures them. In the predefined connection set defined by the standard, an 11-bit COB-ID splits into an upper function-code field and a lower field carrying the seven-bit node ID, which ranges from 1 to 127. The function code says what class of communication object the message is, for example an emergency message, a particular transmit or receive PDO, an SDO, or a heartbeat, and the node ID says which device it concerns.
This is why CANopen default identifiers look regular on an analyzer. The node-management and emergency messages, the four default PDOs, the SDO channels, and the heartbeat each occupy a known function-code range, and within that range the low bits count off the node number. Once you internalize the split you can look at a bare identifier and immediately say both the message type and the node, without a lookup table, which is a genuine time-saver when reading a live bus.
The Predefined Connection Set and Its Limits
The predefined connection set exists so that a simple network works out of the box: assign each device a unique node ID and its default COB-IDs fall into place automatically, giving every node its standard PDOs, SDO, heartbeat, and emergency identifiers with no manual identifier assignment. For many machines that default mapping is all you ever need, and it is why CANopen commissioning can be so quick when node IDs are set correctly.
The defaults have limits, though. The predefined connection set gives each node only a handful of default PDOs, so a device that needs to publish more process data, or a network that wants a custom producer-consumer mapping, reconfigures COB-IDs explicitly through the communication parameters in the object dictionary. When you remap a PDO to a non-default COB-ID, you are overriding the predefined scheme, and both the producing and consuming nodes must agree on the new identifier.
Because a COB-ID is ultimately a CAN identifier, its numeric value also sets the message's priority through CAN arbitration. The function-code layout is arranged so that time-critical CANopen objects get lower identifiers and therefore higher priority, which is another reason not to reassign COB-IDs casually: an ill-chosen custom identifier can invert the intended priority and let housekeeping traffic outrank real-time data.
Why the Structure Helps Monitoring
For anyone integrating CANopen upward, the COB-ID structure is a gift because it makes the bus self-describing at the identifier level. A gateway or analyzer can derive, from the COB-ID alone, which node and which object each frame belongs to, which is how tools present a raw CAN stream as organized CANopen traffic rather than an undifferentiated list of identifiers. That decomposition is the first step in turning frames into named tags.
It also makes troubleshooting cleaner. If one node's heartbeat stops, its heartbeat COB-ID simply goes silent, and because the COB-ID identifies the node you know immediately which device dropped, which ties directly into node guarding and heartbeat monitoring. You are never guessing which physical device an identifier maps to, because the node ID is right there in the low bits.
When the data reaches a monitoring platform through a gateway, the COB-ID has done its job and the values appear as ordinary tags, but the clean mapping it enabled is what made the integration systematic. A network with well-assigned node IDs and default COB-IDs maps into a historian with a predictable, repeatable tag structure, which is exactly what you want across a fleet of similar machines.
Frequently Asked Questions
What does a CANopen COB-ID contain?
In the standard predefined connection set, an 11-bit COB-ID is built from an upper function-code field and a lower seven-bit node ID (1 to 127). The function code identifies the message type, such as an emergency, a specific PDO, an SDO channel, or a heartbeat, and the node ID identifies which device the message belongs to. So a COB-ID tells you both what a message is and which node it concerns, readable directly from the identifier.
What is the CANopen predefined connection set?
It is the default mapping that automatically assigns each node its standard COB-IDs based only on its node ID, so a simple network works without manual identifier assignment. Setting a unique node ID gives each device its default PDOs, SDO channel, heartbeat, and emergency identifiers. Networks that need more PDOs or a custom mapping override these defaults through the communication parameters in the object dictionary.
Can I change a CANopen COB-ID?
Yes, through the PDO communication parameters in the object dictionary, and it is sometimes necessary when a device needs more PDOs than the defaults or a custom producer-consumer mapping. Both the producing and consuming nodes must agree on the new COB-ID. Because a COB-ID is a CAN identifier, its value also sets arbitration priority, so a poorly chosen custom identifier can invert the intended message priority.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.