Rockwell Automation T80019 Application Note Working With Large Applications - Manual (Page 2)

Trusted TM
AN-T80019 Working with Large Applications
Issue 1 Sep 08 AN-T80019 2
Working with Large Applications
Function Block Local Variables
Functions and function blocks may contain local variables, defined in the dictionary. For functions, the
variables are discarded after running the function logic, and are initialised as new variables each time
the function is run. Only one set of variables is stored in memory. A function can be run many times,
but there is only one copy of the function logic and variables stored in memory.
Function blocks may also contain local variables, but the values are stored for the next scan. Each
time a function block is placed in a Function Block Diagram (FBD) program, a new area of memory is
allocated to store a copy of the local variables for that placement (called an instance).
This process is obvious to the user when creating function block instances in the dictionary for calling
in Structured Text (ST) programs, where the user has to name each instance and is therefore aware of
creating a new ‘copy of the function block’. However, most safety system programs are written in FBD,
where the function block instances are given temporary names by the compiler.
A complex function block which is called many times will require a lot of memory. A typical example is
input or output conditioning blocks which may include a variety of overrides, handoffs to DCS or
matrices, trip and reset logic, scaling, alarm thresholds etc. It is not uncommon for these function
blocks to be near the limit of 32 inputs and outputs. These blocks are allocated once for every channel,
often by an automated application creation tool (if a program is written by hand, it is more likely to be
optimised).
To reduce the memory usage of repetitive large function blocks:
• Consider if the block’s functionality is all necessary
• Consider if the block’s internal variables are all necessary
• Create reduced function blocks for channels that do not need some functionality
• Separate the functionality into a suite of blocks, if they are rarely all needed (note that wires
between blocks will also take memory, so do not replace one block with repetitive complex
sets)
• Consider ways to reduce the number of function blocks, e.g. by grouping digital inputs into
words and processing them simultaneously
• Some standard function blocks take more memory depending on their use, e.g. delay
functions; trim the block’s capability to the realistic need
The measures above will not save much scan time (the raw logic processing is usually only 5-10% of
the scan time) but they will save significant memory.
Other FBD memory reduction measures
• Some legacy system hybrids were written to imitate the logic of the old system; this may be
adding functionality or complexity that is no longer necessary. Consider optimising logic
function blocks and wired networks, starting with the most common examples.
• Turn off Power Flow Debugging (Options | Enable Power Flow Debugging should not be
ticked). Power flow debugging adds extra internal variables to allow the Toolset to allocate
colours to unnamed wires between function blocks. These internal variables can number
thousands in a large program. Power flow debugging is a useful tool for testing (e.g. on the
Target Simulator program) but takes extra memory.