A synopsis of
CANopen ™
An Application Layer Protocol for Industrial Automation
CANopen™ is another CAN application layer protocol like DeviceNet and J1939. Like those other application layers, CANopen is a low-level industrial application layer protocol for automation applications. CANopen connects automation devices together using peer messaging. Built on the standard CAN (Controller Area Network) physical communications standard, CANopen uses CAN hardware to define an application layer protocol that structures the task of configuring, accessing and messaging between various kinds of automation devices. The data structure of CANopen is also the base of the newer high speed protocol EtherCAT.
Data Structure
CANopen is an object-based communications protocol. An Object Dictionary describes the complete functionality of a device. The Object Dictionary is the connection point between the communication interface and the application program. All communication objects are described in the Object Dictionary in a standardized way. These objects are accessible by a 16-bit index and, in the case of some objects in an additional 8-bit sub-index.
The CANopen Object Dictionary provides standardized communication objects for real-time data (PDOs – Process Data Objects), configuration data (SDOs – Service Data Objects), and special functions (Time Stamp, Sync Message, and Emergency Message) as well as network management data (Boot-up Message, NMT Message, and Error Control Message).
There are explicit and implicit messages that are embedded in the CAN Application layer that allow access to the Object Dictionary. Explicit messages allow a device to request the data value of a specific item in the Object Dictionary or set the value of an item in the Object Dictionary. Implicit messages allow predefined data transfers from one device to another without any overhead.
CANopen devices are not strictly peer-peer devices and not strictly Master-Slave devices. It is possible for a CANopen device to be a Master to another CANopen device and command it to take some action. At the same time, it can be a Slave device to another CANopen device that wishes to command it to take some action. And, at the same time it can exchange peer data with yet another CANopen device.
This is all possible because of the Object Dictionary, the organizing structure for all communications and all data exposed to the network within a CANopen device. If access is allowed, a device on a CANopen network can configure another CANopen device to perform peer communications or accept acyclic messages. Typically, this kind of general access is not made available to random nodes on the network. Instead, communication is preconfigured and provided to devices acting as a CANopen Master.
The CANopen Object Dictionary is the core of a CANopen device. The CANopen Object Dictionary contains the supported data types, communication objects, objects specific to the vendor and the device and objects specific to any profile supported.
| Network Type: | Multi-master Slave Communication system |
| Topology: | Linewith Trunkline, Dropline with Termination at each end |
| Cabling: | 4 wire (2 data 2 power) |
| Data rate: | 125K,250K, 500K, 1M |
| Max Number Devices: | 127 |
Message and Data Types
Required objects are required by the specification to be included in every CIP device. These objects include the Identity object, a Message Router object and a Network object.
PDO
PDO data transfers are high priority, unconfirmed data transfers that move I/O and high priority status information from one device to another device. PDOs are the most common mechanism for two devices to exchange data. PDOs are initiated either internally by the device or from some kind of external message.
To simplify configuration of devices and avoid the problem of configuring all the PDOs in both of the CANopen devices, the CANopen specification defines a PreDefined Connection set. This is simply a set of pre-configured, well-understood PDOs. By using the PreDefined Connection Set you don’t need to go through the trouble of setting up the PDOs on both sides, making sure they match and testing the communications. You have a set of PDOs that already have preconfigured COB-IDs that you can use. The Predefined Connect set include four transmit PDOs, four receive PDOs, 1 SDO, 1 Emergency object and 1 Node Error Control identifier.
Service Data Objects
Service Data Objects support the transfer of asynchronous commands and data between two CANopen devices. SDOs exist primarily for configuration, though some vendors seem to like to use them for data transfer. The target of the SDO message, the Object Dictionary that is acted upon, is the Server for the SDO. The initiator is the Client of the SDO.
SDOs have two purposes; to read an Object Directory entry in another CANopen device or to write an Object Dictionary entry in another CANopen device. Every SDO contains a full complement of 8 bytes of data even though sometimes data bytes will go unused. Unlike PDOs, SDO transfers are always confirmed by the receiver. Also unlike PDOs, SDOs can transfer much more data and have multiple types.
To simplify configuration of devices and again avoid the problem of configuring all the SDOs in both of the CANopen devices, the CANopen specification defines a Predefined Connection set. The Predefined Connection set contains a single SDO in each direction.
Just like with the Predefined Connection set for PDOs, the connection IDs of the SDOs are configured with the node address of the CANopen device so that a Maser type device can easily send SDOs to the device and get the SDO response messages.
CANopen also supports a number of other message types:
A set of messages that are issued by a Master type device that serve to synchronize the actions of a group of CANopen devices. CANopen reserves a connection ID in the highest priority group (lowest CAN ID) to ensure that the SYNC message is reliably transmitted over the network.
A set of messages that a Master uses with a set of CANopen Slave devices implementing the Predefined Connection set. The NMT (Network Management) protocol is implemented using a single CAN frame and is given the highest priority CAN ID (0). The NMT command consists of a command byte indicating the action to perform and a Node ID. A Node ID of zero is used to indicate that all devices on the network should execute the given command.
The set of messages used by a CANopen device to transmit some internal error condition. The Emergency Protocol transmits the Emergency Data Object once per occurrence of a device internal error. No additional messages are transmitted unless a different device internal error condition is raised. Typically, the CANopen Master device is the only device that will consume the Emergency Protocol message.
A single CAN frame that periodically transmits the current NMT state of the device.
CiA (CAN In Automation) provides both a certification test laboratory and a test tool. The Certification laboratory tests devices and certifies them compatible with the CANopen specification. The test tool evaluates whether a device behaves properly in a CANopen network. The test tool is available for purchase from CiA.
