Guide 1.

Performance Optimization for the Galileo 10 Runtime System

Revision History

Revision Remarks Date Sign

1.0 Initial version 2016-07-28 PDU

Eaton Automation GmbH

Spinnereistrasse 8-14
CH-9008 St.Gallen
Tel. +41 71 243 24 24
Fax +41 71 243 24 90
www.eaton.com

© Eaton Automation GmbH. All rights reserved.

 Performance Optimization for the Galileo 10 Runtime System
Guide, 1.0

Table Of Contents

1 Introduction........................................................................................................................................3
1.1 Purpose .....................................................................................................................................3
1.2 Terms ........................................................................................................................................3
1.3 References ................................................................................................................................3
2 Overview of specific performance problems .................................................................................4
3 Issues .................................................................................................................................................4
3.1 Large initialization script ............................................................................................................4
3.2 Large background images ........................................................................................................6
3.3 Overlapping controls .................................................................................................................7
3.4 Controls with transparencies .....................................................................................................9
3.5 Inaccessible pattern “Chessboard” .........................................................................................11
3.6 Entry script execution ..............................................................................................................12
3.7 Complex calculations in loop scripts .......................................................................................12
3.8 Permanent communication takes too much performance ......................................................13
3.9 Huge recipes ...........................................................................................................................13
3.10 Unused graph blocks ..............................................................................................................14
3.11 Minimal available free memory ...............................................................................................14
3.12 Overlapping controls check .....................................................................................................15

Performance Optimization Guide 2 / 15 2016-07-28

 Performance Optimization for the Galileo 10 Runtime System
Guide, 1.0

1 Introduction
Galileo offers customers great freedom and flexibility to create their own visualization. However, some
constellations and conditions could lead to loss in performance on the Galileo Runtime System. The im-
pacts could be: Slow screen changes, slow screen refreshes after some values have changed, communi-
cation to/from PLC is delayed, and so on. This especially affects less performant device families like XV-
400 and XV-100 while XV-300 and Galileo Open/Win32 usually have enough performance so it is not
needed to optimize anything.
Often, the root cause of performance problems can be eliminated easily by following a few rules.

1.1 Purpose
This document gives an overview of some issues causing possibly performance problems and also
shows how to solve them.
Because different issues can be responsible for multiple performance problems, the document is struc-
tured as follows:
- Chapter 2 gives an overview of possible performance problems and lists the issues, which could
cause them
- Chapter 3 describes the different issues, together with possible solutions to solve them

1.2 Terms
DT (or Galileo DT)
The Galileo Design Tool: The application for creating the visualization running on the PC

GRS
Galileo Runtime System: The application running on a panel, showing the visualization

PLC
Programmable Logic Controller

1.3 References
For further information see the help documentation included in every Galileo setup.

Performance Optimization Guide 3 / 15 2016-07-28

 Performance Optimization for the Galileo 10 Runtime System
Guide, 1.0

2 Overview of specific performance problems

Performance Problem Possible Issues

Screen change to the “Start Screen” is always slow 3.1, 3.6
Some screen changes are very slow 3.5, 3.6
After changing a value or pushing a button, the 3.2, 3.3, 3.4, 3.5
screen refresh is slow
Memory problems 3.9, 3.10
Others 3.7, 3.8, 3.11, 3.12

3 Issues

3.1 Large initialization script

Often, you want to initialize some data of Galileo (tag values, loaded recipes, …) when the visualization
starts up for the first time. A common way was, to do that initialization within a script and reference it on
the “Start Screen” of the project as the “Entry Script”.

Having defined it this way, GRS needs to evaluate the script content on every change to this screen.
Evaluating a script means for example, read all the tags used in the script synchronously from the PLC.

From Galileo 10.1.8 on, there’s a better way to accomplish this task. In the “Project Settings” dialog on
the “Runtime” tab you will find the setting “Startup Script”. Reference an initialization script there instead
as the “Entry Script” on a “Start Screen”:

Performance Optimization Guide 4 / 15 2016-07-28

 Performance Optimization for the Galileo 10 Runtime System
Guide, 1.0

