Trusted
TM
AN-T80019
Application Note
Working with Large Applications
The 8110B processor has 1MB of memory set aside for storing the application, with another 1MB
allocated to allow an online update to be loaded without disturbing the running application. 64KB of the
1MB is allocated to storing the System.INI file, which is plenty because the System.INI files are rarely
larger than 15KB.
The remaining 960KB is allocated to the application download. A reasonable approximation to the size
of this download is the size of the appli.x6m file in the application folder after full compilation, although
this is not exactly the same data as the download. The download contains the application code, the
symbol table (database of variables) and if it is an intelligent update, a recipe of matches between the
old and new symbol table to allow the processor to copy the variable values for a bumpless transfer.
The intelligent online update recipe may be large or small, depending on the effect of the changes
made to the application. The symbol table contains all dictionary variables, but also internal variables
used to hold the value of corner connections, program constants and wires between function blocks in
FBD programs. The names of these internal variables are set at compilation and may change
depending on the effects of the editing on the source code. The update recipe must track all these
changes, and the recipe can be large or small depending on the hidden changes. This will change the
size of the download in an apparently random way.
For some large applications, the random size of the update recipe may make the download exceed
960KB, making the update impossible.
This document describes the factors that affect the size of the application download and advises on
how it can be reduced.
For technical support email: support@icstriplex.com
Issue Record
Issue
Number
1 Sep 08 Nick Owens Andy Holgate Pete Stock Initial Issue
Date Revised by Technical
Check
Authorised by Modification
Issue 1 Sep 08 AN-T80019 1
Trusted
TM
AN-T80019 Working with Large Applications
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.
Issue 1 Sep 08 AN-T80019 2
Trusted
TM
AN-T80019 Working with Large Applications
• Connection corners add extra variables and can cause problems with online updates (before
Toolset version 3.5.1 build 111). If a program has ‘join the dots’ style wiring, with many
onnection corners connected to each other, delete the corners and wire directly from the
c
source. You can tidy these wires by selecting them all and typing Ctrl-A.
• Look for redundant logic, such as spare logic allocated for unused channels, logic that has
been skipped using permanent Jump instructions, or spare copies of logic to allow normal
online updates to run. None of these are required.
Further memory reduction measures
• The Toolset has settings in a file called isa.ini. This is
located in the \Toolset\exe folder. Under the [EDIT]
section are four settings which define how many spare
variables are allocated in the symbol table for each
program. These spares are used for normal online
updates, where the symbol table must not change.
However, intelligent online updates are able to replace
the symbol table, and so these spare variables are no
longer necessary (they only allowed changes in about
1% of cases anyway).
If you have many programs in an application, these spares are
multiplied many times.
Change the settings to zero or delete the four lines.
MNTVboo means ‘amount of’ Booleans, MNTVana means
‘amount of’ analogues etc, allocated per program.
• Remove unused variables. You can use the Cross Reference tool to find unused variables.
• Program in Structured Text instead of FBD. This encourages the use of compact code. FBD is
translated into ST on compilation; programming directly in ST will eliminate inefficient code.
If it still won’t fit
• When possible, schedule a system shutdown and load the application using a Stop and
Download (having applied all the appropriate optimisations above). This will have no intelligent
update recipe attached.
• Add new code to a new program. It could be that editing a large program has caused an
oversized update recipe; if the logic can be added in a new program then it will not affect the
update recipe.
• Check for the issues in TA20005 using the program tool (see AN-80018). The intelligent
updater may be confused by duplicate IDs in programs.
Issue 1 Sep 08 AN-T80019 3
Loading...