CANopen Basics
Communication Objects
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)
SYNC (synchronisation)
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.
CAN IDs
Communication objects
0x000
NMT requests
0x080
SYNC
0x081 - 0x0FF
EMCY
0x581 - 0x5FF
SDO responses
0x601 - 0x67F
SDO requests
0x701 - 0x77F
NMT responses / heartbeats
So if any of these IDs look familiar to you, chances are you’ve got a CANopen network.
Note
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.
SDO Addresses
The SDO address space layout is standardized:
Index (hex)
Object
0000
not used
0001-001F
Static Data Types
0020-003F
Complex Data Types
0040-005F
Manufacturer Specific Complex Data Types
0060-007F
Device Profile Specific Static Data Types
0080-009F
Device Profile Specific Complex Data Types
00A0-0FFF
Reserved for further use
1000-1FFF
Communication Profile Area
2000-5FFF
Manufacturer Specific Profile Area
6000-9FFF
Standardised Device Profile Area
A000-BFFF
Standardised Interface Profile Area
C000-FFFF
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.