VISU+ BEST PRACTICE

Tips for using the Visu+ software

Application note
8212_en_01
1

PHOENIX CONTACT 2013-10-21

Description

This document provides support in finding the optimum

hardware platform (Windows PC with Win32 or touch panel
with WinCE) for a Visu+ visualization project as well as
optimizing the performance of existing Visu+ projects.
Various methods are presented which show you how you
can optimize Visu+ projects for HMI devices with WinCE.
This document also presents a powerful tool in the Visu+
software: the Refactoring Explorer, which enables you to
detect critical design errors during the development phase.
A complete overview of the differences between and the
limitations of the Visu+ 2 CE runtime environment and the
Visu+ 2 runtime environment is not provided in this
document. For information on this, please refer to the data
sheet for Visu+ 2.x (DB EN VISU+ 2...). The data sheet can
be downloaded at phoenixcontact.net/products.

Make sure you always use the latest documentation.

It can be downloaded at phoenixcontact.net/products.

VISU+ BEST PRACTICE

Table of contents

Description.................................................................................................................................. 1

Table of contents ........................................................................................................................ 2

Hardware requirements .............................................................................................................. 3

Software requirements................................................................................................................ 3

Starting a project......................................................................................................................... 3
5.1
5.2
5.3
5.4

Design of the screens..................................................................................................................................... 3

OPC communication ...................................................................................................................................... 3
Communication drivers................................................................................................................................... 4
License restrictions ........................................................................................................................................ 4

Refactoring Explorer ................................................................................................................... 5

6.1
6.2

Displaying the Refactoring Explorer ............................................................................................................... 5

Using the Refactoring Explorer....................................................................................................................... 6

Memory management................................................................................................................. 7

Screen properties ....................................................................................................................... 9

8.1
8.2

Recommended maximum number of objects ................................................................................................. 9

Memory management for screens................................................................................................................ 11

Managing OPC items.................................................................................................................13

9.1
9.2
9.3

Optimizing an OPC group............................................................................................................................. 13

Dynamic assignment of OPC items to variables ........................................................................................... 13
Synchronizing OPC items............................................................................................................................. 14

10 Scripts .......................................................................................................................................15
10.1
10.2

Global scripts ............................................................................................................................................... 15

Local scripts ................................................................................................................................................. 16

11 Databases .................................................................................................................................17
11.1
11.2
11.3

IMDB ............................................................................................................................................................ 17
ODBC........................................................................................................................................................... 18
General recommendations regarding the use of databases ......................................................................... 19

12 Debugging .................................................................................................................................19

8212_en_01

PHOENIX CONTACT

VISU+ BEST PRACTICE

Hardware requirements
OT xx
TP xxx
TP 3xxx

Software requirements

Visu+ 2.xx
AX OPC Server 2.40.xx or later

Starting a project

Before you start a project it is very important to define the

requirements of the project in order to determine which
hardware platform (Win32 or WinCE) or license fits best
(Win32).
It is useful to prepare a checklist as follows:
Design of the screens (resolution, number, and type of
objects)
Total number of I/O variables
Communication protocol to be used
Required web clients
Redundancy functions
Use and size of databases
Communication between Visu+ applications

Graphical elements
Various graphical elements are available in Visu+.
The following table provides an overview.
Function
Color
Linear filling
Polygonal filling
Rotation
Dynamic X, Y movement
Graphical objects
Symbol libraries
3D buttons/gauges
Trend
Diagram
DB Viewer
Embedded screens
1

PC runtime environment

Recommended maximum number of objects on a

screen
Hardware platform
TP xxx / OT xx
TP 3xxx
Win32
(PC runtime)

Design of the screens

Screens are the central component of a visualization. They

represent the interface via which the user can interact with
the visualized process.
The design of the screens has a large influence on the
required resources and also on the graphical capabilities of
the hardware platform. It is also very important for the
definition of the hardware and runtime requirements.

Win321
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes

Due to the limitations in WinCE, not all of the

available functions and objects can be used on a
HMI device.

This list is only a suggestion, the requirements

may vary depending on the project.
5.1

TP xxx
Yes
Yes
No
No
Yes
Yes
Yes
No
Yes
No
Yes
Yes

5.2

Recommended maximum
number of objects
64
128
Unlimited1

Depends on the performance of the PC system used

OPC communication

The OPC (OLE for Process Control) interface offers a quick

