User guide

Lenze · 9400 function library · Reference manual · DMS 6.7 EN · 08/2014 · TD05 35
2Introduction
2.8 Multitasking in the Servo Drive 9400
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
2.8.2 Optimising the runtime behaviour
The following points should be considered for an optimum runtime behaviour of the controller:
• Before you start programming, check which response times are required for which functions.
This defines in which task the corresponding functions are to be programmed and which inter-
val time must be set for the corresponding task. A subsequent optimisation of programs is very
time-consuming and error-prone!
• High-priority, quick tasks must always be programmed runtime-efficiently. The less logic is exe-
cuted in the quick task, the more resources are available for the other tasks!
• The runtimes of the time-controlled user tasks must not be higher than 95 % of the interval time
of the corresponding task.
• If, for example, the ApplicationTask is loaded with 70 %, only the 25 % are available for the
UserTask and the IdleTask.
• Check the runtimes by means of the runtime measurement. Runtime measurement
( 33)
• If the runtime of the ApplicationTask is higher than 950 μs with an interval time of 1 ms, check
first if the interval time of the ApplicationTask can be increased from 1 ms to 2 ms. This is the
case if:
• the setpoints in the application are generated in an interval higher than 2 ms, as for example
with positioning drives or actuating drives with internal ramp generation or slave drives with
a setpoint selection. Slave drives with a setpoint generation in an interval lower than 2 ms are
excluded.
• no time-critical operation of digital outputs is required as for example with a cam group.
• An increase of the interval time only causes a minimum deterioration of the drive behaviour if
the motion setpoints are generated in the controller.
• The activation/deactivation of the three setpoint interpolators (C02550/1…3) has no influence
on the task runtime.
• In a second step, the logics from the ApplicationTask should be sourced out into one of the other
two tasks.
• Time-critical logics should remain in the ApplicationTask.
• Logics (modules) which require a time-equidistant execution and do not need to be executed
in the ApplicationTask should be transferred to the UserTask.
• Logics (modules) the execution of which is not time-critical and not time-equidistant should
be transferred to the IdleTask.
• When the project is based on a technology application by Lenze, the logic which has no influ-
ence on the application function, e.g. non-used ports with connected signal converters, should
be deleted from the ApplicationTask after activating the FB Editor.
• Deleting non-required system blocks from the FB interconnection does not influence the task
runtime.