CANOPEN^™

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.

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: