CANopen Communication Model

CANopen mechanisms and services allow a standardized communication via the CAN-bus. The CAN in Automation (CiA) is responsible for the standardization. There are various types of CANopen standards:

• communication profiles specify fundamental CANopen mechanisms and services,

• device profiles specify the usage of fundamental CANopen mechanisms and services and objects for special device classes

• application profiles specify the usage of fundamental CANopen mechanisms and services and objects and device profiles for special application systems

The CANopen Library from port provides communication profiles with interfaces to the user application.

Two CANopen services with different characteristics are dominating most automation networks and thus CANopen. These are the service for very quick messages for process data and the service for slower yet more flexible message for service data. Furthermore, CANopen defines an interface for accessing and storing data in a basic dictionary. All data and parameters of a device which shall be visible from the CAN bus or the application, can be reached via this object dictionary.

Object dictionary

All device parameters are stored in an object dictionary. This object dictionary contains the description, data type and structure of the parameters as well as the address composed of a 16‑bit index and an 8-bit sub-index and therefore guarantees compatibility with existing older device profiles (e.g. DRIVECOM). Only the CANopen specific entries have no correlation with other profile definitions. The sub-index refers to the elements of complex data types e.g. arrays and records.

Table 1: organization of complex data types on the example of an object for the RS232 configuration

The following C-structure is the equivalent of the contents in Table 1.

The object dictionary is organized in different sections, see Table 2.

Table 2: structure of object dictionary

The communication profile area is used to configure the standardized communication services supported by a device. Objects in this area have a predefined meaning and will expect values according to the CiA standards.

The big address space in the manufacturer-specific area is totally under control of the device developer and can be used however he needs. It is often used to store application data or configuration that is unrelated to the CANopen functionality, but which shall be accessed via the CAN bus. In other words, this is the storage of (most of) the data that will be communicated using CANopen.

The object dictionary concept allows optional predefined device features which ensure a standardized behavior of certain device classes. These device profiles are standardized by the CiA and use objects in the standardized profile-specific area both for configuration and data storage. Multiple device profiles can be implemented at the same time.

Service data objects

Service data messages, in CANopen called Service Data Objects (SDO), are used to read and write all entries of the object dictionary of a device. Main usage of this type of messages is the device configuration. Besides reading and writing of the parameters and data, it is possible to download whole programs to the devices.

The SDO message contains information to address data in the device object dictionary and the data itself. Most existing profiles use 3 bytes to address objects, divided in two bytes for an index address and one byte for the sub-index address. Considering one byte for the protocol four bytes remain for parameter data. 

A basic SDO transfer consists of a CAN message to initiate and perform data transfer and a CAN message for handshake. Transfers of more than 4 Byte will use more than those 2 messages.

SDOs are typically transmitted asynchronously. The requirements towards transmission speed are not as high as for PDOs.

Open

Figure 2: SDO communication principle

Figure 2 shows the communication between two devices. There are two variants for SDO usage. The first one is a write access and the second one is a read access to the SDO server object dictionary. 

The SDO client initiates a write service with a SDO write request. The SDO server indicates the message, writes the value to the object dictionary and gives a response to the CAN network. The client gets a confirmation of that service. 

At a read request the client initiates the SDO service. The SDO server indicates the message, reads the value from object dictionary and gives a response to the CAN network.  The client gets a confirmation message containing the data read. 

If it is necessary to transfer more than 4 bytes, e.g. arrays or files, a sequence of segmented messages will follow the initiate transfer message, each one acknowledged by the data server. See Figure 3 for the SDO protocol.

Open

Figure 3: SDO protocol

The SDOs get low priority CAN identifiers. There are two SDO service types required for SDO communication. The first is the SDO server (SSDO), which cannot initiate a SDO service request. Instead they react to an SDO indication e.g. by writing or reading values to/from the local object dictionary. 

The COB-IDs for the first server SDO are pre-defined and must not be changed in order to ensure the connection to the device. The COB-IDs are built according to the following rules:

COB − ID_TX = 580h + <node-ID>              (1)

COB − ID_RX = 600h + <node-ID>              (2)

These equations are valid for the SDO server point of view.

The second SDO service type is the SDO client (CSDO), who initiates the SDO service. Typical SDO client applications are configuration tools and control units. The corresponding entries in the object dictionary are:

index_SSDO = 1200h + (<server SDO number> − 1)       (3)

index_CSDO = 1280_h + (<client SDO number> − 1)        (4)

Every CANopen device must have at least one SDO server. Each device can support up to 128 server SDOs and 128 client SDOs.