An additional advantage of this solution is, that you no longer have to setup an “initialize once” construct
in the script in the type of:

if (isInit == FALSE)
...
isInit := TRUE;
endif

Performance Optimization Guide 5 / 15 2016-07-28

 Performance Optimization for the Galileo 10 Runtime System
Guide, 1.0

3.2 Large background images

Large background images should be especially avoided on less performant platforms (such like the XV-
400 series). It’s better to set the background color of a screen to accomplish the desired design.

Bad Good

- Background image (Texture) - Background color set on screen properties

- Gray background image with logo on the - Background color “Gray” set on screen
bottom right corner properties
- Logo placed as single, small image at the
bottom right corner

The reasons to not use large background images, are the following:
Drawing controls on the screen (especially if they have transparencies within them) causes also a redraw-
ing of the area (and the control(s)) laying behind them. In case of a large, maybe full screen size filling
image, this can be time consuming if the image needs to be loaded again from the storage device.

Performance Optimization Guide 6 / 15 2016-07-28

 Performance Optimization for the Galileo 10 Runtime System
Guide, 1.0

Example:

Large background image

Value Display with transparent background

Following happens, if “Value 1” changes its value:

- The “Value Display” control displaying “Value 1” is set to be redrawn
- Because of the transparency, the background image on the area covered by the “Value Display”
needs to be redrawn first
- Depending on the project, its memory consumption and the available memory on the device, it
can happen, that the background image is not cached and needs to be loaded from the storage
device again.

3.3 Overlapping controls

Having multiple overlapping controls can cause a chain of redrawing if one of the control changes its vis-
ualization. Take care that controls, which don’t need to overlap for design reasons, are placed side-by-
side.

A bad example:
The image area over-
laps the button. Every
“Value Displays” overlap time the button gets
each other. Changing one pressed, the image
value causes the neigh- needs to be redrawn.
bor(s) to redraw as well.

“Value Displays” laid

over a graph chart
area. Every time the
graph draws the line
for a value, the “Value
Displays” needs to be
redrawn also.

Performance Optimization Guide 7 / 15 2016-07-28

 Performance Optimization for the Galileo 10 Runtime System
Guide, 1.0

Better:
The image is placed next
to the “Button”.
“Value Displays”
placed next to each
other.

“Value Displays”
are placed outside
of the “Graph”
control.

Performance Optimization Guide 8 / 15 2016-07-28

 Performance Optimization for the Galileo 10 Runtime System
Guide, 1.0

3.4 Controls with transparencies

Controls having transparencies causes the overlapped/overlaid controls to be redrawn. Also, the drawing
performance for controls with transparencies is generally slower than drawing controls without any trans-
parency. Try to avoid transparencies in controls, these includes:
- Controls with transparent background
- Rounded rectangles
- Images with transparencies (attention: also graphics with rounded corners are affected)

Bad example:

“Button” with a
graphic having
rounded rectangles
as background.

“Graph” having
“Bargraph” having transparent back-
transparent back- ground and chart
ground color color

Performance Optimization Guide 9 / 15 2016-07-28

 Performance Optimization for the Galileo 10 Runtime System
Guide, 1.0

Better:

“Button” with a
graphic having no
transparencies as
background.

“Bargraph” having “Graph” having the

the same back- same background
ground color as the and chart color as
area behind. the area behind.

Performance Optimization Guide 10 / 15 2016-07-28

 Performance Optimization for the Galileo 10 Runtime System
Guide, 1.0

3.5 Inaccessible pattern “Chessboard”

The pattern “Chessboard” for inaccessible states is not really performant. It is recommended to use an-
other style instead (e.g. “Alpha blending):

Takes much time to draw

the “Chessboard”.

Faster (and also nicer

looking) “Alpha Blending”.

Performance Optimization Guide 11 / 15 2016-07-28

 Performance Optimization for the Galileo 10 Runtime System
Guide, 1.0

3.6 Entry script execution

