ware Release Notes) helps finding out which libraries and functions/function
blocks are made available in which firmware.
8.5.12
Code optimization
Requirements on the real-time be‐
havior of the application
Drive control and drive-integrated PLC share the computing power of the
drive, the drive control taking up a large part of the computing power of the
drive. To use the available calculating time in the best possible way, it is first
necessary to check which demands are made on the real-time behavior of
the application:
●
Which functionalities must be called in certain time intervals or in the
case of certain events?
●
What happens when a function is not completed at the desired point of
time?
●
Is it necessary to use a task in synchronism with master communication
or a task in synchronism with CCD
?
Task system
The first approach to the task configuration of the application results from the
requirements on the real-time behavior of the application. Generally, several
tasks should be used to separate functions with long runtimes from functions
which must run in real time. Each task requires calculating time to manage
and control the task system. The more tasks have been configured, the more
calculating time must be spent for the management of the tasks.
Generally, only the necessary code should be processed in time-critical
tasks. Too short intervals should not be used for the tasks.
Using tasks of different velocity only makes sense when relatively few actions
must be processed very quickly and other actions run in a slower task (e.g. a
task with t#1ms and a task with t#10ms).
Besides, it is necessary to consider whether a watchdog must already be trig‐
gered when a task is exceeded once, or whether the watchdog can be more
tolerant.
As an alternative to a multi-task system, all fast actions can at first
be carried out in a task and then only one slower action at a time
(CASE instruction).
However, if the slower actions require more calculating time, they
must be carried out in a separate task.
String processing
The processing of strings is relatively slow. If possible, it is to be avoided with
rapid task cycles.
IEC language selection
The programming language "Structured Text" (ST) is recommended for per‐
formance-optimized programming. "ST" also provides clearly structured pro‐
gramming.
Program code
●
Bit processing is clearly slower than byte processing. This applies to ad‐
dressed variables and bit access in words (e.g., %IX0.0 inputs,
%QX0.0 outputs, flags or bit access).
●
Division of integer types is clearly slower than REAL division.
I/O configuration
The I/O mapping to BOOL variables (8 bits long) is clearly faster than bit vari‐
ables (e.g.,
%IX0.0
).
Using IEC constants
Using
VAR CONSTANT
is faster than using constant values in the form of nor‐
mal variables. Variable addressing is not required, the value is directly used.
Task in synchronism with CCD is only possible with MLD-M
Bosch Rexroth AG
DOK-INDRV*-MLD3-**VRS*-AP02-EN-P
234/267
Rexroth IndraDrive Rexroth IndraMotion MLD (2G) as of MPx-18
Programming information
LSA Control S.L. www.lsa-control.com [email protected] (+34) 960 62 43 01