The SDO parameters are organized in a structure (Table 3). All entries can be changed besides the value for the first server SDO. The index 0022h is only a reference to the structure type. It has to be replaced with the computed index mentioned above.

Table 3: structure of SDO parameters

Process data objects

Process data messages, in CANopen called Process Data Objects (PDO), are used to perform the real-time data transfer between different automation units. PDOs have to be transmitted quickly, without any protocol overhead and within a pre-defined structure.

For PDOs different transmission modes are distinguished (Figure 4):

Figure 4: PDO transmission types

Asynchronous event-driven PDOs are sent on event (application/profile specific or timer) or on a remote request. Synchronous PDOs can be triggered cyclic or acyclic with the SYNC message.

An explicit confirmation for PDOs is not required and it carries no overhead. CANopen suggests a high priority in order to ensure their real-time behavior. CANopen defines PDO producer and PDO consumer. The producer sends PDOs and the consumer receives PDOs. Commonly a CANopen device can fulfill both properties.

Figure 5: PDO communication model

The PDO communication parameters reside in the object dictionary. The indices for PDO communication objects are calculated as follows:

index_{RPDO_para} = 1400h + (<RPDO number> − 1)          (5)

indexT_{PDO_para} = 1800h + (<TPDO number> − 1)         (6)

The range of the PDO numbers is 1...512. That means up to 512 Receive PDOs (RPDO) and up to 512 Transmit PDOs (TPDO) are possible for a device.

The PDO communication parameters are described with a structure (Table 4). The index 0020h is only a reference to the structures type and is used from the PDO communication parameter objects.

Table 4: structure of PDO communication parameter

The sub-index 0 contains the number of implemented PDO communication parameters. Only sub-index 1 and 2 are mandatory.

Sub-index 1 describes the used COB-ID of the PDO. This value is bit-coded. A detailed description is shown in Table 5. A PDO communication channel between two devices is created by setting the RPDO COB-ID of one device to the TPDO COB-ID of the other device. For PDOs a 1:1 and a 1: n communication is possible. This means that there is always only one transmitter, but an unlimited number of receivers.

Table 5: structure of PDO COB-ID parameter

The transmission type (sub-index 2) describes the kind of PDO transmission see Table 6. For synchronous PDO it is possible to define a scaling factor. Transmission type 1 means PDO will be triggered with each SYNC object. If this entry has the value 240, the PDO will be sent/received with each 240th SYNC.

Table 6: PDO transmission types

The inhibit time (sub-index 3) defines a minimum time period between two PDO transmissions. This feature ensures that messages with lower priorities than the current PDO can be transmitted in the case of continuous transmission of the current PDO and the PDO consumers are able to process the received PDO data.

The event timer (sub-index 5) is only relevant for asynchronous TPDOs. It defines an event timer. Once the event time is elapsed, the transmission of this PDO is started.

The SYNC start value (sub-index 6) requires SYNC messages with a SYNC counter. The SYNC start values specifies the SYNC counter number with which the PDO transmission starts.

The content of the PDO is encoded in the PDO mapping entries. A PDO can contain up to 64 single data elements from the object dictionary. In the case of 64 of the data are bits. The data are described via its index, sub-index and length. The PDO mapping parameter resides also in the object dictionary. The indices for PDO mapping objects are calculated as follows:

index_{RPDO_map} = 1600h + (<RPDO number> − 1)       (7)

index_{TPDO_map} = 1A00h + (<TPDO number> − 1)       (8)

The PDO mapping parameters are described with a structure (Table 7). The index 0021h is only a reference to the structures type and is used from the PDO mapping parameter objects.

Table 7: structure of PDO mapping parameter

Sub-index 0 contains the number of mapped variables. The maximum of entries is either 64 or 8. This fact depends on the PDO mapping granularity. (This is a feature of the CANopen Library implementation, not of the standard.) Many devices support only byte-wise PDO mapping. The sub-index defines the order of the variables on the PDO message. The data are assigned in ascending order in the PDO message.

The entries from sub-index 1 contain a logical reference to the variables, which are to be transmitted/received (Table 8). The data object is described by its index and sub-index and its length. The length value represents the data’s length in bits.

Table 8: structure of PDO mapping entry

A special case of PDO mapping is the so called PDO dummy mapping. With this kind of PDO mapping, it is possible to blind out irrelevant data. This feature is used for a 1:n communication, where each receiver utilizes only a part of the PDO. For PDO dummy mapping the indices 0001h -0007h are used. These indices are only references to data types and the entries are only space holders with the data type corresponding size, see Table 9.

Table 9: indices of PDO dummy mapping entries

The PDO mapping can be static or dynamic. It is not allowed to change the PDO mapping during run-time for static PDO mapping. In contrast, the dynamic PDO mapping allows the configuration of the PDO mapping during run-time if the PDO is disabled.