and easy way to exchange data from a Phoenix Contact
controller with a visualization project. OPC items can be
used to link a variable to a process data item from the
controller directly in Visu+, whereby the process data item
must be enabled for communication via the OPC interface.
Use the AX OPC server to enable process data
from Phoenix Contact controllers via the OPC
interface.

8212_en_01

PHOENIX CONTACT

VISU+ BEST PRACTICE

Windows PC (Win32)
On a Windows PC, a distinction is made between the local
OPC server and the remote OPC server. Any OPC server
can be used as the local server provided you are not using
a Phoenix Contact controller. If using Phoenix Contact
controllers, the AX OPC server must be used as the local
server.
The DCOM interface of the PC must be configured
accordingly in order to use a remote OPC server. For
information regarding the configuration of the DCOM
interface, please visit www.opcfoundation.org.
HMI device/touch panel (WinCE)
The AX OPC server is installed as standard on a touch
panel. It cannot be replaced by another server.
It is not possible to use a remote OPC server with a touch
panel.
5.3

Communication drivers

Visu+ supports the following communication drivers for data

exchange via different bus systems:
CAN/CANopen
IEC 60870-5-104
IEC 60870-5-101
Modbus TCP
Modbus RTU
INTERBUS
PROFIBUS
EtherNet/IP
S7-MPI
Ethernet S7-300/400 TCP
RS-232
The number of communication drivers that can be used
depends on whether a Windows PC (Win32) or a touch
panel (WinCE) is used. For information on this, please refer
to the data sheet for Visu+ 2.x (DB EN VISU+ 2...). The data
sheet can be downloaded at phoenixcontact.net/products.
Windows PC (Win32)
A Visu+ RT-D license is required to use communication
drivers.

The following system limits apply:

Maximum of two communication drivers
Maximum of 128 stations at each communication driver
Runtime configurations with additional
communication drivers (64, maximum) are
available on request.
Please contact your nearest Phoenix Contact
representative.
HMI device/touch panel (WinCE)
The license for the communication drivers is already
included with touch panels from Phoenix Contact.
With standard touch panels (TP xx / OT xx), only the
Ethernet-based communication drivers can be used:
IEC 60870-5-104
Modbus TCP
EtherNet/IP
Ethernet S7-300/400 TCP
A TP 3xxx series touch panel is required in order to use
other communication drivers. The following table shows
which touch panels support which drivers:
Touch panel
TP 3xxxT/M PB
TP 3xxxT/M MPI
TP 3xxxT/M CO
TP 3xxxT/M SER

Communication driver
PROFIBUS
S7-MPI
CANopen
RS-232

The following system limits apply:

Maximum of two communication drivers
Maximum of 128 stations at each communication driver
5.4

License restrictions

Depending on the license or runtime version, there are

limitations with regard to the maximum number of
permissible I/O variables (I/O bytes). The I/O bytes are
transmitted via the OPC interface or the communication
driver. The number of local project variables is not limited,
however. The following table shows the maximum number
of permissible I/O bytes depending on the hardware
platform used:

Some communication drivers (e.g., CAN/CANopen,

INTERBUS) require additional hardware components. For
additional information, please refer to the documentation for
the respective communication driver.

8212_en_01

PHOENIX CONTACT

VISU+ BEST PRACTICE

Hardware platform
TP xxx / OT xx
TP 3xxx
Win32
(PC runtime)
1

Max. number of I/O bytes

4096
4096
Depends on the license1

100,000 bytes recommended for an unlimited license.

Only active I/O bytes are relevant for the license

and are calculated during runtime.
Checking the number of I/O bytes
Visu+ includes a function to calculate the number of I/O
bytes actually used. Using this function, you can check
whether the planned or existing Visu+ RT license is
sufficient to cover your visualization project or whether the
license has already been exhausted.
Proceed as follows to use this function:
Start your visualization project by clicking on the Start
button.

Figure 1

During runtime all I/O bytes declared in the visualization

project and all I/O bytes that are actually used are detected.
Stop your visualization project and return to
development mode.
Open the Edit, Check License needs (License
Requirements)... menu.
The License Requirements tab shows all detected I/O
bytes.
Add a reserve of 20% to the number given in the Used
(max peek detected) column and check whether your
license is sufficient for the calculated number of I/O
bytes.

License manager: checking the number of I/O

bytes

Recommendation: before starting the project,

create a list of the required I/O variables
(communication drivers and OPC) and allow for a
reserve of at least 20% in order to determine the
license needed.

Refactoring Explorer

