BECKHOFF FC5101 - Manual (Page 42)

Eiserstraße 5 / D-33415 Verl / Telefon 05246/963-0 / Telefax 05246/963-149
42
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 pro-
cedure, 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 (Rx) PDOs and transmit (Tx) PDOs are distin-
guished, the name being chosen from the point of view of a 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 Twin-
CAT 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 ac-
cessed 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 en-
tries for the transmit PDOs are located from index 0x1800 (TxPDO1) to 0x19FF (TxPDO512).
The Bus Couplers or Fieldbus Box modules make 16 RxPDO and 16 TxPDOs available for the exchange of
process data (although the figure for Economy and LowCost BK5110 and LC5100 couplers and the Compact
Box modules is 5 PDOs each, since these devices manage a lower quantity of process data).
The FC5x10x 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 192 TxPDOs and 192 RxPDOs can also 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 en-
tries 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 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 identifier itself. The
data width of 32 bits also allows 29-bit identifiers in accordance with CAN 2.0B to be entered, although the
default identifiers always refer to the more usual 11-bit versions. Generally speaking, CANopen is economical
in its use of the available identifiers, so that the use of the 29-bit versions remains limited to unusual applica-
tions. The highest bit (bit 31) can be used to activate the process data object or to turn it off.
A complete identifier list is provided here.
PDO Linking
In the system of default identifiers, all the nodes (here: slaves) communicate with one central station (the mas-
ter), since slave nodes do not listen by default to the transmit identifier of any other slave node.