Emergency object

The Emergency object (EMCY) is a service, which signals internal fatal device errors. The error types are defined in the communication profile and the device profiles. The EMCY is transmitted with highest priority.

CANopen defines EMCY producer and EMCY consumer. The producer transmits EMCYs and the consumers receive them.

The EMCY telegram consists of 8 bytes. It contains an EMCY error code, the contents of object 1001h and 5 bytes of an additional information. The additional information is manufacturer-specific.

Additional an error handling exists. Each transmitted error code and the first two bytes of the manufacturer-specific additional information will be pushed in the predefined error field on index 1003h. This field can contain up to 255 error entries. The value of sub-index 0 shows the current number of entries. The most recently occurred error will be always inserted on the top of this field (sub-index 1). All older entries will be moved down.

When all errors are cleared on the device, an EMCY with error code 0 will be sent.

Synchronization object

The Synchronization object (SYNC) is a network wide system clock. It is the trigger for synchronous message transmission. The SYNC has a very high priority in order to guarantee a minimum of jitter.

Time Stamp object

The Time Stamp object provides a common time reference. It is transmitted with high priority. The time is encoded in the type Time of Day. This data type contains the milliseconds since midnight and the number of days since January 1, 1984.

Error Control mechanisms

For node monitoring two different mechanisms are defined:

• Heartbeat and

• Node Guarding.

Each device has to provide one of the error control mechanisms. For new devices Heartbeat shall be preferred.

Heartbeat

Heartbeat (HB) is an error control mechanism without need for remote frames. Each Heartbeat producer cyclically transmits a Heartbeat message. One or more Heartbeat consumers receive this message and monitor the Heartbeat producer. Each Heartbeat producer uses a certain period defined in object 1017h (Heartbeat producer time). Heartbeat starts immediately if the Heartbeat producer time is greater zero.

The Heartbeat consumer has to monitor the Heartbeat producer. For monitoring the Heartbeat consumer has an entry for each Heartbeat producer in its object dictionary. The Heartbeat consumer Time in object 1016h can be different for each Heartbeat producer but shall be greater than the Heartbeat producer time. Usually the Heartbeat will be configured by the network Configuration Manager. The resolution of the Heartbeat times is 1ms.

Heartbeat has a big influence on network load - but in effect, the half of the load of the Node Guarding monitoring!

Node Guarding

The Node Guarding (NG, also known as Life Guarding) is the active periodical monitoring of certain network nodes. Each node can be checked from the NMT master with a certain period specified in object 100Ch (guard time). A second parameter in object 100Dh (life time factor) defines a factor when the connection shall be detected as lost.

The resolution of the guarding time is 1 ms. The condition for Node Guarding on a slave device is that guard time and life time factor are not zero. Node Guarding is started with the first guarding telegram of the master.

During Node Guarding the master sends a RTR frame to each guarded slave. The slave answers with its current state and a toggle bit. This toggle bit alternates for each cycle.

Node Guarding has a big influence on network load!

Boot-up message

After a CANopen node has finished its own initialization and entered in the node state NMT/PRE-OPERATIONAL it has to send the Boot-up message. This message indicated that the device is ready for communication. This protocol uses the same CAN-identifier as the error control protocol (Heartbeat or Node Guarding).

Network behavior

CANopen uses the state machine shown in Figure 6 for the handling of communication functions.

Figure 6: NMT state machine

After power-on a device is going to be initialized and set in the state NMT/PRE-OPERATIONAL automatically. In this state reading and writing to its object dictionary via SDO is possible. The device can now be configured. That means setting of objects or changing of default values in the object dictionary like preparing PDO transmission.

Afterwards the device can be switched into the NMT/OPERATIONAL state via the command Start Remote Node in order to start PDO communication. PDO communication can be stopped by the network master by simply switching the remote node back to NMT/PRE-OPERATIONAL by using the Enter Pre-Operational State command.

Via the Stop Remote Node command the NMT master can force the slave(s) to the state NMT/STOPPED. In this state no services besides network and error control mechanisms are available.

The command Reset Communication resets the communication on the node. All communication parameters will be set to their defaults. The application will be reset by Reset Node. This command resets all application parameters and calls Reset Communication command.

The difference between NMT master and NMT slave devices is the initiation of the state transitions. The NMT master controls the NMT state transitions of each device in the network.

All needed NMT commands use only CAN identifier 0. The commands are distinguished with a command specifier in the first data byte of the NMT message, see Table 10. The second byte specifies the addressed node-ID. If the node-ID is zero the command is valid for all nodes in the network (broadcast).