The execution of (large) entry scripts can lead to the impression, that a screen buildup is slow.
In following case, there’s a possible solution existing:
All used entry scripts can be executed after the screen buildup without any noticeable effect, if
the script is not used for:
- Initialize data displayed/used on the screen (e.g. displayed by a “Value Display”, used as “Visibil-
ity” condition)
- Executing a conditional screen change to another screen

The effects of having the mentioned conditions fulfilled, are:

- Value displays may get updated after the screen is already displayed
- The complete screen is displayed before the new screen change is processed

If this requirement is fulfilled or the possible effects are bearable, you can enable the option “Delayed
Entry Script Execution” in the dialog “Project Settings”:

3.7 Complex calculations in loop scripts

Although Galileo offers the possibility to do some calculations within scripts, for huge and complex calcu-
lations it makes more sense to perform them directly on the PLC rather than within a loop script of Gali-
leo.

Performance Optimization Guide 12 / 15 2016-07-28

 Performance Optimization for the Galileo 10 Runtime System
Guide, 1.0

3.8 Permanent communication takes too much performance

The communication to the PLC has a higher priority than the rest of the visualization. If now a faster re-
sponsive visualization is more important than the almost immediate update of value changes on the PLC,
there’s the setting “Min. Cycle Time” which can be set for every communication in the project:

Increasing the time gives the visualization more time for drawing and handling background stuff but val-
ues from the PLC will be updated less frequently.
The default value is 50ms.

3.9 Huge recipes

Try to avoid recipes with hundreds of tags and entries. Loading and writing such recipes takes a lot of
time, especially on slow storage media like the “StorageCard” on the XV-400 series.
If the large recipe is used for configuring a machine, it may be better to configure it through the PLC.

Performance Optimization Guide 13 / 15 2016-07-28

 Performance Optimization for the Galileo 10 Runtime System
Guide, 1.0

3.10 Unused graph blocks

In projects developed for multiple machines, it can be the case, that multiple graph blocks are defined but
only a few are actively used for a specific machine.
By default, Galileo creates all graph blocks memory buffers on startup which means, that memory gets
reserved for the graph blocks.

To avoid this behavior, the parameter “CreateGraphBufferOnDemand” can be set in the “Advanced Set-
tings” page in the “Project Settings” dialog.
For every graph block, you can define whether its memory buffer should be created on startup (value 1)
or on demand (value 0).

Such a configuration could look like:

CreateGraphBufferOnDemand=1 0 1 0 0

This setting means:

- Memory buffer for first graph block will be created on startup
- Memory buffer for second graph block will be created on demand
- Memory buffer for third graph block will be created on startup
- Memory buffer for fourth and fifth graph block will be created on demand

The order of the graph blocks corresponds with the graph block IDs. Lowest ID represents the first entry,
second lowest the second entry and so on.

The disadvantage of setting a graph block setting to “0” is, that on first use of a graph, some extra time is
needed to reserve the memory and therefore the starting of the graph recording could be delayed.

3.11 Minimal available free memory

This option can be set to ensure a minimum amount of memory to keep free from caching. This might be
necessary because some screen or execution may cause the system to use a lot of memory at once
which would lead to a crash if not available. Setting this option gives a possibility to control the caching
mechanisms on how much memory to use.

Such a configuration could look like:

MinimumFreeMemory=5

Performance Optimization Guide 14 / 15 2016-07-28

 Performance Optimization for the Galileo 10 Runtime System
Guide, 1.0

3.12 Overlapping controls check

Before a control is drawn, it is checked whether it is overlapped by a non-transparent object (and there-
fore not visible at all). If so, it is not drawn and therefore not re-calculated (if needed). This can save a lot
of time. However, if there are a lot of controls on the screen which do not overlap, the overhead caused
by the overlap checks decreases performance dramatically for no reason. Hence, it depends on the
screen design whether this check makes sense or not.

Therefore, this check can be adjusted to three options (use the appropriate value in the configuration):
1= Full overlap check (default): every object is checked whether it is overlapped
2= Overlapped by keyboard only: Check an object whether a keyboard is opened and overlapping
(reduces checks)
3= Disable all checks

Such a configuration could look like:

OverlapCheck=1

Performance Optimization Guide 15 / 15 2016-07-28