CANopen system overview
CXxxxx-M510/B510
14
Version: 1.0
2.1.3
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:
Содержание CX-B510 Series
Страница 2: ......
Страница 36: ...TwinCAT tabs CXxxxx M510 B510 36 Version 1 0 4 3 CANopen slave 4 3 1 CAN node 1 3 7 11 13 5 6 2 12 8 9 4 10...
Страница 80: ......