PDO services

In CANopen FD, the Process Data Object (PDO) functionality is nearly the same as in Classic CANopen. PDOs are used to transmit process data. Process data could be for example measured values or it could be commands. Most of them are time-critical. The PDO service is not confirmed. It is a producer/consumer service or in other words a publisher/subscriber service.

PDO messages in CANopen FD contain up to 64 byte of process data. They are mapped to a single CAN FD data frame using a CAN-ID determined by the COB-ID parameter given in the CANopen FD object dictionary. This parameter is part of the PDO communication parameter set. This parameter set also comprises the transmission type, which indicates the kind of transmission mode respectively reception mode.

In general, CANopen FD allows transmitting PDOs asynchronously and synchronously. The triggering of asynchronous PDOs depends on device-internal events. This can be the change of process data transmitted in this PDO or the elapsing of the event-timer – also part of the PDO communication parameter set. The event-timer enables a periodical transmission of the PDO. But have in mind, the event-timer is a local timer and not synchronized with the other CANopen FD device in the network.

The synchronous transmission of PDOs is a unique feature of the CANopen FD application layer. It is based on the periodical transmission of the SYNC message, which uses a single CAN data frame with the default high-prior CAN-ID of 8016. The SYNC message triggers the transmission of all synchronous PDOs in the CANopen FD network. This means, all sensors measure their values at the very same moment. They are synchronized. Depending on the internal delay and the priority of the PDO message, these values are transmitted. Of course, they are transmitted one after the other, but all have been measured simultaneously.

In order to synchronize “fast” and “slow” CANopen FD devices, the synchronous TPDOs can be configured to serve each, each second up to each 240th SYNC message. But with mechanism you cannot group synchronous PDOs. For this feature, you need to use the SYNC message with a 1-byte counter. Additionally, the SYNC start value (sub-index 0616) needs to be configured. Now, you can start one group of synchronous PDOs, for example, at the SYNC counter value of 1 serving each second SYNC message and another group at the SYNC counter value of 2 also serving each second SYNC message. Of course, you can configure more complex behavior, in order to achieve a stable average busload.

In order to synchronize outputs in different devices, the related RPDOs need to be configured as synchronous. This means, the received commands are not performed immediately, but when the next SYNC message is received. At this time all devices perform synchronized the requested actuation.

Another unique feature is the PDO inhibit time. This configurable time circumvents the transmission of the PDO for the configured period. This means, a high-prior PDO cannot occupy the entire bandwidth, and lower-prior PDOs can win bus-arbitration. With this feature you can design a predictable transmission of Change-of-State (CoS) triggered PDOs.

There is a second PDO parameter set specifying the content of the PDO message. It is possible to map multiple process data into one PDO message. Bit-wise mapping is supported, but not recommended. The related PDO mapping parameter array in the object dictionary provides the object dictionary addresses (16-bit index plus 8-bit sub-index), where the process data value is stored (in case of a Transmit-PDO) or should be stored (in case of a Receive-PDO).

The PDO mapping parameters could be different on the transmitting and the receiving side, the example shows a sensor device transmitting two process data and a display device with virtual gauges receiving the PDO.

The PDO mapping parameters could be different on the transmitting and the receiving side, the example shows a sensor device transmitting two process data and a display device with virtual gauges receiving the PDO.

The system designer has several opportunities to optimize the PDO communication to the application requirements:

  • PDO prioritization: Configuring the COB-ID parameter with an appropriate CAN-ID value changes the prior when accessing the CAN network.
  • PDO linking: Configuring the COB-ID parameter of the RPDO to a dedicated CAN-ID value is a subscription of the corresponding TPDO. It is possible that multiple or all CANopen devices subscribe to the same TPDO (multi-cast and broadcast communication)
  • PDO scheduling: Configuring the transmission type sub-parameter of a TPDO determines the sending behavior (e.g. change-of-state (CoS), periodically, or synchronously). Configuring the transmission type parameter of a RPDO determines the reception behavior (performing the required action immediately or with the reception of the next SYNC message).
  • PDO mapping: Configuring the PDO mapping parameter set determines, which process data are mapped into the TPDO or where to entry the received process data (RPDO).

Transmission type values

The transmission type sub-parameter of determines the scheduling of TPDO. In case of a synchronous transmission, the TPDO can be configured to serve each received SYNC message, each second, etc. Remotely requested TPDO should not be used, due to a completely specified behavior (the reaction on CAN remote frames can be implemented differently, for example).

Value Description
0016 Acyclic synchronous: Triggered when the SYNC message is received and one of the mapped process data has changed its value after the last transmission.
0116 to F016 Cyclic synchronous: Triggered when the SYNC message is received (0116), each second SYNC message is received (0216), etc. This allows supporting fast changing process data as well as slow changing process data.
F116 to FB16 reserved
FC16 Synchronous RTR only: not recommended anymore
FD16 Asynchronous RTR only: not recommended anymore
FE16 Asynchronous: Triggered by an internal event (e.g. change-of-state of one of the mapped process data or elapsing of the event-timer or any other event). The device manufacturer specifies the internal event triggering the TPDO transmission.
FF16 Asynchronous: As before, but the CiA profile specifies the internal event triggering the TDPO transmission.

PDO communication parameter set

This parameter set is a record. The first sub-parameter (highest sub-index supported) indicates the sub-parameter with highest number. The COB-ID sub-parameter contains the CAN-ID to be used and some additional protocol control bits. The transmission type sub-parameter determines the triggering (TPDO) or reception (RPDO) behavior). The inhibit-time sub-parameter provides the time in ms, when this TPDO is allowed sending it again. The event timer sub-parameter specifies the period in ms of the TPDO transmission respectively the time-out (missing) of a RPDO. The SYNC start value sub-parameter indicates, when the synchronous TPDO is transmitted first. The value of this sub-parameter needs to match with the value given in the 1-byte SYNC message.

Sub-index Name Data type
0016 Highest sub-index supported Unsigned8 (BYTE)
0116 COB-ID Unsigned32 (DWORD)
0216 Transmission type Unsigned8 (BYTE)
0316 Inhibit-time Unsigned16 (WORD)
0416 reserved Not applicable
0516 Event timer Unsigned16 (WORD)
0616 SYNC start value Unsigned8 (BYTE)