The Refactoring Explorer is a powerful tool which enables

you to detect and avoid critical design errors during the
development process. Such errors include, for example,
incorrectly assigned variables, off-screen objects, and
communication problems.
Recommendation: check all the objects of your
Visu+ project with the Refactoring Explorer.
6.1

Displaying the Refactoring Explorer

The Refactoring Explorer is activated by default and is

available as soon as Visu+ is started.
If the Refactoring Explorer is not displayed, it can be opened
via the View, Refactoring Explorer menu.

8212_en_01

PHOENIX CONTACT

VISU+ BEST PRACTICE

Figure 3

Refactoring Explorer

The following buttons are available in the Refactoring

Explorer:
Open:

Display jumps to the faulty

object in the screen

Rebuild:

Rebuilds the list

Stop build:

Aborts the build process

When you double-click on an error description in the

Refactoring Explorer, the display jumps to the object in
question. Alternatively, you can highlight the error
description and click on the Open button. The display then
likewise jumps to the object in question.
Figure 2
6.2

Opening the Refactoring Explorer

Using the Refactoring Explorer

The Refactoring Explorer can be used for the following

Visu+ components:
Screens
Alarms
Data loggers
Recipes
Event objects
Scheduler objects
Scaling objects
OPC Client
Click on a component of your visualization that you
want the Refactoring Explorer to check.

Example: off-screen objects

The visible area of the visualization is predetermined by the
screen dimensions. All objects outside these boundaries
are not displayed, however they are still included in the
calculated screen objects. These objects can result in
performance losses even though the objects do not actually
contribute to the visualization of the process.
Figure 4 shows an object (red square) that is off screen.

The Refactoring Explorer then scans all the objects of the

selected component. The results are displayed in the
Refactoring Explorer together with a brief error description.

8212_en_01

PHOENIX CONTACT

VISU+ BEST PRACTICE

Figure 6

Figure 4

Off-screen object

After selecting the screen and scanning it with the

Refactoring Explorer, a corresponding error message is
displayed in the Refactoring Explorer (see Figure 5).

Object partially off screen

Memory management

In the development environment of Visu+, you can create

both platform-independent (Win32, WinCE) projects and
platform-specific projects for touch panels from Phoenix
Contact. To get the best possible results in terms of
performance for HMI devices (TP xxx / TP 3xxx), the project
should be adapted to the HMI device.
HMI device/touch panel (WinCE)
All HMI devices from Phoenix Contact come with Windows
CE (WinCE) Version 5.0 or 6.0 operating system. The
following table provides an overview:
Embedded HMI device

Figure 5

Object error description in the Refactoring

Explorer

When you double-click on the error message, the display

jumps to the faulty object in the screen. Here the faulty
object can be deleted or positioned correctly.
An object must be completely off screen for it to
be detected as a faulty object by the Refactoring
Explorer.
When creating your visualization, make sure that
all object are placed within the screen
boundaries.
Figure 6 shows an object (red square) that is only partially
off screen. This object is not detected as a faulty object by
the Refactoring Explorer.

8212_en_01

TP xxx / OT xx
TP xxT/M 201
TP 3xxxT/M xx
TP 5xxxT
TP 5xxxC
TP xxT/M 211

WinCE
version
5.0
6.0

A big difference between the two WinCE versions is

memory management. WinCE 5.0 is only able to manage
processes with a maximum of 32 MB of memory. If a
process requires more memory, the system will no longer
have sufficient memory capacity and Windows will stop the
process. A simplified illustration of memory management for
a TP xxx is shown in Figure 7.

PHOENIX CONTACT

VISU+ BEST PRACTICE

Visu+ RT

Key:
1. Memory used by the Visu+ runtime environment
2. Memory used by the AX OPC server
3. Overall memory consumption of the Visu+ runtime
environment and the project
4. Free device memory, available to all processes

OPC server

If a process tries to access more memory than is

available, the HMI device freezes and only starts
up again if the power supply is interrupted.

4
Figure 7

6
5
Memory management in WinCE 5.0

Recommendation: if using an HMI device with

WinCE 5.0, upgrade to WinCE 6.0 if possible.

8212B001

Checking memory resources

