[Documentation] [TitleIndex] [WordIndex

  Show EOL distros: 

ros_canopen: can_msgs | canopen_402 | canopen_chain_node | canopen_master | canopen_motor_node | socketcan_bridge | socketcan_interface

Package Summary

CiA(r) CANopen 301 master implementation with support for interprocess master synchronisation.

ros_canopen: can_msgs | canopen_402 | canopen_chain_node | canopen_master | canopen_motor_node | socketcan_bridge | socketcan_interface

Package Summary

CiA(r) CANopen 301 master implementation with support for interprocess master synchronisation.

ros_canopen: can_msgs | canopen_402 | canopen_chain_node | canopen_master | canopen_motor_node | socketcan_bridge | socketcan_interface

Package Summary

CiA(r) CANopen 301 master implementation with support for interprocess master synchronisation.

ros_canopen: can_msgs | canopen_402 | canopen_chain_node | canopen_master | canopen_motor_node | socketcan_bridge | socketcan_interface

Package Summary

CiA(r) CANopen 301 master implementation with support for interprocess master synchronisation.

ros_canopen: can_msgs | canopen_402 | canopen_chain_node | canopen_master | canopen_motor_node | socketcan_bridge | socketcan_interface

Package Summary

CiA(r) CANopen 301 master implementation with support for interprocess master synchronisation.

ros_canopen: can_msgs | canopen_402 | canopen_chain_node | canopen_master | canopen_motor_node | socketcan_bridge | socketcan_interface

Package Summary

CiA(r) CANopen 301 master implementation with support for interprocess master synchronisation.

Overview

This packages contains a master implementation of the CANopen DS 301 protocol. It provides libraries to connect to CANopen devices and access their data objects via high-level interfaces.

Features

This implementation provides support for many CANopen interfaces and services:

CANopen basics

Node ID

Each device is assigned a node ID in range between 1 and 127. It determines the CAN frame the device and listens to, so it must be unique (per bus).

Object dictionary

All data is stored as objects, which are adressed with 4-digit hexadecimal numbers and an optional hexadecimal 8-bit sub index. The object types range from simple integer values to complex structs and arrays.

The object dictionary contains all objects (data + types) and is structured based on the index, notable ranges are:

Network management (NMT)

The network management includes a state machine for the overall status(pre-operational, operation, stopped) of the devices and service to control the states. Further it can be used to monitor the devices.

Service data objects (SDOs)

Client/server interface for reading and writing objects. SDO cannot be used with stopped devices.

Process data objects (PDOs)

Publisher/subscriber interface for reading and writing objects. Limited to 8 bytes per PDO, can contain multiple (simple) objects. Not all objects can be mapped to PDOS, this depends on the object and the device. PDOs are available in the operational state only.

Synchronization object (SYNC)

Periodically object sent by the master to synchronize the devices of one bus. PDOs might be set-up to be synchronous (recommended for ros_canopen).

Emergency objects (EMCY)

The nodes send these objects on critical errors. The standard lists a wide range of errors code, profile can have additional codes.

EDS/DCF files

The electronic data sheet and the device configuration files are standardized in CiA 306 DS. These are INI files that contain all objects descriptions. The new XML based XDD is currently not supported.

The EDS just contains the defaults, the DCF can include specific parameter values, however canopen_master treats both alike. All entries that have parameter values different from the defaults are written to the device at initialization. PDO objects have additional restrictions and are handled separately.

All manufactures should provide EDS or DCF files. The editor Vector CANeds 3.6 is available freely and plays well with wine. The 3.7 version is free as well, but bundled to the demos version of the big CAN software suites. However, it can extract the object dictionary from any CANopen device.

Master plug-ins

Each CANopen bus shall have up to one master that is responsible for the synchronization. The driver has preliminary support for inter-process communitcation which should allow to run two driver instances on one bus. This implementation is currently not ready for production use however.

For now 2 different implementations exist with allocator plug-ins:

3 additional IPC-based implementations exist, but got deprecated:


2024-03-23 12:28