Rockwell Automation T80019 User Manual

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: [e-mail]

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