1. M510/B310 CANopen optional interface
2. CANopen system overview
3. Network Management
4. Process Data Objects (PDO)

Process Data Objects (PDO)

In many fieldbus systems the entire process image is continuously transferred - usually in a more or less cyclic manner. CANopen is not limited to this communication principle, since with CANopen the process data are transferred based on the producer/consumer model. It means that a device sends its process data spontaneously (producer), while all other devices listen and use a CAN identifier to decide whether the telegram is of interest for them, in which case they process it accordingly (consumer).

The process data in CANopen is divided into segments with a maximum of 8 bytes. These segments are known as process data objects (PDOs). The process data objects (PDOs) each correspond to a CAN telegram. They are allocated and prioritized based on a specific CAN identifier.

The process data objects (PDOs) are subdivided into receive PDOs (RxPDOs) and send PDOs (TxPDOs); the ID is based on the device perspective. A device sends its input data with TxPDOs and receives the output data in the RxPDOs.
This designation is retained in TwinCAT.

Communication parameters

The process data objects (PDOs) can be assigned different communication parameters, as required. Like all CANopen parameters, these are also listed in the object directory of the device. The communication parameters can be accessed via service data objects (SDOs).

The parameters for the receive PDOs are contained in index 0x1400 (RxPDO1) to 0x15FF (RxPDO512), which means up to 512 RxPDOs can exist. In the same way, the entries for the transmit PDOs are located from index 0x1800 (TxPDO1) to index 0x19FF (TxPDO512).

For each existing process data object (PDO) there is an associated communication parameter object. TwinCAT automatically assigns the set parameters to the relevant object directory entries. These entries and their significance for the communication of process data are explained below.

CAN identifier

The main communication parameter for process data objects (PDOs) is the CAN identifier (also referred to a communication object identifier, COB ID). The CAN identifier is used to identify the CAN telegrams and determines their priority for bus access. For each CAN telegram there can only be one sender (producer). However, since CAN sends all messages based on the broadcast method, a telegram can be received by any number of devices (consumers), as described. In other words, a device can make its input information available to several devices at the same time, even without transfer by a logical master.

The CAN identifier is contained in subindex 1 of the communication parameter set. It is coded as a 32-bit value in which the least significant 11 bits (bits 0...10) contain the CAN identifier itself. The 32-bit object data width enables 29-bit CAN identifiers to be entered. The use of the 29-bit version is limited to special applications and is therefore not supported by the Beckhoff CANopen devices. The highest bit (bit 31) can be used to activate the process data object or to turn it off.

PDO linking

By default all devices (slaves) communicate with a central controller (master). By default no slave listens to the process data objects (PDOs) and therefore the CAN identifiers of another slave.

Standard communication between several slaves and a master:

To exchange process data objects (SDOs) directly between the devices without a master, the CAN identifiers have to be adjusted accordingly. The TxPDO identifiers of the producer must match the RxPDO identifier of the consumer. This procedure is known as PDO linking. It permits, for sample, easy construction of electronic drives in which several slave axes simultaneously listen to the actual value in the master axis TxPDO.

Communication without master based on PDO linking:

PDO transmission types

CANopen offers following options for transferring process data objects (PDOs):

• Event driven
• By polling
• Synchronized
  
  

• Event driven:
  If an input value changes, a device immediately transfers its process data objects (PDOs). This enables optimum utilization of the transmission bandwidth, since only the change in the process image is transferred, while the response time is short, since the devices do not wait for a query from a master if the input values change.
  
  As from CANopen Version 4 it is possible to combine the event driven type of communication with a cyclic update. The process data objects (in this case the TxPDOs) are then transferred once a set time (event timer) has elapsed. If an input value changes within the set time, the time (event timer) is reset.
  
  With RxPDOs the set time (event timer) is used to monitor the arrival of the event-driven process data objects (PDOs). A device switches to error state, if no process data objects (PDOs) arrived within the set time.
  
• Polled:
  The process data objects (PDOs) are polled through request telegrams (remote frames). In this way the process data objects (PDOs) are transferred even if there is no change, for sample if a monitor or diagnostic device is included in the network at runtime.
  
  Function blocks with integrated full message filtering (FullCAN) usually respond to a request telegram directly and immediately send the data contained in the corresponding send buffer. The application must ensure that the data are continuously updated. CAN controllers with simple message filtering (BasicCAN) on the other hand pass the request on to the application which can now compose the telegram with the latest data. This does take longer, but does mean that the data is up-to-date. Beckhoff use CAN controllers following the principle of Basic CAN.
  
  Since this device behavior is usually not transparent to the user, and because there are CAN controllers still in use that do not support remote frames at all, polled communication will only with reservation be recommended for operative running.
  
