Pdo Parameterization - Beckhoff FC5101 Documentation

5.4

PDO Parameterization

Even though the majority of CANopen networks operate satisfactorily with the default settings, i.e. with the
minimum of configuration effort, it is wise at least to check whether the existing bus loading is reasonable:
80% bus loading may be acceptable for a network operating purely in cyclic synchronous modes, but for a
network with event-driven traffic this value would generally be too high, as there is hardly any bandwidth
available for additional events.
Consider the Requirements of the Application
The communication of the process data must be optimized in the light of application requirements which are
likely to be to some extent in conflict. These include
• Little work on parameterization - useable default values are optimal
• Guaranteed reaction time for specific events
• Cycle time for regulation processes over the bus
• Safety reserves for bus malfunctions (enough bandwidth for the repetition of messages)
• Maximum baud rate - depends on the maximum bus length
• Desired communication paths - who is speaking with whom
The determining factor often turns out to be the available bus bandwidth (bus load).
Baud rate
We generally begin by choosing the highest baud rate that the bus will permit. It should be borne in mind that
serial bus systems are fundamentally more sensitive to interference as the baud rate is increased. The
following rule therefore applies: just as fast as necessary. 1000 kbit/s are not usually necessary, and only to
be unreservedly recommended on networks within a control cabinet where there is no electrical isolation
between the bus nodes. Experience also tends to show that estimates of the length of bus cable laid are
often over-optimistic - the length actually laid tends to be longer.
Determine the Communication Type
Once the baud rate has been chosen it is appropriate to specify the PDO communication type(s). These
have different advantages and disadvantages:
• 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 / EL6751
CANopen terminal 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
[} 44], 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
FC5101 and FC5102 Version: 2.0
CANopen Communication
51