Image Processing Reference
In-Depth Information
profile area) are used to describe all aspects concerning a specific class of devices in a standardized
way,asdeinedintherelateddeviceproile.
Other address ranges are either reserved for future use or concern new functionalities that are in
the process of being defined at the time of writing.
15.6.3 Process Data Objects
Real-time process data, involved in controlling the physical system, are exchanged in CANopen by
means of PDOs according to the producer/consumer scheme. Every PDO is mapped onto exactly one
CAN frame, so that it can be exchanged quickly and reliably. As a direct consequence, the amount of
data that can be embedded in one PDO is limited to  bytes at most. In most cases this is more than
sufficient to encode an item of process data.
From the point of view of devices, there are two kinds of PDO: transmit PDO (TPDO) and receive
PDO (RPDO). he former kind is produced (i.e., sent) by a node, whereas the latter is consumed by
the node itself (this implies they should not be discarded by the frame filtering function).
According to the predefined connection set, each node in CANopen can define up to four RPDOs
(from the application master to the device) and four TPDOs (from the device to the application mas-
ter). In the case more PDOs are needed, the PDO communication parameters of the device (stored
as entries in the OD) can be used to define additional messages—or to change the existing ones. his
is often sufficient to set up simple master/slave systems in small factory automation systems.
In network embedded systems, which need more flexibility and where device-to-device commu-
nication is required as well as multicasting, the PDO linking mechanism can be exploited. From a
practical point of view, this consists of configuring explicitly matching PDO communication param-
eters in two or more devices, so that they are enabled to exchange process data directly according to
the standard CAN paradigm.
Finally, by configuring the PDO mapping parameters—if supported by the device—it is possible
to define dynamically what application objects (i.e., process variables) will be included in each PDO.
15.6.3.1 PDO Transmission
The transmission of PDOs by CANopen devices can be triggered by some local event taking place
on the node—including the expiration of some timeout—or it can be remotely requested from the
master. his gives system designers a high degree of flexibility in choosing how devices interact, and
enables the features offered by intelligent devices to be exploited in a better way.
No additional control information is added to PDOs by the CANopen protocol, so that the com-
munication efficiency is kept as high as in CAN. The meaning of each PDO is determined directly
through the related CAN identifier only. As multicasting is allowed for PDOs, their transmission is
unconfirmed, i.e., the producer has no way to know whether or not a PDO was received by all the
intended consumers.
One noticeable feature of CANopen is that it can provide synchronous operations as well. In par-
ticular, the transmission type of each single PDO can be configured so that exchanges will be driven
by the occurrence of a synchronization event on the network, this event being generated regularly
by a node known as sync master (usually, it is the same node acting as the application master).
Synchronous data exchanges, in this case, take place in periodic communication cycles.
When synchronous operations are selected, commanded values are not actuated by devices imme-
diately as they are received, nor are sampled values transmitted. Instead, as depicted in Figure .,
each time a SYNC message is read from the network the synchronous PDOs received in the previous
communication cycle are actuated by every output device. At the same time, all sensors sample their
input ports and the related values are sent as soon as possible in the next cycle. The synchronous
windows length parameter can be defined, which specifies the time when it is certain that all the
 
Search WWH ::




Custom Search