Table 10: NMT message

Table 11 shows the availability of the CANopen services depending on the NMT state.

Table 11: availability of CANopen services depending on NMT state

In order to reduce configuration effort for simple networks a mandatory default identifier allocation scheme, called pre-defined connection set, is defined not only for NMT messages, also for the other services. These identifiers are available in the NMT/PRE-OPERATIONAL state directly after initialization (if no modifications have been stored) and may be modified by means of dynamic identifier distribution or SDO access (default way). A device has to provide the corresponding identifiers only for the supported communication objects.

The cob-ID is built from a function code, representing the object type, and the 7 bit module or node-ID. A simplified overview about the pre-defined connection set is shown in Table 12.

Table 12: cob-IDs according to pre-defined connection set

The resulting CAN-ID for a COB is built:

CAN-ID = ((function code) * 128) + <node-ID>                                                                               (9)

The CAN-IDs for further CANopen services can be assigned free with exception of restricted CAN-IDs. The restricted CAN-IDs are specified in the communication profile standard CiA-301 as follow:

Table 13: restricted CAN-IDs

The priority order of the communication services according to CiA-301 shall be:

1. NMT (lowest CAN-ID),

2. SYNC,

3. TIME,

4. EMCY,

5. synchronous PDOs,

6. asynchronous PDOs,

7. MPDOs

8. SDOs and

9. error control (highest CAN-ID).

The CAN-IDs can be configured about standardized communication objects via SDO.

CANopen LEDs

The CiA-303-3 provides a standardized way for state indication of a CANopen device. There is an ERR LED and a RUN LED. It is also possible to use only one of the two LEDs or instead of two single color LEDs a bicolor LED.

The RUN LED is green and indicates the CANopen state. The ERR LED is red and shows errors of the physical layer.

Table 14: states indicated by ERR LED (**… not supported by CANopen Library)

Table 15: states indicated by RUN LED

Flying Master

The Flying Master mechanism provides services for transferring the NMT master service from one node to another node. The Flying Master principle is based on Heartbeat monitoring of all NMT master capable devices in the network. If the active NMT master fails a new negotiation is started automatically, depending on a priority of nodes and the node number of the NMT master capable devices. The NMT master negotiation is won by the node with the highest priority (prior = 0) and the lowest node-ID. The active NMT master monitors the network cyclically for other active NMT masters and starts a new NMT master negotiation if necessary.

All Flying Master devices have to implement object 1F80h where bit 0 (NMT master) and 5 (Flying Master) are set. Otherwise they cannot participate in the master negotiation process.

Figure 7 shows the procedure for the Flying Master startup. The services are defined in the standard CiA-302-2.

Figure 7: Flying Master startup

Layer Setting Services

The Layer Setting Services (LSS) provides services and CANopen protocols to inquire or to change network parameters via the CAN network. The services are defined in the standard CiA-305. The standard CiA-305 uses a CAN bit timing table for the configuration of the CAN bit rate. Each LSS device can support more than one bit timing table. Therefore every table has a number and each CAN bit rate in the bit timing table has a table index number. The CiA-305 specifies the table with the number 0 with the following CAN bit rates:

Table 16: CAN bit timing table 0 of CiA-305

Safety

Services and CANopen protocols for safety critical communication are defined in the standard CiA-304. For safety critical communication Safety Relevant Data Objects (SRDO) are used. SRDOs are sent periodically. To increase safety, the data of an SRDO is transmitted twice. The second time the data is sent inverted. All SRDOs have their own COB-ID.

Figure 8: SRDO timing (SCT…safe-guard cycle time, SRVT…safety relevant object validation time)

The receiver of an SRDO has to check the incoming SRDO for correctness of the order, correctness of data and the time period. All information (timings, COB-ID, mapping) for SRDO is stored in the object dictionary.

1.1      CANopen device profiles

A device profile defines a standard device. For these standard devices a basic functionality has been specified, which has to exhibit every device within a class. The CANopen Device Profiles ensure a minimum of identical behavior for a kind of devices.

Figure 9: communication architecture with device profile CiA-402

A typical communication architecture is shown in Figure 9.

If a device uses a standardized device profile it has to provide all items defined as mandatory in the standard. Additional the manufacturer can decide about supported optional objects. All parameters and data, which are not covered by the standardized device profiles can be realized as manufacturer-specific objects.

The constantly growing list of currently available profile databases can always be found at port’s homepage.

Implementation of device profiles can be done very easily by using the Industrial Communication Creator from port. This tool provides profile databases with all objects for many of the standardized device profiles. Missing device profiles can be easily implemented by using the Industrial Communication Creator as data entry tool.