Beckhoff CX1500-M510 Manual page 105

• Cyclic synchronous communication provides an accurately predictable bus loading, and therefore a
defined time behavior - you could say that the standard case is the worst case. It is easy to configure:
The SYNC rate parameter sets the bus loading globally. The process images are synchronized: Inputs
are read at the same time, output data is set valid simultaneously, although the quality of the
synchronization depends on the implementation. The Beckhoff FC510x PC cards are capable of
synchronizing the CANopen bus system with the cycles of the application program (PLC or NC).
The guaranteed reaction time under cyclic synchronous communication is always at least as long as
the cycle time, and the bus bandwidth is not exploited optimally, since old data, i.e. data that has not
changed, is continuously transmitted. It is however possible to optimize the network through the
selection of different SYNC multiples (transmission types 1...240), so that data that changes slowly is
transmitted less often than, for instance, time-critical inputs. It must, however, be borne in mind that
input states that last for a time that is shorter than the cycle time will not necessarily be communicated.
If it is necessary for such conditions to be registered, the associated PDOs for asynchronous
communication should be provided.
• Event-driven asynchronous communication is optimal from the point of view of reaction time and the
exploitation of bus bandwidth - it can be described as "pure CAN". Your choice must, however, also
take account of the fact that it is not impossible for a large number of events to occur simultaneously,
leading to corresponding delays before a PDO with a relatively low priority can be sent. Proper network
planning therefore necessitates a worst-case analysis. Through the use of, for instance, inhibit time
[} 15], it is also necessary to prevent a constantly changing input with a high PDO priority from blocking
the bus (technically known as a "babbling idiot"). It is for this reason that event driving is switched off by
default in the device profile of analog inputs, and must be turned on specifically. Time windows for the
transmit PDOs can be set using progress timers: the telegram is not sent again before the inhibit time
[} 15] has elapsed, and not later than the time required for the progress timer to complete.
• The communication type is parameterized by means of the transmission type [} 15].
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 optimize
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.
Optimization of bus access latency time through modification of the identifier allocation is not, however,
normally required. On the other hand the identifiers must be altered if masterless communication is to be
made possible (PDO linking [} 15]). 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
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 interrupts 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 generate an interrupt every 40 µs; for example, an NMT master might transmit all its
guarding requests in an unbroken 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 telegrams are sorted in order of priority for transmission on the bus. This is
not usually critical, since these telegrams do contain some data bytes, and the telegrams trigger a sequence
of receive interrupts at the CAN nodes which is indeed rapid, but is nevertheless manageable.
CX1500-M510, CX1500-B510 Version: 1.0
Product overview
105