Key:
1. Memory used by the Visu+ runtime environment
2. 32 MB process limit of WinCE 5.0
3. Memory used by the AX OPC server
4. Free process memory available to the project
5. Overall memory consumption of the Visu+ runtime
environment and the project
6. Free device memory
Make sure that the process limit of 32 MB is not exceeded
as the HMI device will freeze if the process limit is exceeded
and can only start up again if the power supply is
interrupted.
Memory management has been revised in WinCE 6.0. The
process limit has been increased to 2 GB. A simplified
illustration of memory management in Windows CE 6.0 is
shown in Figure 8.

Make sure that your visualization project does not exceed

the available memory resources during runtime. This is the
only way to ensure stable operation.
Visu+ offers several options for controlling the memory that
is actually used during runtime. In order to keep memory
resources in check, you can see how much memory is
already allocated and how much is still available directly in
the status bar.
Proceed as follows to display the status bar:

Right-click to open the context menu for your Visu+

project.

Select the Properties menu item.

Under Execution, activate the Show Status Bar

checkbox.

Visu+ RT

OPC server

Figure 9

3
Figure 8

8212_en_01

4
Memory management in WinCE 6.0

Activating the status bar in Visu+

8212B002

PHOENIX CONTACT

VISU+ BEST PRACTICE

Copy your visualization project to the HMI device.

After restarting the project, the status bar will be displayed

during runtime.

8.1

Recommended maximum number of objects

For HMI devices, the recommended total number of objects

that can be used in a screen is limited as follows:
HMI device

Figure 10

Status bar of a Visu+ project

The first value indicates the amount of memory already

allocated. The value in brackets indicates how much
memory is still available.
The minimum storage allocation of a Visu+ process (here:
blank visualization project without screens) on a touch panel
with X86 processor is shown in the following table:
Program
Visu+ runtime environment
WinWrap Basic
ADOCE
Total

Allocated memory
7 MB
2.5 MB
2.3 MB
11.8 MB

TP xxx / OT xx
TP 3xxx

Recommended maximum
number of objects
64
128

The maximum number of objects is specified in the Project

name.constraints file. The constraints file is located in your
project directory.
Should you require more than the maximum number of
objects, you must change the value for the maximum
number of objects in the constraints file.
Visu+ automatically calculates the number of objects in a
screen and displays this information in the Project Explorer
(see Figure 11).

As the above table shows, a Visu+ process operating under

WinCE requires a minimum of approximately 12 MB of
memory. Further storage allocation depends on the size of
your visualization project, whether IMDB is used, and other
factors (e.g., the use of global scripts, see Section 10.2 on
page 16).
If the available memory capacity of the Visu+ process falls
below 5 MB during runtime, an error message is output
(Low Memory Condition) and all screens, embedded
screens, and scripts are emptied from the memory. This
also applies to screens for which the Keep always in
memory option is activated. For information on the Keep
always in memory option, refer to Keeping screens in the
memory on page 11.
If the Low Memory Condition error message is
output, stable operation is no longer ensured.

Screen properties

The screen design has a considerable influence on the

memory resources that are required and therefore the
operability of the overall visualization project.
When a screen is opened, it is loaded in the memory
together with all its objects and remains there until it is
closed. Depending on the size and the objects used, this
can lead to high memory usage particularly in the case of
HMI devices.

8212_en_01

Figure 11

Project Explorer screen objects

The result is divided into two separate numbers. The value

not in brackets shows the number of object groups, the
value in brackets shows the total number of objects used
(even if they belong to a group or are part of a symbol). For
an object group, the group itself and the number of objects
it contains are also added.
Example: for an object group consisting of two objects, the
values 1(3) are displayed in the Project Explorer.

PHOENIX CONTACT

VISU+ BEST PRACTICE

Only the number of object groups is counted in the

constraints file. This may mean that despite observing
specifications, the visualization project performance is
insufficient. You should therefore separately check the
number of objects used during the development phase of
the visualization project.
Example: objects and symbols in Visu+
The development environment of Visu+ features a toolbox
and a symbol library with preconfigured collections of
complex graphical elements such as buttons, machines,
animated valves, buildings, etc.

Figure 13

Symbol library object with grouping ungrouped

The number of screen objects in Figure 13 is displayed in

the Project Explorer.

Figure 14

Figure 12

Screen with objects from the symbol library

A symbol from a symbol library consists of many individual

objects which have been grouped to form an object group.
An object group can consist of very many individual objects,
thereby greatly influencing performance. Figure 13 shows a
symbol (i.e., an object group) where the grouping has been
ungrouped. The individual objects of the object group can
therefore be seen.

8212_en_01

Number of screen objects in the Project

Explorer

If possible, do not use complex symbols for a

