 |
CANopen Slave Protocol Stack
Version 7.06.02
|
|
CANopen Slave Protocol Stack
Version 7.06.02
|
CANopen is a higher-layer protocol built on top of the CAN bus. It is standardised by CiA (CAN in Automation) in CiA 301 and defines the application layer as well as a communication profile. CANopen FD, defined in CiA 1301, extends CANopen to take advantage of the larger payload and higher data-phase bit rate offered by CAN FD.
A CANopen network consists of one or more nodes. Every node is identified by a unique node-ID in the range 1–127. One node may act as a CANopen controller; all other nodes operate as CANopen devices. There is no dedicated hardware token for the controller role — any node that implements the NMT controller services can take the role.
Every CANopen node maintains an Object Dictionary (OD): a structured table of data objects. Each data object is addressed by a 16-bit index (1000h–FFFFh). If a data object holds more than one value, its individual values — called data elements — are addressed by an additional 8-bit sub-index.
The index ranges are standardised:
| Range | Contents |
|---|---|
| 1000h – 1FFFh | Communication profile (CiA 301) |
| 2000h – 5FFFh | Manufacturer-specific objects |
| 6000h – 9FFFh | Device profile objects (CiA 4xx) |
Object dictionary parameters can be stored persistently in NVM using the standard objects 1010h (Store parameters) and 1011h (Restore default parameters).
An Electronic Data Sheet (EDS) file describes the object dictionary of a device and is used by configuration tools to set up and commission the device.
Each CANopen service is represented by a communication object (COB). Every COB is identified on the bus by a Communication Object Identifier (COB-ID), which is the CAN-ID of the corresponding CAN frame. Most COB-IDs follow a pre-defined connection set: they are computed from a fixed base value and the node-ID of the producing or consuming node, for example:
| Service | COB-ID formula | Note |
|---|---|---|
| Synchronisation (SYNC) | 080h | COB-ID change via data object 1005h |
| Emergency (EMCY) | 080h + node-ID | COB-ID change via data object 1014h |
| TIME | 100h | COB-ID change via data object 1012h |
| Transmit PDO1 | 180h + node-ID | COB-ID change via data object 1800h |
| Receive PDO1 | 200h + node-ID | COB-ID change via data object 1400h |
| Transmit PDO2 | 280h + node-ID | COB-ID change via data object 1801h |
| Receive PDO2 | 300h + node-ID | COB-ID change via data object 1401h |
| Transmit PDO3 | 380h + node-ID | COB-ID change via data object 1802h |
| Receive PDO3 | 400h + node-ID | COB-ID change via data object 1402h |
| Transmit PDO4 | 480h + node-ID | COB-ID change via data object 1803h |
| Receive PDO4 | 500h + node-ID | COB-ID change via data object 1403h |
| Transmit SDO | 580h + node-ID | COB-ID bound to node-ID |
| Receive SDO | 600h + node-ID | COB-ID bound to node-ID |
| NMT Error Control | 700h + node-ID | COB-ID bound to node-ID |
SYNC, EMCY, TIME and PDO COB-IDs can be configured freely within the object dictionary.
NMT controls the state machine of each CANopen device. The possible states are:
NMT commands are sent by the CANopen controller to transition one or all nodes between states.
SDOs provide confirmed, point-to-point access to any data object in the object dictionary of a remote node. SDOs are used for parameterisation and diagnostics. CANopen supports expedited transfer (up to 4 bytes), segmented transfer (arbitrary length), and block transfer (efficient bulk transfer). CANopen FD uses the USDO protocol, which supports transfers of arbitrary size natively.
PDOs are unconfirmed messages optimised for real-time process data exchange. A Transmit PDO (TPDO) is produced by a CANopen device; a Receive PDO (RPDO) is consumed by it. PDO content is defined by a PDO mapping in the object dictionary: up to 8 bytes (or up to 64 bytes in CANopen FD) of data objects are packed into one PDO. PDO transmission can be triggered by a SYNC message (synchronous), by an event, or on a timer.
When a device-internal error occurs, the node broadcasts a single Emergency (EMCY) message containing a 16-bit Emergency Error Code (EEC) and a 5-byte manufacturer-specific field. An EMCY message is sent exactly once per error event; a separate EMCY reset message (EEC 0000h) is sent when the error clears. A history of recent EMCY messages is kept in object 1003h.
The SYNC producer broadcasts a periodic SYNC message (COB-ID 080h by default). Nodes that are configured for synchronous PDO transmission use the SYNC message as a trigger. The SYNC period is configured in object 1006h (Communication Cycle Period).
The Heartbeat protocol allows the CANopen controller and other nodes to monitor network health. A heartbeat producer transmits its NMT state cyclically; any consumer that does not receive a heartbeat within the configured timeout reports an error.
LSS allows a CANopen controller to configure the node-ID and bit rate of unconfigured CANopen devices at run-time, without using DIP switches or other hardware means. The device's identity (Vendor-ID, Product-Code, Revision-Number, Serial-Number, from object 1018h) is used to address individual devices during LSS configuration.
The TIME protocol distributes an absolute network time (days since 1984-01-01, milliseconds after midnight) from a TIME producer to one or more consumers. The COB-ID is configured in object 1012h.
CANopen FD (CiA 1301) extends classical CANopen with:
The CANopen FD protocol stack selects the mode (classical or FD) at run-time via CosMgrInit().