CANopen Communication
FC5101 and FC5102
44
Version: 2.0
5.0070 281 4 00 00 00 00 00 00 00 00
5.0094 701 1 05 T0 Operational
5.0153 281 4 00 00 08 00 00 00 08 00
5.0174 281 4 00 00 00 00 00 00 00 00
5.1129 701 1 05 T0 Operational
....
5.4755 00 2 01 00 Start all nodes
Now all nodes are started
5.4847 201 1 00 00
approx. 1 sec after start of node 1 the RxPDO1 is sent for the first time
5.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. The EL6751 CANopen terminal dynamically organizes
the process image; i.e. the process data are written in succession, enabling a higher data transmission rate.
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 known 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 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