visualization project on an embedded HMI
device. Symbols can adversely affect
performance.
Optimizing screens with a large number of objects
Complex processes can often only be represented in a
visualization project by a large number of objects. In order to
achieve a good level of performance for the HMI device in
these visualization projects, it is wise to subdivide the
screen objects into animated and static objects and to insert
the static objects in the screen as background images with
file format .bmp.

PHOENIX CONTACT

10

VISU+ BEST PRACTICE

Proceed as follows to insert the static objects of a screen as

a background image in the screen:
Right-click to open the context menu for the screen.
Select the Properties menu item.
Under Style, Advanced, activate the Static Object in
Background checkbox.

Figure 15

Activating the Static Object in Background

checkbox

Visu+ searches the screen for static objects. The

background image is created and inserted in the screen
when the visualization project is transferred to the HMI
device.
This function is only available for HMI devices
with WinCE.
The Static Object in Background checkbox is
deactivated by default.
Only activate the checkbox for screens where the
number of objects is greater than the number of
objects defined in the constraints file.
8.2

Memory management for screens

In Visu+, screens can either be preloaded when the

visualization project is started or permanently stored in the
memory. If both of these options are used with care for your
visualization project, you can reduce project loading times
significantly.
The settings that are required greatly depend on the project
and your own requirements. General recommendations
therefore cannot be made. The following steps should help
you understand the possible functions and their effects, and
help you find the optimum settings for each of your
visualization projects,

8212_en_01

Keeping screens in the memory

If the Keep always in memory checkbox is activated for a
screen, the screen will be kept in the process memory after
it has been loaded for the first time. This means that when
the screen is later called, it does not have to be reloaded,
i.e., it can be called very quickly.
Proceed as follows to use this function:

Right-click to open the context menu for the screen.

Select the Properties menu item.

Under Style, activate the Keep always in memory

checkbox.

Figure 16

Keep always in memory checkbox

The screen is kept in the process memory the next time the
visualization project is started.
Recommendation: optimize the screen as
described in Optimizing screens with a large
number of objects on page 10 before activating
the Keep always in memory option.
When the Keep always in memory option is
activated, active screen elements (e.g., trend
windows) and programs (e.g., global scripts) are
executed, even if the screen is not visible. This
can lead to insufficient memory capacity (low
memory condition).
Recommendation: only use the Keep always in
memory function for screens without active
screen objects and/or programs.
Preloading screens
Even when the Keep always in memory option is activated,
it will take some time for a screen to load when it is called for
the first time as the screen has to be loaded in the memory.
You can avoid this delay when calling the screen for the first
time by preloading the screen when Visu+ is started.
Proceed as follows to use this function:

Right-click to open the context menu for the screen.

Select the Properties menu item.

PHOENIX CONTACT

11

VISU+ BEST PRACTICE

Under Execution, activate the Pre-Load Screens

checkbox.

Figure 18

Close Screen Delay - setting the delay time

If a screen is closed and opened again within the set delay

time, the screen is called just as quickly as it would be if the
Keep always in memory checkbox were activated for the
screen.
A delay time of 5 seconds is set by default.
Figure 17

Activating the Pre-Load Screens checkbox

When the Pre-Load Screens checkbox is

activated, Visu+ takes more time to fully initialize.
Close screen delay
A good compromise between saving resources and loading
screens quickly is the Close Screen Delay function. With
this function a screen only remains in the memory for a
certain amount of time after it has been closed. The screen
is only removed from the memory once this delay time has
elapsed.
Proceed as follows to use this function:
Right-click to open the context menu for the screen.
Select the Properties menu item.
Under Style, Close Screen Delay, enter the desired
delay time in milliseconds.

8212_en_01

Note: if you set a value for the delay time that is

too high, under certain circumstances there will
be multiple screens in the memory at the same
time. This can lead to insufficient memory
capacity (low memory condition).
Note: if using screens with parameters, set the
delay time to 0 beforehand. The parameters can
only be loaded on screens that have been
completely removed from the memory.

PHOENIX CONTACT

12

VISU+ BEST PRACTICE

Managing OPC items

In large visualization projects with a large number of I/O

bytes, it is wise to use OPC items for the purposes of
optimization. As a result, the performance of the
visualization project can be improved significantly.
9.1

Optimizing an OPC group

To use or deactivate the set update rate for inactive OPC

groups, the InUse Variable Manager must be active.
Proceed as follows to activate the InUse Variable
Manager:

