CANOpen

CANOpen

CANopen is a communication protocol and device profile specification for embedded systems used in automation.

• https://en.wikipedia.org/wiki/CANopen
• specifications https://www.can-cia.org/
• mirror http://overpof.free.fr/schneider/CAN%20&%20CANopen/CANopen/%A9CiA%20CANCANopen%20CD%20V5.1/index.htm

Object dictionary

Object dictionary encapsulates all of the CAN exposed variables and allows reading or writing to sections specified by index and subindex. All variables have types and complex types are allowed - records and arrays.

Two major parts of the object dictionary are defined - communication profile area in range 0x1000-0x1FFF and application profile area (Standardised Device Profile Area) in range 0x6000-0x9FFF. Communication profile parameters are used internally by CANOpen stack (e.g. heartbeat period, pdo parameters) while application profile area defines application parameters (e.g. target velocity, control word).

• Specification is part of CiA 301

Layout

Object dictionary sections:

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

NMT service

Network management services allows controlling node state transitions. Also provides heartbeat functionality. On boot, CANOpen node automatically enters pre-operational NMT state, where node configuration usually takes place. After configuration, node can be switched to operational state where PDO services are available. NMT also defines initialising state, stopped state and two states for resetting object dictionary values - reset application and reset communication for resetting respective parts of object dictionary.

• Specification is part of CiA 301

SDO service

Allows reading or writing to variables in object dictionary. Device can implement multiple SDO services but generally only one service (default SDO) is provided that allows object dictionary variable access.

SDO Upload -> Read register from device:

# rs-canopen-sdo-upload vcan0 05 6000 01

vcan0  605   [8]  40 00 60 01 00 00 00 00

SDO Download -> Write register to device:

# rs-canopen-sdo-download vcan0 05 6000 01 13

vcan0  605   [8]  2F 00 60 01 13 00 00 00

• Specification is part of CiA 301.
• COB-ID for default SDO tx (transmitted from node) - 0x580 + node ID
• COB-ID for default SDO rx (received by node) - 0x600 + node ID

PDO

PDO or Process Data Objects allow communication without protocol overhead. PDO allows mapping of single or multiple variables into one CAN message with specific ID. This allows usage of all 8 bytes of CAN message data and allows writing or reading multiple variables at once.

There are two kinds of PDOs: transmit and receive PDOs (TPDO and RPDO). Transmit PDOs are used to read data from node and receive PDOs are used for writes.

For example RPDO for servo controller can contain mapping to two variables - control word and target velocity. Both of these are 32 bit values

• control word unsigned int32 at address 0x6040
• target velocity signed int32 at address 0x60FF

This fills up full 8 bytes of CAN data.

In similar manner, TPDO can be used for monitoring the drive, example mapping can look like this:

• status word unsigned int32 at address 0x6041
• velocity actual signed int32 at address 0x606C

Specification is part of CiA 301.

SYNC

Node synchronization is accomplished with the help of SYNC message. This can be used to either sample current sensor values at SYNC time or apply buffered SDO data to all variables at once.

• Specification is part of CiA 301
• COB-ID used by SYNC message is 0x80

LSS

Layer Setting Services and Protocol allows configuration of node ID and CAN baudrate. This protocol runs prior other CANOpen services as they require node ID to be configured.

Typically used when adding new nodes to the system. Non-configured node boots into LSS mode indicated by both LEDs blinking rapidly. Node ID and baudrate can be configured and configuration stored in non-volatile memory for next boots. If node ID is valid device skips LSS mode and goes straight into pre-operational state.

• LSS is defined in CiA 305
• COB-ID used by NMT is 0x0