Product overview
CX1500-M510, CX1500-B510 15Version: 1.0
2.3.3 Process Data Objects (PDO)
Introduction
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 the multi-master bus access
protocol allows CAN to offer other methods. Under CANopen the process data is not transferred in a master/
slave procedure, but follows instead the producer-consumer model. In this model, a bus node transmits its
data, as a producer, on its own accord. This might, for example, be triggered by an event. All the other nodes
listen, and use the identifier to decide whether they are interested in this telegram, and handle it accordingly.
These are the consumers.
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 PDOs each correspond to a CAN telegram, whose specific CAN
identifier is used to allocate them and to determine their priority. Receive PDOs (RxPDOs) and transmit
PDOs (TxPDOs) are distinguished, the name being chosen from the point of view of the device: an input/
output module sends its input data with TxPDOs and receives its output data in the RxPDOs. This naming
convention is retained in the TwinCAT System Manager.
Communication parameters
The PDOs can be given different communication parameters according to the requirements of the
application. Like all the CANopen parameters, these are also available in the device's object directory, and
can be accessed by means of the service data objects. The parameters for the receive PDOs are at index
0x1400 (RxPDO1) onwards. There can be up to 512 RxPDOs (ranging up to index 0x15FF). In the same
way, the entries for the transmit PDOs are located from index 0x1800 (TxPDO1) to 0x19FF (TxPDO512).
The BECKHOFF Bus Couplers or Fieldbus Coupler Box modules make 16 RxPDO and TxPDOs available
for the exchange of process data (although the figure for Economy and LowCost BK5110 and LC5100
Couplers and the Fieldbus Boxes is 5 PDOs each, since these devices manage a lower quantity of process
data). The FC510x CANopen master card supports up to 192 transmit and 192 receive PDOs for each
channel - although this is restricted by the size of the DPRAM. Up to 32 TxPDOs and 32 RxPDOs can be
handled in slave mode.
For each existing process data object there is an associated communication parameter object. The TwinCAT
System Manager 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.
PDO Identifier
The most important communication parameter in a PDO is the CAN identifier (also know as the
communication object identifier, or COB-ID). It is used to identify the data, and determines their priority for
bus access. For each CAN data telegram there may only be one sender node (producer), although all
messages sent in the CAN broadcast procedure can be received, as described, by any number of nodes
(consumers). Thus a node can make its input information available to a number of bus devices at the same
time - even without transferring them through a logical bus master. The identifier is located in sub-index 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 identifier itself. The data width of the object of 32 bits also allows 29-bit identifiers in
accordance with CAN 2.0B to be entered, although the default identifiers [}110] always refer to the more
usual 11-bit versions. Generally speaking, CANopen is economical it its use of the available identifiers, so
that the use of the 29-bit versions remains limited to unusual applications. It is therefore also not supported
by a Beckhoff's CANopen devices. The highest bit (bit 31) can be used to activate the process data object or
to turn it off.
A complete identifier list [}65] is provided in the appendix.
PDO linking
In the system of default identifiers, all the nodes (here: slaves) communicate with one central station (the
master), since slave nodes do not listen by default to the transmit identifier of any other slave node.