BECKHOFF FC5101 - Manual (Page 50)

Eiserstraße 5 / D-33415 Verl / Telefon 05246/963-0 / Telefax 05246/963-149
50
the transmit PDOs can be set using progress timers: the telegram is not sent again before the inhibit
time has elapsed, and not later than the time required for the progress timer to complete.
· The communication type is parameterised by means of the transmission type.
It is also possible to combine the two PDO principles. It can, for instance, be helpful to exchange the set and
actual values of an axis controller synchronously, while limit switches, or motor temperatures with limit values
are monitored with event-driven PDOs. This combines the advantages of the two principles: synchronicity for
the axis communication and short reaction times for limit switches. In spite of being event-driven, the distributed
limit value monitoring avoids a constant addition to the bus load from the analog temperature value.
In this example it can also be of value to deliberately manipulate the identifier allocation, in order to optimise
bus access by means of priority allocation: the highest priority is given to the PDO with the limit switch data,
and the lowest to that with the temperature values.
Optimisation of bus access latency time through modification of the identifier allocation is not, however, nor-
mally required. On the other hand the identifiers must be altered if "masterless" communication is to be made
possible (PDO linking). In this example it would be possible for one RxPDO for each axis to be allocated the
same identifier as the limit switch TxPDO, so that alterations of the input value can be received without delay.
Determining the Bus Loading
It is always worth determining the bus loading. But what bus loading values are "permitted", or indeed sensible?
It is first necessary to distinguish a short burst of telegrams in which a number of CAN messages follow one
another immediately - a temporary 100% bus loading. This is only a problem if the sequence of receive inter-
rupts that it caused at the CAN nodes can not be handled. This would constitute a data overflow (or "CAN
queue overrun"). This can occur at very high baud rates (> 500 kbit/s) at nodes with software telegram filtering
and relatively slow or heavily loaded microcontrollers if, for instance, a series of remote frames (which do not
contain data bytes, and are therefore very short) follow each other closely on the bus (at 1 Mbit/s this can gen-
erate an interrupt every 40 µs; for example, an NMT master might transmit all its guarding requests in an un-
broken sequence). This can be avoided through skilled implementation, and the user should be able to assume
that the device suppliers have taken the necessary trouble. A burst condition is entirely normal immediately
after the SYNC telegram, for instance: triggered by the SYNC, all the nodes that are operating synchronously
try to send their data at almost the same time. A large number of arbitration processes take place, and the tele-
grams are sorted in order of priority for transmission on the bus. This is not usually critical, since these tele-
grams do contain some data bytes, and the telegrams trigger a sequence of receive interrupts at the CAN no-
des which is indeed rapid, but is nevertheless manageable.
Bus loading most often refers to the value averaged over several primary cycles, that is the mean value over
100-500 ms. CAN, and therefore CANopen, is indeed capable of managing a bus loading of close to 100% over
long periods, but this implies that no bandwidth is available for any repetitions that may be necessitated by in-
terference, for asynchronous error messages, parameterisation and so on. Clearly, the dominant type of com-
munication will have a large influence on the appropriate level of bus loading: a network with entirely cyclic syn-
chronous operation is always in any case near to the "worst case" state, and can therefore be operated with
values in the 70-80% range. The figure is very hard to state for an entirely event-driven network: an estimate
must be made of how many events additional to the current state of the system might occur, and of how long
the resulting burst might last - in other words, for how long the lowest priority message will be delayed. If this
value is acceptable to the application, then the current bus loading is acceptable. As a rule of thumb it can usu-
ally be assumed that an event-driven network running with a base loading of 30-40% has enough reserve for
worst-case scenarios, but this assumption does not obviate the need for a careful analysis if delays could have
critical results for the plant.
The Beckhoff FC510x PC cards indicate the bus loading via the System Manager. This variable can also be
processed in the PLC, or can be displayed in the visualisation system.
The amount data in the process data objects is of course as relevant as the communication parameters: the
PDO mapping.