CANopen is a communication protocol and device profile specification for embedded systems used in automation. In terms of the OSI model, CANopen implements the layers above and including the network layer. The CANopen standard consists of an addressing scheme, several small communication protocols and an application layer defined by a device profile. The communication protocols have support for network management, device monitoring and communication between nodes, including a simple transport layer for message segmentation/desegmentation. The lower level protocol implementing the data link and physical layers is usually Controller Area Network (CAN), although devices using some other means of communication (such as Ethernet Powerlink, EtherCAT) can also implement the CANopen device profile.
The basic CANopen device and communication profiles are given in the CiA 301 specification released by CAN in Automation. Profiles for more specialized devices are built on top of this basic profile, and are specified in numerous other standards released by CAN in Automation, such as CiA 401 for I/O-modules and CiA 402 for motion control.
Device model
Every CANopen device has to implement certain standard features in its controlling software.
A communication unit implements the protocols for messaging with the other nodes in the network. Starting and resetting the device is controlled via a state machine. It must contain the states Initialization, Pre-operational, Operational and Stopped. The transitions between states are made by issuing a network management (NMT) communication object to the device. The object dictionary is an array of variables with a 16-bit index. Additionally, each variable can have an 8-bit subindex. The variables can be used to configure the device and reflect its environment, i.e. contain measurement data. The application part of the device actually performs the desired function of the device, after the state machine is set to the operational state. The application is configured by variables in the object dictionary and the data are sent and received through the communication layer.
Object dictionary
CANopen devices must have an object dictionary, which is used for configuration and communication with the device. An entry in the object dictionary is defined by: Index, the 16-bit address of the object in the dictionary Object name (Object Type/Size), a symbolic type of the object in the entry, such as an array, record, or simple variable Name, a string describing the entry Type, gives the datatype of the variable (or the datatype of all variables of an array) Attribute, which gives information on the access rights for this entry, this can be read/write, read-only or write-only The Mandatory/Optional field (M/O) defines whether a device conforming to the device specification has to implement this object or not
The basic datatypes for object dictionary values such as booleans, integers and floats are defined in the standard (their size in bits is optionally stored in the related type definition, index range 0x0001–0x001F), as well as composite datatypes such as strings, arrays and records (defined in index range 0x0040–0x025F). The composite datatypes can be subindexed with an 8-bit index; the value in subindex 0 of an array or record indicates the number of elements in the data structure, and is of type UNSIGNED8.
For example, the device communication parameters, standardized in the basic device profile CiA 301 are mapped in the index range 0x1000–0x1FFF ("communication profile area"). The first few entries in this area are as follows:
Given suitable tools, the content of the object dictionary of a device, based on an electronic data sheet (EDS), can be customized to a device configuration file (DCF) to integrate the device into a specific CANopen network. According to CiA 306, the format of the EDS-file is the INI file format. There is an upcoming XML-style format, that is described in CiA 311.
Communication
Communication objects
CAN bus, the data link layer of CANopen, can only transmit short packages consisting of an 11-bit id, a remote transmission request (RTR) bit and 0 to 8 bytes of data. The CANopen standard divides the 11-bit CAN frame id into a 4-bit function code and 7-bit CANopen node ID. This limits the number of devices in a CANopen network to 127 (0 being reserved for broadcast). An extension to the CAN bus standard (CAN 2.0 B) allows extended frame ids of 29 bits, but in practice CANopen networks big enough to need the extended id range are rarely seen.