A CANopen network consists of “masters” and “slaves”, masters are clients, slaves are servers. At most one master may be active at a time.
CANopen supports addressing of up to 127 slaves on a bus using node IDs 1-127. Node address 0 is used for broadcasts to all nodes. Node addressing is simply mapped onto CAN IDs by adding the node id to a base ID.
The CANopen protocol mainly consists of…
PDO (process data objects)
SDO (service data objects)
NMT (network management)
EMCY (emergency events)
PDO are regular, normally periodical, status update frames, for example sensor
data. You can log them using the CAN monitor (
can log start monitor …).
PDOs can be sent at any CAN ID except those reserved for other CANopen services.
SDO are memory registers of nodes that can be read and written by masters on request. SDO requests are normally sent at ID 0x600 + nodeid, responses at ID 0x580 + nodeid. SDOs are addressed by a 16 bit index + 8 bit subindex. Registers and data types for a given device are documented by the device specific object dictionary, normally represented as an EDS (electronic data sheet) file.
NMT are short datagrams to control node startup / shutdown. There’s a special node state “pre-operational” allowing access to all operation and communication parameters of a node in a standardized way. NMT requests are sent at ID 0x000, responses and unsolicited updates (aka heartbeats) are sent at ID 0x700 + nodeid with length 1.
SYNC messages are datagrams of length 0, normally sent at ID 0x080.
EMCY messages are sent if a node encounters some kind of alert or warning condition, they are normally sent at ID 0x080 + nodeid with a length of 8 bytes.
0x081 - 0x0FF
0x581 - 0x5FF
0x601 - 0x67F
0x701 - 0x77F
NMT responses / heartbeats
So if any of these IDs look familiar to you, chances are you’ve got a CANopen network.
CANopen coexists nicely with OBD-II and often does in a vehicle (i.e. Renault Twizy). OBD-II devices normally are addressed at IDs > 0x780 so are outside the CANopen ID range. Even if they use non-standard IDs, the devices normally will detect and ignore frames not matching their protocol.
The SDO address space layout is standardized:
Static Data Types
Complex Data Types
Manufacturer Specific Complex Data Types
Device Profile Specific Static Data Types
Device Profile Specific Complex Data Types
Reserved for further use
Communication Profile Area
Manufacturer Specific Profile Area
Standardised Device Profile Area
Standardised Interface Profile Area
Reserved for further use
See CiA DS301 for details on standard SDOs.
For example, a device shall tell about the PDOs it transmits or listens to, their IDs, update frequency and content structure at SDO registers 1400-1BFF. This is mandatory in theory but real devices may not fully comply to that rule.
CANopen compliant standard device types like motor controllers need to implement some standard profile registers. See CiA DS401 for the generic I/O device class definition and CiA DS402 for motor controllers.
Most devices will require some kind of login before allowing you to change operational parameters. This is also done using SDO writes, but there is no standard for this, so you’ll need to dig into the device documentation.
Of course there’s a lot more on CANopen, but this should get you going.
CAN in Automation
More info on the standard and specific device profiles can be found on the CiA website:
CAN in Automation (CiA) is the international users’ and manufacturers’ group for the CAN network (Controller Area Network), internationally standardized in the ISO 11898 series. The nonprofit association was established in 1992. The aim is to provide an unbiased platform for future developments of the CAN protocol and to promote the image of the CAN technology.