Right-click to open the context menu for the screen.

Select the Properties menu item.

Under InUse Variable Manager, activate the InUse

Manager checkbox.

In Visu+, an OPC group consists of several OPC items. The

status of an OPC group and the OPC items it contains is
updated within a specific time interval. Proceed as follows to
define this update rate:
Right-click to open the context menu for the screen.
Select the Properties menu item.
Under General, Update Rate, enter the desired
update rate in milliseconds.

Figure 20

Activating the InUse Variable Manager

By default in Visu+, all OPC items that you have

added are grouped to form an OPC group.
Figure 19

In addition to this update rate, you can also define an update

rate for inactive OPC groups. An OPC group is always
inactive if all variables that are linked to the OPC items of the
group are neither used in the screens loaded in the memory
nor recorded in data loggers, etc.
Proceed as follows to define the update rate for inactive
OPC groups:
Right-click to open the context menu for the screen.
Select the Properties menu item.
Under General, Update Rate Not In Use, enter the
desired update rate in milliseconds.
Alternatively, you can deactivate the update rate for inactive
OPC groups completely. To do this, proceed as follows:
Right-click to open the context menu for the screen.
Select the Properties menu item.
Under General, activate the Deactivate Not In Use
checkbox.

8212_en_01

Recommendation: group the OPC items

according to their use to form different OPC
groups, so that as few OPC items as possible are
active at the same time. This means that data
traffic can be reduced and performance improved
especially in visualization projects with a large
number of I/O bytes.

Setting the update rate for an OPC group

9.2

Dynamic assignment of OPC items to variables

In addition to the recommended option for adding an OPC

item via the Project Explorer, an OPC item can be
dynamically linked to a variable directly.
To do this, proceed as follows:

Right-click to open the context menu for the variable.

Select the Properties menu item.

Under Dynamic, click on the ... button.

In the Tag Browser that opens, select the desired

OPC item.

PHOENIX CONTACT

13

VISU+ BEST PRACTICE

In addition to OPC items, a driver can also be used directly

in this way without having to create a task.

Figure 22

9.3

Figure 21

Dynamic assignment

OPC items which are dynamically linked to a variable cannot

be configured further (update rate, etc.). In addition, things
are less clear since a dynamically linked OPC item is not
listed under the OPC client in the Project Explorer.

Activating the Read Dynamic Items at

Startup checkbox

Synchronizing OPC items

During the development phase of a visualization project,

many OPC items are added and deleted again both in Visu+
and on the OPC server. As of Visu+ Version 2.3x, it is
possible to synchronize the OPC items with the OPC server.
To do this, proceed as follows:

Right-click to open the context menu for the OPC client.

Select the Synchronize OPC Server menu item.

Another disadvantage of dynamic assignment is that the

assigned OPC item is only ever logged into the OPC server
when the corresponding variable used. If the variable is no
longer active, the assigned OPC item is logged out of the
OPC server. As a result OPC items are only updated while
they are actually in use. This means that there is an
additional delay when displaying the process data. When
the variables are called, the OPC item must first establish a
connection to the OPC server before it can be updated.
As of Visu+ Version 2.3x, it is possible for all dynamically
linked OPC items to be logged into the server on project
start so that their method of operation corresponds to a
standard OPC item.
To do this, under the properties for the selected OPC
server, activate the Read Dynamic Items at Startup
checkbox (see Figure 22).

Figure 23

Synchronizing OPC items with the OPC server

During synchronization, all OPC items which are no longer

present on the OPC server and the variables assigned to the
OPC items are deleted. This ensures that only OPC items
that are currently available are found in the visualization
project.

8212_en_01

PHOENIX CONTACT

14

VISU+ BEST PRACTICE

10

Scripts

For project requirements that cannot be covered with the

standard components of Visu+, a VBA (Visual Basic for
Application) script editor is available. This editor can be
used to write scripts for specific functions or complex data
operations. In Visu+, a distinction is made between global
and local scripts.
The use of scripts does not generally cause
problems with regard to system stability.
However, the incorrect use of scripts can lead to
insufficient memory capacity (low memory
condition).
10.1

Global scripts

Global scripts can be called from the overall visualization

project. Proceed as follows to add a global script:
Right-click to open the Basic Scripts context menu.
Select the Add a new Script menu item.

The script editor is opened.

Program the desired function in the script editor.