• Synchronized
  It is not only for drive applications that it is worthwhile to synchronize the determination of the input information and the setting the outputs. For this purpose CANopen provides the SYNC object, a CAN telegram of high priority but containing no user data, whose reception is used by the synchronized users as a trigger for reading the inputs or for setting the outputs.

PDO transmission types: Parameterization

The PDO transmission type determines how the transfer of the process data objects (PDOs) is triggered and how the received process data objects (PDOs) are treated:

The type of transmission is parameterized for RxPDOs in the objects at 0x1400ff, sub-index 2, and for TxPDOs in the objects at 0x1800ff, sub-index 2. In TwinCAT the PDO transmission type is set on the PDO tab under Transmission Type (see: PDO tab).

• Acyclic Synchronous:
  PDOs of transmission type 0 function synchronously, but not cyclically. An RxPDO is only evaluated after the next SYNC telegram. In this way, for instance, axis groups can be given new target positions one after another, but these positions only become valid at the next SYNC - without the need to be constantly outputting reference points.
  In contrast, a TxPDO determines its input data after a SYNC telegram (synchronous process image) and forwards its input data if the input data have changed.
  Transmission type 0 therefore combines the send reason „synchronized“ with the send reason “event-driven”.
  
• Cyclic Synchronous:
  With transmission types 1-240 the PDO is sent cyclically after each n-th SYNC (n=1...240). In this way it is possible to parameterise a fast cycle for digital inputs (n=1), for sample, while the data of the analog inputs are transferred in a slower cycle (e.g. n=10). RxPDOs generally do not differentiate between the transmission types 0...240. A received PDO is set to valid with the next SYNC telegram. The cycle time (SYNC rate) can be monitored (object 0x1006), so that if the SYNC fails the device reacts in accordance with the definition in the device profile, and switches, for sample, its outputs into the fault state.
  
  The SYNC telegram is coupled with the link task, so that new input data are available with each task start. If a synchronous PDO fails to materialize, this is detected and reported to the application.
  
• Asynchronous:
  The transmission types 254 + 255 are asynchronous or event-driven. In transmission type 254, the event is specific to the manufacturer, whereas for type 255 it is defined in the device profile. In the simplest case, the event is the change of an input value - this means that every change in the value is transmitted. The asynchronous transmission type can be coupled with the event timer, thus also providing input data when no event has just occurred. Once the set time has elapsed, this is interpreted as an additional event, and the input data are sent.

PDO Mapping

PDO mapping refers to mapping of the application objects (real time data) from the object directory to the process data objects. The CANopen device profile provide a default mapping for every device type, and this is appropriate for most applications. Thus the default mapping for digital I/O simply represents the inputs and outputs in their physical sequence in the transmit and receive process data objects.

The default PDOs for drives contain 2 bytes each of a control and status word and a set or actual value for the relevant axis.

The current mapping can be read by means of corresponding entries in the object directory. These are known as the mapping tables. The first location in the mapping table (sub-index 0) contains the number of mapped objects that are listed after it. The tables are located in the object directory at index 0x1600ff for the RxPDOs and at 0x1A00ff for the TxPDOs.

Digital and analog input/output modules: Read out the I/O number

The current number of digital and analog inputs and outputs can be determined or verified by reading out the corresponding application objects in the object directory:

Variable mapping

As a rule, the default mapping of the process data objects already satisfies the requirements. For special types of application the mapping can nevertheless be altered: the Beckhoff CANopen Bus Couplers, for instance, thus support variable mapping, in which the application objects (input and output data) can be freely allocated to the PDOs. The mapping tables must be configured for this: as from Version 4 of CANopen, only the following procedure is permitted, and must be followed precisely:

1. First delete the PDO (set 0x1400ff, or 0x1800ff, sub-index 1, bit 31 to "1")
2. Set sub-index 0 in the mapping parameters (0x1600ff or 0x1A00ff) to "0"
3. Change mapping entries (0x1600ff or 0x1A00ff, SI 1..8)
4. Set sub-index 0 in the mapping parameters to the valid value. The device then checks the entries for consistency.
5. Create PDO by entering the identifier (0x1400ff or 0x1800ff, sub-index 1).

Dummy Mapping

A further feature of CANopen is the mapping of placeholders, or dummy entries. The data type entries stored in the object directory, which do not themselves have data, are used as placeholders. If such entries are contained in the mapping table, the corresponding data from the device is not evaluated. In this way, for instance, a number of drives can be supplied with new set values using a single CAN telegram, or outputs on a number of nodes can be set simultaneously, even in event-driven mode.