CANopen is the internationally standardized (EN 50325-4) CAN-based higher-layer protocol for embedded control system. For more information on CANopen see http://www.can-cia.org/
This library allows the manipulation of CANopen devices as defined in CiA 301.
Pre-built documentation is available here: https://daxbot.github.io/node-canopen/
The Device class represents a CANopen device and provides context for the protocol objects as well as access methods for the manufacturer data fields.
| OD Entry | Description | Supported |
|---|---|---|
| 0x1000 | Device type | ✔️ |
| 0x1002 | Manufacturer status register | ✔️ |
| 0x1008 | Manufacturer device name | ✔️ |
| 0x1009 | Manufacturer hardware version | ✔️ |
| 0x100A | Manufacturer software version | ✔️ |
The CANopen emergency protocol is used to indicate internal errors with a CANopen device. Call Emcy.write to produce an emergency object.
| OD Entry | Description | Supported |
|---|---|---|
| 0x1001 | Error register | ✔️ |
| 0x1003 | Pre-defined error field | ✔️ |
| 0x1014 | COB_ID EMCY | ✔️ |
| 0x1015 | Inhibit time EMCY | ✔️ |
| 0x1028 | Emergency consumer object | ❌ |
| 0x1029 | Error behavior object | ❌ |
The CANopen layer setting services protocol allows the CAN-ID and bitrate of an LSS consumer device to be modified. This allows for setting up a network of identical devices without relying on physical dip switches or non-volatile storage to distinguish between them.
| OD Entry | Description | Supported |
|---|---|---|
| 0x1018 | Identity object | ✔️ |
Supported Features:
- LSS producer ✔️
- LSS consumer ✔️
The CANopen network management protocol is used to manipulate the state of NMT consumer devices on the network and is responsible for the device heartbeat. Call Nmt.start to begin heartbeat generation.
| OD Entry | Description | Supported |
|---|---|---|
| 0x1016 | Consumer heartbeat time | ✔️ |
| 0x1017 | Producer heartbeat time | ✔️ |
Supported Features:
- Remote state changes ✔️
- Heartbeat
- Generation ✔️
- Monitoring ✔️
- Command processing
- State changes ✔️
- Reset node ✔️
- Reset communications ✔️
The CANopen process data object protocol is used for broadcasting data changes with minimal overhead, similar to a more traditional CAN network architecture. A mapped PDO can be sent with the Pdo.write method. Calling Pdo.start will begin producing mapped synchronous TPDOs.
| OD Entry | Description | Supported |
|---|---|---|
| 0x1400 - 0x15FF | RPDO communication parameter | ✔️ |
| 0x1600 - 0x17FF | RPDO mapping parameter | ✔️ |
| 0x1800 - 0x19FF | TPDO communication parameter | ✔️ |
| 0x1A00 - 0x1BFF | TPDO mapping parameter | ✔️ |
The CANopen service data object protocol provides direct access to a device's object dictionary. Call the Sdo.upload or Sdo.download methods to initate a transfer.
| OD Entry | Description | Supported |
|---|---|---|
| 0x1200 - 0x127F | SDO server parameter | ✔️ |
| 0x1280 - 0x12FF | SDO client parameter | ✔️ |
The CANopen sync protocol is used to synchronize actions between devices on the network. Call Sync.start to begin producing sync objects.
| OD Entry | Description | Supported |
|---|---|---|
| 0x1005 | COB-ID SYNC | ✔️ |
| 0x1006 | Communication cycle period | ✔️ |
| 0x1007 | Sync window length | ❌ |
| 0x1019 | Sync counter overflow value | ❌ |
The CANopen time protocol is used to provide a simple network clock. Call Time.write to produce a time stamp object.
| OD Entry | Description | Supported |
|---|---|---|
| 0x1012 | COB-ID TIME | ✔️ |
| 0x1013 | High resolution time stamp | ❌ |