The Basic Interpreter is loaded when a global script is
called. It requires approximately 700 kbytes of memory.
Additional memory is required to execute the script. The
amount of memory required depends on the length of the
source code for the respective script. After executing the
script, the Basic Interpreter is removed from the memory.
Separate thread
The Basic Interpreter can only execute one script as
standard. If several scripts need to be executed
simultaneously, proceed as follows:

Right-click to open the context menu for the script.

Select the Properties menu item.

Under Mode, activate the Separate Thread

checkbox.

Repeat this procedure for all scripts that need to be

executed simultaneously.

Figure 25

Activating the Separate Thread checkbox

By activating the Separate Thread checkbox, the selected

script is loaded in a separate Basic Interpreter and can be
executed parallel to another script.

Figure 24

8212_en_01

Adding a new global script

Note: each executed script requires

approximately 700 kbytes of memory for the
Basic Interpreter, plus the memory required to
execute the respective script. If several scripts
are executed simultaneously, this can lead to
insufficient memory capacity (low memory
condition). In this case, deactivate the Separate
Thread checkbox for all global scripts.

PHOENIX CONTACT

15

VISU+ BEST PRACTICE

Priority

10.2
This section only applies to Windows PCs with
Win32.

Each global script can be assigned a priority so as to

influence the order in which the individual scripts are
executed. To do this, proceed as follows:
Right-click to open the context menu for the script.
Select the Properties menu item.
Under Execution, Priority, select the desired priority
for the script from the drop-down list.
Repeat this procedure for all scripts to which you wish
to assign a priority.

Figure 26

Local scripts

Local scripts are directly linked to a screen or an object

(e.g., a button) from where they are called and executed by
means of a user action (e.g., a change, a mouse click). It is
not possible to call a local script from any other point in the
visualization project.
To create a local script, e.g., for a button, proceed as
follows:

Open the screen where the relevant button is located.

Open the Script Explorer.

Click on the button for which you wish to create a script.

In the Script Explorer event list, select the event that will
call the script.

Program the desired function in the Script Explorer.

Assigning script priority

A high-priority script interrupts the execution of a lower

priority script provided it is not executed in a separate
thread. After the high-priority script is executed, the lower
priority script that was previously interrupted is executed
again.
Calculating memory requirements
The memory required to use global scripts is calculated
using the following formula:
Max. RAM = 700 kbytes + CL +

n x 700 kbytes + n x CL

Key:
700 kbytes
CL
n

8212_en_01

Memory required for Basic Interpreter

Memory depends on the length of the source
code
Number of separate threads

Figure 27

Creating a local script in the Script Explorer

Unlike global scripts, the Basic Interpreter is loaded

separately for each local script that is called. The Basic
Interpreter requires approximately 300 kbytes of memory.
Additional memory is required to execute the script. The
amount of memory required depends on the length of the
source code for the respective script. After executing the
script, the Basic Interpreter remains in the memory and is
available to execute another local script.

PHOENIX CONTACT

16

VISU+ BEST PRACTICE

In the case of screens for which the Keep always in

memory function is activated, the Basic Interpreter is
likewise loaded for each local script that is called. However,
after changing screens, the Basic Interpreter is not available
to execute another local script. In larger visualization
projects this can mean that there are many Basic
Interpreters in the memory at the same time, which can in
turn lead to insufficient memory capacity (low memory
condition).
Recommendation: deactivate the Keep always
in memory function for all screens in which local
scripts are used.

11.1

IMDB

When using the IMDB (In Memory Database), all values are
stored directly in the device memory. This is also the default
setting for all database connections if a WinCE template is
used. If a WinCE template is not used, this setting must be
activated manually. To do this, proceed as follows:

Right-click to open the context menu for the data logger

or recipe.

Select the Properties menu item.

Under Database options, IMDB Historical Manager,

activate the Use IMDB Manager checkbox.

In order to ensure the maximum possible

performance of the visualization project, it is wise
reduce the use of local scripts to a minimum. Use
global scripts instead.
Calculating memory requirements
The memory required to use local scripts is calculated using
the following formula:

+
=

11

Memory required for the screen with the most local

scripts
Memory required for the screens with local scripts left
in the memory
Total memory required to use local scripts

Databases

Various databases can be used in Visu+:

On Windows PCs (Win32), the IMDB (In Memory
Database) and ODBC (Open Database Connectivity)
can be used.
On embedded HMI devices with WinCE, ADOCE
(Microsoft Active X Data Objects for Windows CE) can
be used.

8212_en_01

Figure 28

Use IMDB Manager checkbox

A backup file of the memory is stored on the CompactFlash

card, the internal parameterization memory or the hard disk
of the device in a periodic, adjustable interval. An interval of
10 seconds is set by default. To adjust the interval, proceed
as follows:

Right-click to open the context menu for the data logger

or recipe.

Select the Properties menu item.

Under IMDB Historical Manager, Write on disk

every..., enter the desired time in seconds.

PHOENIX CONTACT

17

VISU+ BEST PRACTICE

Figure 29

Setting the backup interval

The backup file is stored in csv format and can be opened

using a standard editor. After a system restart, the backup
file is reloaded in the memory.
Calculating memory requirements
IMDB data records are stored in the memory. Sufficient
memory capacity must be available to process the
maximum number of data records. If the IMDB is allocated
more memory than is available, the device will enter an
unstable operating state. It is therefore wise to calculate the
anticipated memory requirements.
The backup files can be used as a basis for calculating the
anticipated memory requirements. The ratio of memory
required by a backup file in csv format is around 1:3
compared to the storage allocation of the data logger in the
main memory. A data logger that is allocated 1 MB in the
memory is approximately 350 kbytes in size once it is
exported to a csv file.
In addition, data loggers can also be saved in xml format
(see Figure 30).

Figure 30

Activating the Save as XML File checkbox

The ratio of memory required by the xml file is also around

1:3 compared to the storage allocation of the data logger in
the main memory. You should therefore allow for an xml file
that is five times the size of a csv file. Using the Save as
XML File function can result in a much higher storage
allocation.
The anticipated storage allocation can be calculated using
the following formula:
(Size of csv file + Size of xml file) x 3
11.2

ODBC

If a large volume of data needs to be stored which exceeds

the maximum memory capacity of an IMDB, Visu+ offers the
option of using an SQL-based database solution via an
ODBC link.
This function is used automatically if use of the IMDB format
is deactivated. To deactivate use of the IMDB format,
proceed as follows:

Right-click to open the context menu for the data logger

or recipe.

Select the Properties menu item.

Under Database options, IMDB Historical Manager,

deactivate the Use IMDB Manager checkbox.
Visu+ automatically creates a local Microsoft Access
database (mdb file) for the visualization project.
If you wish to use another type of database (e.g., MySQL) or
if you wish to establish a connection to a database in the
network (remote OPC server), you must set this up via the
ODBC DSN setting of the data logger.

8212_en_01

PHOENIX CONTACT

18

VISU+ BEST PRACTICE

HMI device/touch panel (WinCE)

On HMI devices, ADOCE format is used instead of ODBC
format. This means that (where possible) all ODBC
connections are converted into ADOCE connections. SQL
Server Mobile Version 3.0 (sdf file) format is used as
standard.
Memory requirements
The data is saved directly to the hard disk or CompactFlash
card of the hardware platform used via the ADOCE
interface.
The software for managing the databases on an HMI device
requires the following amount of memory:
Program
ADOCE and SSCE 3.0
SSCE Engine 3.0
Data logger

11.3

Allocated memory
Approximately 3 MB
Approximately 0.75 MB
Approximately 1 MB per
data logger

General recommendations regarding the use of

databases

Figure 31

Any messages regarding functions are displayed in the

debug window during runtime (see Figure 32).

Use IMDB databases if the volume of data to be stored

is < 4 MB.
Use SQL-based databases if the volume of data to be
stored is > 4 MB.
Figure 32

The advantage of an IMDB database over an SQL-based

database is the file format used for the backup file. IMDB
backup files can be saved in dat, csv or xml format. Files in
csv or xml format can be copied during runtime and opened
with a text editor.
In contrast, backup files for an SQL-based database cannot
be opened during runtime as the SQL database is
inaccessible during runtime. Once copied, the backup files
can only be opened using a special software tool.

12

Activating the Show Output Window

checkbox

Messages in the debug window

The messages that are displayed are also saved to the log
files for the visualization project. The log files are located in
the LOGS folder in your project directory.

Debugging

For visualization projects that are executed with errors,

Visu+ offers various options for error analysis.
It is wise to activate the debug window during the
development process. To do this, proceed as follows:
Right-click to open the context menu for your Visu+
project.
Select the Properties menu item.
Under Execution, activate the Show Output Window
checkbox.

8212_en_01

PHOENIX CONTACT GmbH & Co. KG 32823 Blomberg Germany

phoenixcontact.com

19