Visu Performance Guide 8212 en 00

8/2/2019 Visu Performance Guide 8212 en 00

1/60

Application note

Tips for using the Visu+ software

AH EN VISU+ BEST PRACTICE

Revision: 00


2/60

2011-11-02

8212_en_00 PHOENIX CONTACT

Tips for using the Visu+ software

AH EN VISU+ BEST PRACTICE

00

Designation Version Order No.

Visu+ 2.xx or later See Ordering data

Application note

Designation:

Revision:

Order No.:

This user manual is valid for:


3/60

PHOENIX CONTACT

Please observe the following notes

User group of this manual

The use of products described in this manual is oriented exclusively to qualified electricians

or persons instructed by them, who are familiar with applicable standards and other regula-tions regarding electrical engineering and, in particular, the relevant safety concepts.

Explanation of symbols used and signal words

How to contact us

Internet Up-to-date information on Phoenix Contact products and our Terms and Conditions can be

found on the Internet at:

www.phoenixcontact.com

Make sure you always use the latest documentation.

It can be downloaded at:

www.phoenixcontact.net/catalog

Subsidiaries If there are any problems that cannot be solved using the documentation, please contact

your Phoenix Contact subsidiary.

Subsidiary contact information is available at www.phoenixcontact.com.

Published by PHOENIX CONTACT GmbH & Co. KG

Flachsmarktstrae 8

32825 Blomberg

GERMANY

Should you have any suggestions or recommendations for improvement of the contents and

layout of our manuals, please send your comments to:

[email protected]

This is the safety alert symbol. It is used to alert you to potential personal injury

hazards. Obey all safety measures that follow this symbol to avoid possible in-

jury or death.

There are three different categories of personal injury that are indicated with a

signal word.

DANGER This indicates a hazardous situation which, if not avoided, will re-

sult in death or serious injury.

WARNING This indicates a hazardous situation which, if not avoided, could

result in death or serious injury.CAUTION This indicates a hazardous situation which, if not avoided, could

result in minor or moderate injury.

This symbol together with the signal word NOTE and the accompanying text

alert the reader to a situation which may cause damage or malfunction to the

device, hardware/software, or surrounding property.

This symbol and the accompanying text provide the reader with additional in-

formation or refer to detailed sources of information.
http://www.phoenixcontact.com/http://www.phoenixcontact.com/http://www.phoenixcontact.net/cataloghttp://www.phoenixcontact.net/cataloghttp://www.phoenixcontact.com/http://www.phoenixcontact.com/http://www.phoenixcontact.net/cataloghttp://www.phoenixcontact.com/


4/60

Please observe the following notes

PHOENIX CONTACT

General terms and conditions of use for technical documentation

Phoenix Contact reserves the right to alter, correct, and/or improve the technical documen-

tation and the products described in the technical documentation at its own discretion and

without giving prior notice, insofar as this is reasonable for the user. The same applies to any

technical changes that serve the purpose of technical progress.

The receipt of technical documentation (in particular user documentation) does not consti-

tute any further duty on the part of Phoenix Contact to furnish information on modifications

to products and/or technical documentation. You are responsible to verify the suitability and

intended use of the products in your specific application, in particular with regard to observ-

ing the applicable standards and regulations. All information made available in the technical

data is supplied without any accompanying guarantee, whether expressly mentioned, im-

plied or tacitly assumed.

In general, the provisions of the current standard Terms and Conditions of Phoenix Contact

apply exclusively, in particular as concerns any warranty liability.

This manual, including all illustrations contained herein, is copyright protected. Any

changes to the contents or the publication of extracts of this document is prohibited.

Phoenix Contact reserves the right to register its own intellectual property rights for theproduct identifications of Phoenix Contact products that are used here. Registration of such

intellectual property rights by third parties is prohibited.

Other product identifications may be afforded legal protection, even where they may not be

indicated as such.


5/60

8212_en_00 PHOENIX CONTACT i

Table of contents

1 General information ................................................................................................................1-1

1.1 User group of this OT/TP design guide...............................................................1-1

1.2 Hardware requirements......................................................................................1-1

1.3 Software requirements .......................................................................................1-1

2 Purpose of this Visu+ OT/TP design guide ..............................................................................2-1

3 Starting a project .....................................................................................................................3-1

3.1 Design of the screens.........................................................................................3-1

3.1.1 Possible number of screen objects .....................................................3-1

3.1.2 Graphical elements .............................................................................3-1

3.2 Communication driver ........................................................................................3-2

3.2.1 Win32 Systems ...................................................................................3-2

3.2.2 WinCE (touch panels) .........................................................................3-3

3.3 I/O bytes.............................................................................................................3-3

4 Refactoring Explorer ...............................................................................................................4-1

4.1 Refactoring Explorer in the design mode............................................................4-1

4.2 Use of the Refactoring Explorer..........................................................................4-2

4.2.1 Example: Off-screen objects ...............................................................4-3

5 Memory management of embedded devices ..........................................................................5-1

5.1 WinCE ................................................................................................................5-1

5.2 Project resource control......................................................................................5-3

5.3 Heap Memory Manager WinCE..........................................................................5-5

6 Screen objects ........................................................................................................................6-1

6.1 Maximum number of objects ..............................................................................6-1

6.1.1 Example: Objects and symbols in Visu+ .............................................6-2

6.1.2 Optimizing the screen with a large number of objects .........................6-4

6.1.3 Example: Graphical elements as screen background .........................6-4

6.2 Off-screen objects ..............................................................................................6-9

7 Screen management ...............................................................................................................7-1

7.1 Keep screens in memory....................................................................................7-1

7.2 Preload screens .................................................................................................7-2

7.3 Close screen delay.............................................................................................7-3


6/60

Visu+

ii PHOENIX CONTACT 8212_en_00

8 Scripts .....................................................................................................................................8-1

8.1 Global scripts......................................................................................................8-1

8.1.1 Separate thread ..................................................................................8-1

8.1.2 Priority .................................................................................................8-2

8.2 Local script .........................................................................................................8-3

9 Data logging & recipe ..............................................................................................................9-1

9.1 IMDB ..................................................................................................................9-1

9.1.1 Calculation of the memory needed .....................................................9-3

9.1.2 Example: Calculation with the .dat or .xml file .....................................9-4

9.2 ODBC/ADOCE ...................................................................................................9-5

10 Debug ...................................................................................................................................10-1

11 Support .................................................................................................................................11-1


7/60

General information

8212_en_00 PHOENIX CONTACT 1-1

1 General information

Unless mentioned otherwise, all information in this manual refers to the operating devices

OT xx, TP xx, and TP 3xxx.

In order to ensure the safe use of the product described, we recommend that you read the

data sheets of the connected devices before.

1.1 User group of this OT/TP design guide

The use of products described in this manual is oriented exclusively to qualified application

programmers and software engineers, who are familiar with the safety concepts of

automation technology and applicable standards.

Phoenix Contact accepts no liability for erroneous handling or damage to products from

Phoenix Contact or third-party products resulting from disregard of information contained in

this manual.

1.2 Hardware requirements

OT xx

TP xx

TP 3xxx

1.3 Software requirements

Visu+ 2.xx

AX OPC Server 2.40.xx

For additional information on HMI and Visu+, please refer to the UM QS EN OT TP quick

start guide.


8/60

Visu+

1-2 PHOENIX CONTACT 8212_en_00


9/60

Purpose of this Visu+ OT/TP design guide


2 Purpose of this Visu+ OT/TP design guide

This design guide helps to find the best platform (Win32/WinCE) for a visualization project

and to optimize the performance of existing Visu+ applications, especially on HMI devices

with a Visu+ WinCE runtime (touch panels).

There are significant differences between a normal office PC system with Windows

XP/Vista/7 and embedded HMI devices with WinCE in terms of memory management and

general graphical capabilities. This guide should help to consider this during the design of

a Visu+ application.

With the Refactoring Explorer, Visu+ 2.xx offers a powerful tool for detecting potential

critical design errors in the engineering phase. This is also shown in this guide.

A complete overview of the differences and limitations of Visu+ 2 CE RT and

Visu+ 2 x86 RT can be found in the Visu+ 2.x data sheet (DB EN VISU+ 2 ...).


10/60

Visu+



11/60

Starting a project


3 Starting a project

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

decide which 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

Web Clients needed

Redundancy functions

Communication between Visu+ applications

3.1 Design of the screens

The design of the screens has a large influence on the required resources and also on the

graphical capabilities of the platform. It is very important for the hardware and runtime

definition.

3.1.1 Possible number of screen objects

3.1.2 Graphical elements

This list is only a suggestion, the requirements may vary depending on the project.

TP xx / OT xx: 64

TP 3xxx: 128

Win32 (PC Runtime) Not limited1

1 Depends on the general performance of the PC (server)

Table 3-1 Graphical elements

Function TP xx Win32 Runtime

Color Yes Yes

Linear filling Yes Yes

Polygonal filling No Yes

Rotation No Yes

Dynamic X, Y movement Yes Yes

Graphical objects Yes Yes

Symbol libraries Yes Yes


12/60

Visu+


3.2 Communication driver

Visu+ offers the possibility of using so-called communication drivers for data exchange with

the following bus systems:

CAN/CAN Open

IEC 60870-5-104 IEC 60870-5-101

MODBUS TCP

MODBUS RTU

INTERBUS

PROFIBUS

Ethernet IP

S7-MPI

Ethernet S7-300/400 TCP

The number of usable drivers and the terms of licensing vary between the Win32 and

WinCE (touch panel) runtime.

3.2.1 Win32 Systems

A Visu+ RT -D license is required to use communication drivers.

Some drivers (e.g., CAN/CAN Open, INTERBUS) require additional hardware. Additional

information can be found in the documentation of the drivers.

The system limitations are as follows:

Maximum of two communication drivers

Maximum of 128 stations on each driver

3D button/gauges No Yes

Trend Yes YesDiagram No Yes

DB Viewer Yes Yes

Embedded screens Yes Yes

Table 3-1 Graphical elements

Function TP xx Win32 Runtime

For more detailed technical information please refer to the Visu+ 2.x data sheet (DB EN

VISU+ 2 ...).

An insufficient hardware configuration can decrease the performance of the driver.

Runtime configurations with additional drivers (64 drivers, maximum) are available on

request.

Please contact your nearest Phoenix Contact representative.


13/60

Starting a project


3.2.2 WinCE (touch panels)

The license for the driver is already included in WinCE runtime.

With standard touch panels (TP xx / OT xx) only the Ethernet based drivers can be used:

IEC 60870-5-104

MODBUS TCP

Ethernet IP

Ethernet S7-300/400 TCP

A touch panel of the TP 3xxx series is necessary if you use other drivers.

It is possible to use two drivers on a touch panel at the same time (e.g., Modbus TCP and

PROFIBUS).

3.3 I/O bytes

Depending on the license or runtime version there are limitations in the maximum number

of allowed I/O bytes. These bytes are all transferred via OPC or drivers.

Check the number of I/O bytes

Visu+ includes a function to calculate the number of actually used I/O bytes. This permits

checking if the planned or already bought Visu+ RT license is still sufficient or if the projectcan be run on a touch panel.

To use this function, start your project first by clicking the "Start Project button. During

runtime all I/O bytes are acquired which have been declared and used in the project. Stop

your project and return to development mode. Open the "Edit...Check License needs

(License Requirements)... menu. The "License Requirements tab shows all acquired 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.

TP xx / OT xx: 4096 bytes

TP 3xxx: 4096 bytes

Win32 (PC runtime): Depending on the license1

1 Recommendation for the unlimited license is 100000 bytes

Display size

- 0575.7

- 0707.0

- 10510.5

- 12112.1

Additional interface

- PBPROFIBUS

- MPIMPI

- COCANopen

- SERRS232

TP 3xxx xx

Only active I/O bytes are relevant for the license and are calculated during runtime.


14/60

Visu+


Figure 3-1 Check the number of I/O bytes

Number of active I/O bytes

in runtime

All I/O bytes defined

in the project

We recommend creating a list of the required I/O variables (drivers & OPC) and to plan a

reserve of 20% at least for evaluation of the required license.


15/60

Refactoring Explorer


4 Refactoring Explorer

The Refactoring Explorer is a powerful tool for detecting and preventing potential critical

design errors in the engineering phase. These could be incorrect variable assignments, off-

screen objects, and problems in terms of communications.

4.1 Refactoring Explorer in the design mode

Normally, the Refactoring Explorer is active and visible directly after starting Visu+.

Figure 4-1 Refactoring Explorer user interface

If the Refactoring Explorer is not visible, it can be opened as follows:

Figure 4-2 Open Refactoring Explorer

We strongly recommend scanning all project elements when engineering is finished.


16/60

Visu+


4.2 Use of the Refactoring Explorer

Almost all parts of a Visu+ project can be analyzed with the Refactoring Explorer. After one

of these project elements is highlighted, the Refactoring Explorer scans the objects and

displays the results in the Refactoring Explorer window.

The Refactoring Explorer can be used for the following Visu+ components:

Screens

Alarms

Data loggers

Recipes

Event objects

Scheduler objects

Scaling objects

OPC Client

All results are shown with a short description and in case the error is part of a screen. Visu+

will jump to the object concerned after a double click.

A description of the Refactoring Explorer user interface is shown below.

Figure 4-3 Refactoring Explorer message window

Open: Jump to the incorrect screen object

Rebuild: Rebuild the list

Stop build: Abort of rebuild

Error notification

Analyzed Visu+ object or screen


17/60

Refactoring Explorer


4.2.1 Example: Off-screen objects

The following example shows a screen where an object is placed off screen.

Figure 4-4 Example: Off-screen object

When the screen is opened in Visu+, the Refactoring Explorer scans the screen and shows

the following result.

Figure 4-5 Typical error message

After a double click on the message the object is marked and the properties are loaded.

Off-screen object


18/60

Visu+



19/60

Memory management of embedded devices


5 Memory management of embedded devices

The engineering environment of Visu+ provides the option of creating platform-independent

(Win32, WinCE and also hardware platforms) projects. To get the best results in terms of

performance for embedded devices (TP xx / TP 3xxx) it is useful to adapt the project to the

device.

5.1 WinCE

All embedded HMIs from Phoenix Contact use a WinCE operating system with version 5.0

or 6.0.

One of the biggest differences between both versions is the memory management, whichcan handle only processes with a maximum of 32 Mbytes of RAM under WinCE 5.0. If a

process requires more RAM, the system will run in an out-of-memory condition and

Windows will stop the process. The memory management of a TP xx is shown in a simplified

figure below.

Figure 5-1 Memory management of TP xx WinCE 5.0

Key

1 Memory used by the Visu+ runtime

2 32 Mbyte process limit of WinCE 5.0

3 Memory used by the AX OPC Server

4 Free device memory (heap memory)

5 Overall memory consumption of Visu+ runtime and the project

6 Free process memory

TP xx / OT xx: WinCE 5.0

TP 3xxx: WinCE 6.0

1 2

3

456


20/60

Visu+


The programmer must ensure that the project does not exceed the 32 Mbyte limit, otherwise

the device may freeze. In order to realize bigger projects, the

Heap Memory Manager WinCE in Visu+ (see also Section 5.3,

"Heap Memory Manager WinCE") can be used.

WinCE 6.0 uses a complete different memory management and the process limit of32 Mbytes does not exist. This leads to the following memory management (e.g., for the TP

3xxx):

Figure 5-2 Memory management TP 3xxx WinCE 6.0

Key

1 Memory used by Visu+ runtime

2 Memory used by the AX OPC Server

3 Free memory of the device, access able for the single process

4 Overall memory consumption of Visu+ runtime and the project

Visu+ can access the complete available system memory. Therefore, use of the Visu+

Heap Memory Manager WinCE is no longer necessary.

1 2

43

If the project tries to allocate more memory than is available, a device with WinCE 6.0 can

freeze as well.


21/60



5.2 Project resource control

To guarantee stable operation on an embedded device it is necessary to ensure that the

project does not exceed the available resources. Visu+ offers several options of controlling

the currently used memory during runtime conditions. The easiest way to do this is toactivate the status bar of the project.

Select the name of your project and then select "Properties" in the context menu. Activate

the checkbox "Show Status Bar" under "Execution".

Figure 5-3 Activating the project status bar

Now copy the project to the HMI and after a restart of the project the status bar will be shown

during runtime.

Figure 5-4 Project status bar

The available process memory can be used by the project without any additional

modifications. However, it should never fall below 5 Mbytes to prevent a low memory

condition. It is useful to perform a complete function test of the project on the target device

with an active status bar to ensure that this limit will not be reached.

Available memory in the Visu+ process Free memory of the device


22/60

Visu+


Figure 5-5 Visu+ process on WinCE

If the available memory in the Visu+ process falls under 5 Mbytes, the runtime will operate

in a low memory condition and unload all screens (even when "keep in memory" is

activated), embedded screens and script interpreters.

Available memory in

the Visu+ process

5 Mbyte limit, if more memory is

used the device goes into a low

memory condition

Visu+ RT uses

approximately

12 Mbytes

A low memory condition is critical and a stable operation of the device is not guaranteed.

For devices with WinCE 6.0 only the free memory is relevant, because the available

memory in the Visu+ process is only a virtual value.


23/60



5.3 Heap Memory Manager WinCE

The Heap Memory Manager WinCE of Visu+ is a possibility of using memory outside the

Visu+ process in order to bypass the 32 Mbyte limit of a WinCE 5.0 device.

Figure 5-6 Heap Memory Manager WinCE on WinCE 5.0

Key

1 32 Mbyte limit of WinCE 5.0

2 Heap Memory Manager WinCE swaps project parts outside the process

3 Visu+ runtime

4 Project resources

To use the Heap Memory Manager WinCE it is necessary to define which project elements

should be transferred and how many resources have to be reserved in the heap memory.

Select the name of your project and then select "Properties" in the context menu. Activate

the checkbox "Enable Heap Values" under "Heap Memory Manager WinCE".

21

43


24/60

Visu+


Figure 5-7 Heap Memory Manager WinCE

The test runtime of Visu+ records the number and type of elements of each run. These

values can be used to find the best heap settings for the project.

Start your project by clicking the "Start Project" button. Test all functions of your project.

Stop your project and change to the Design Mode. Select the name of your project and then

select "Properties" in the context menu. Under "Heap Memory Manager WinCE" click on

..." in the "Set Values from the last Run" line.

Figure 5-8 Take values from the last test run


25/60



The values acquired in the project run will be displayed.

Figure 5-9 Settings of the Heap Memory Manager WinCE

Because the automatically calculated values are only as good as the previous test run it isuseful to add a reserve of 10 20% to this values. Modify the corresponding values

manually.

Once a project element is declared for the heap, Visu+ will transfer all elements. If the

defined number of objects is not sufficient, the runtime is quit with an error "not enough heap

memory".

Elements which are used for the heap

Enable/disable of the

Heap Memory Manager WinCE

Currently used heap memory

The settings of the Heap Memory Manager WinCE cannot be checked by Visu+, the

developer must ensure that these settings are correct.

We strongly recommend using the Heap Memory Manager WinCE only if all

improvements described here are not sufficient.


26/60

Visu+



27/60

Screen objects


6 Screen objects

The performance of a Visu+ application in terms of loading and response time depends

strongly on the total number and type of used objects and of the general workload of the

device.

6.1 Maximum number of objects

The total amount of objects which could be used on a screen is limited on the embedded

devices as follows:

Visu+ automatically counts the number of objects on a screen and displays this information

in the Project Explorer as shown in the following figure:

Figure 6-1 Project Explorer screen objects

The result is divided in two separate numbers. The value without parentheses shows the

number of object groups, the value in parentheses shows the total number of all objects

used (even if they are grouped or part of a symbol).

Only the total number of objects is relevant for evaluation of the loading time and memory

use of a screen.

WinCE does not support all graphical objects of Visu+ (see also Section 3.1.2, "Graphical

elements" or the Visu+ 2.x data sheet (DB EN VISU+ 2...)).

TP xx / OT xx: 64 objectsTP 3xxx: 128 objects

With regard to performance and application stability it is not recommended to use more

objects.


28/60

Visu+


6.1.1 Example: Objects and symbols in Visu+

The development environment of Visu+ offers a symbol library with a preconfigured

collection of complex graphical elements like machines, animated valves or buildings.

These symbols are basically groups of Visu+ objects.

The following example shows how objects and symbols are counted in Visu+.

Screen with objects from the toolbox:

Figure 6-2 Example screen for toolbox objects

Key

A Buttons

B LED

C EditBox

D Graphical elements (rectangle and ellipse)

The number of objects is as follows:

Figure 6-3 Typical number of toolbox objects on the screen

The values for the object group and the total number of individual objects are the same.

Please note that the use of symbols strongly increases the total number of objects on the

screen and the resources required on the device.


29/60

Screen objects


Screen with symbols and objects:

Figure 6-4 Examples of toolbox objects

Key

A Standard objects

B Symbols

A symbol is a group of many single objects and for that reason it increases strongly the total

number of objects on a screen and of course the resources required on the device.

Figure 6-5 Typical number of individual objects and groups of objects in the form of

symbols

Individual objects of the

No. of individual objects and symbols Total number of individual objects

(grouped and ungrouped)

symbol


30/60

Visu+


6.1.2 Optimizing the screen with a large number of objects

To realize projects with many symbols and/or animated graphical parts it is necessary to

reduce the number of screen objects in such a way that the project can be run on an

embedded device in an acceptable way.A good compromise to keep the graphical elements and good performance is achieved

when only animated and user objects (e.g., buttons, edit boxes, etc.) are left on the screen

and other objects are placed as background bitmaps onto the screen. A bitmap is easier to

handle and the system must no longer calculate every individual object.

6.1.3 Example: Graphical elements as screen background

This example shows a project of a pump station with many objects. The simulation on astandard x86 office PC runs fine but on a TP, the loading and response time is not

acceptable. The reason for this behavior is the different system architecture of an office PC

compared to an embedded device. Since most of the symbols are not animated or interact

with variables, it is possible to make a screenshot of the passive parts and implement them

as a background to the screen.

Original screen of the customer:

Figure 6-6 Typical graphical elements

Key

A Bargraph

B Edit box

C Animated symbols

It is not recommended to attach a large bitmap as a background to a normal screen

element (button, rectangle, etc.). These elements will always be kept in the system RAM

and can lead to a low memory condition.


31/60

Screen objects


Visu+ shows only 23 groups for this screen, but the total number of objects is 1083.

Figure 6-7 Typical graphical elements as object original - total number of objects

After the symbols are ungrouped, the 1083 individual objects are visible and every object

must be calculated in the runtime and loaded into the device memory.

Figure 6-8 Typical graphical elements original - individual objects

Create the background screen:

For the screenshot it is useful to disable the grid on the development environment first.

Figure 6-9 Disable screen grid


32/60

Visu+


If animated symbols are used, they should be separated to passive and animated parts as

follows:

Select the symbol and ungroup the symbol with the context menu:

Figure 6-10 Ungrouping a symbol

Separate the animated symbol parts:

Figure 6-11 Separating animated elements of a symbol

Animated symbols

Not animated symbol


33/60

Screen objects


Make a screenshot from the passive elements and save it as a bitmap with a maximum

of 256 colors (keyboard "print" and insert screenshot in an image editor tool such as

Microsoft Paint):

Figure 6-12 Editing a screenshot in Microsoft Paint

Insert the screenshot as a background to the screen:

Figure 6-13 Defining a screen background


34/60

Visu+


Place the animated symbols and objects on the screen:

Figure 6-14 Animated symbols and objects on the screen

Figure 6-15 Typical graphical elements modified - individual objects

After this modification, there are only 58 objects on the screen instead of 1083 objects. The

loading time of the touch panel is significantly shorter without any limitation of the graphical

design.

Animated

objects


35/60

Screen objects


6.2 Off-screen objects

Objects which are completely placed off-screen could lead to a poor performance of the

screen.

Even when the objects are not visible during runtime, the system has to calculate them when

the screen is loaded.

The reason for this is mainly poor programming or a change of the resolution. But you can

find this out easily with the Refactoring Explorer (see also Section 4.2.1, "Example: Off-

screen objects").

Also objects which are not completely placed (like in the drawing below) on the screen

should be avoided.

Figure 6-16 Off-screen objects

These objects are not detected by the Refactoring Explorer, but could also lead to the

described negative performance and must be also changed or deleted.

Object parts are off screen


36/60

Visu+



37/60

Screen management


7 Screen management

It is possible to preload screens during the startup and to keep complete screens in the RAM

even when they are not visible. Used carefully and in the right way this will decrease the

loading time of the screens in a significant way.

All of these settings strongly depend on the project and the user requirements, it is not

possible to give a general recommendation. The following descriptions should help to

understand the function and the influence of the options to help to find the correct settings

for each project.

7.1 Keep screens in memory

A screen which is marked as "keep always in memory" will be hold, permanently in the

system memory, after the first loading. If the screen is called afterwards, the system does

not have to load the screen again into RAM.

The option is located in the properties of the screen.

Figure 7-1 Keep screen always in memory

Excessive use of the following options can lead to a "low memory condition".

The loading time of a screen depends on the number of screen objects. We recommend

that you optimize the time (see also Section 6, "Screen objects") before you use the "keep

always in memory option.

Active screen elements (like Trending Windows) and logics (IL Logic, VBA Scripts) are

executed, even if the screen is not visible, if "keep always in memory" is activated. This

can lead to a low memory condition. We strongly recommend that you deactivate thisoption on screens with logics or trending and alarming windows.


38/60

Visu+


7.2 Preload screens

Even if screens are marked as "keep always in memory" the first call will take as long as

before, because Visu+ has to load the screen into the RAM.

To prevent this delay during the first call, it is possible to preload all screens which are

marked as "keep always in memory" during the startup of Visu+.

Figure 7-2 Preloading screens

This option will increase the overall booting time of the Visu+ project.

Only screens which are marked as "keep always in memory" are permanently loaded, all

other screens are unloaded after a certain time (default 5 s).


39/60

Screen management


7.3 Close screen delay

A good compromise between saving resources and fast loading of screens is the "Close

Screen Delay" option. This is the delay time Visu+ holds the screen even after closing in

memory. After this time the screen will be unloaded.

Figure 7-3 Closing screen delay

That means if the screen is changed and the delay time is not over, the loading time will be

as fast as with the "keep always in memory" option active.

A good use case, for example, is a project with a few main screens and a large number of

objects for an overview of a plant. From this screen the user can call many smaller

parameter and status screens. If the "Close Screen Delay" of the main page is set to, e.g.

one minute, the changes between the main screen and the parameter screens are much

faster and the complete performance of the project seems to be faster for the user.

The delay time should be realistic for the application. If the time is set for all screens to,e.g.

one hour this may also cause a low memory condition because the screens are not

unloaded fast enough.


40/60

Visu+



41/60

Scripts


8 Scripts

Visu+ includes a Basic Script Editor which can be used to fulfill project requirements which

cannot be solved by the Visu+ standard objects or to handle complex data operations.

The use of scripts is normally not critical for the stability of the system but can lead to a "low

memory condition" if used in the wrong way.

Scripts can be included globally for the project and locally to access screens and objects

directly. The differences in terms of function and system handling are described below.

8.1 Global scripts

Global scripts can be called from every part of the project where a command can be used.

They can be added under the Basic Scripts project element.

Figure 8-1 Global scripts in the project tree under "Basic Scripts"

The Basic Interpreter is loaded if a global script is called and it uses approximately

700 Kbytes of system RAM (plus the code length of the scripts). After the script is executed

the interpreter will be unloaded and the resources are given back to the system.

8.1.1 Separate thread

This option allows to run a script while another script is being executed.

Figure 8-2 Separate thread

Visu+ is optimized to handle the standard objects of the toolbox. Scripts can be used but

Visu+ is not designed as a basic runtime. Due to this fact we recommend that you reduce

the use of scripts to the absolute necessary minimum.

Global scripts


42/60

Visu+


If this option is activated the script is loaded with a separate Basic Interpreter and can be

executed parallel to another scripts. An additional basic interpreter requires an extra

700 Kbytes of memory for every "Separate Thread" script executed.

Calculation example:

Key

700 Kbytes = normal global Basic Interpreter

CL = CodeLength

n = Number of separate threads

8.1.2 Priority

If used on Win32 system it is also possible to assign a priority to every global script.

Figure 8-3 Script priority

A script with a higher priority can suspend a script with a lower priority when it is called. After

the high priority script is executed the suspended one will be executed again.

Visu+ WinCE runtime does not support this feature.

Max. RAM = 700 Kbytes + CL + n * 700 Kbytes + n * CL

Because of the higher memory consumption we recommend that you activate this option

only if necessary. If there is a low memory condition, this option should be deactivated for

all global scripts.

We recommend the "Below Normal" default value.


43/60

Scripts


8.2 Local script

It is possible to connect a script directly to a screen or to an object (e.g., button) which is

activated directly with a user action (e.g., a change, click). Such scripts are not accessible

from other project parts and are called "local scripts".

In the following example, local scripts are used to open modal windows with parameters.

Figure 8-4 Local script

Unlike global scripts the Basic Interpreter is loaded separately for every local script (approx.

300 Kbytes, plus the code length of the script) and is not unloaded after execution or a

screen change, but can be used for another local script on different screens.

For evaluation of the resources required for the Basic Interpreter, you only need to open the

screen with the most used local scripts.

Key

n = Number of local scripts on screen

This value can vary depending on the code length of the loaded scripts.

A special case is the use of local scripts on screens which are kept in memory. In this case

the Basic Interpreter is loaded as well after the local script is called, but cannot be used after

a screen change for another local script. The interpreter is fixed to a particular local script.

This has a big influence to the resources required and can be calculated as follows:

Key

n = Number of local scripts on the screen with the most usage

m1 = Local scripts kept in memory screen 1

m2 = Local scripts kept in memory screen 2

RAM = n * 300 KbytesUsage

( n * 300 Kbytes) +RAM =Usage ( m1 * 300 Kbytes) +( m2 * 300 Kbytes) ...


44/60

Visu+


We strongly recommend to deactivate the option "keep always in memory" when local

scripts are used.

To get a better readable and predictable project we also recommend to prefer global

scripts.


45/60

Data logging & recipe


9 Data logging & recipe

The data logging and recipe function can be used with the IMDB (In Memory Database),

ODBC (Open Database Connectivity) on x86 Windows or ADOCE (Microsoft Active X Data

Objects for Windows CE) for WinCE. The following section helps you to choose the best

concept for the project.

9.1 IMDB

By using the IMDB (In Memory Database) all values are stored directly into the RAM of the

device. In case a WinCE template is used this is the default setting for all database

connections, otherwise it has to be activated.

Figure 9-1 Setup IMDB manager

Key

A Activate the IMDB ManagerB Activate the use of shared tables

C Period of time a backup is taken and copied to the Compact Flash card, the internal pa-

rameterization memory or HDD

D Amount of new records a backup is taken and copied to the Compact Flash card, the

internal parameterization memory or HDD


46/60

Visu+


In a periodic and editable time a backup of the RAM is stored to the Compact Flash card,

the internal parameterization memory or the hard disk of the device. The file is stored in a

csvformat which can be opened with a standard editor. In case of a reboot this file is loaded

back into the RAM. If used in combination with a recipe it is possible, for example, to change

the recipe configurations easily by editing the csvfile.

The maximum available memory for the IMDB on a WinCE is 4 Mbytes and 64 Mbytes on a

x86 Windows. ODBC/ADOCE must be used if more data must be stored.

The backup file is stored on the flash of the device and can be accessed by using a browser

or ftp. To access the file it is necessary to close the Visu+ runtime.

Access the ftp area with a browser (such as Microsoft Internet Explorer, Mozilla Firefox)

and open the project directory.

Figure 9-2 Location of the project directory

Project directory

ftp address of the device


47/60



Open the "DLOGGERS" folder.

Figure 9-3 "DLOGGERS" folder in the ftp directory

Figure 9-4 Logfile (.dat format, backup of IMDB) in the "DLOGGERS" folder

9.1.1 Calculation of the memory needed

The IMDB uses the RAM to store the records. It is very important that enough RAM is

available to handle the maximum number of records. In case the IMDB allocates more

memory than available the device will run into an unstable condition. The following section

shows how the required memory can be calculated.


48/60

Visu+


9.1.2 Example: Calculation with the .dat or .xml file

An easy way to calculate the reserve of RAM needed for the IMDB is to use the backup file.

These files have a fixed ratio of the file size to the occupied RAM (.dat 1/34; .xml 1/8).

To do the calculation the IMDB must be activated in the project and transferred to thedevice.

If the data logger is set to record on time, the device should run at least as long as the max.

time set. Afterwards the .dat / .xml file can be downloaded from the device (see also

Figure 9-2 on page 9-2) and multiplied with the ratio of the file type.

The following example shows the calculation based on the standard backup file (*.dat) with

a size of 60 Kbytes

In this example the data logger will use a maximum of 2 Mbytes, the programmer must

ensure that the memory is available on the device (see also Section 5, "Memory

management of embedded devices").

Standard backup (*.dat) RAMUsage = A * 34 (A = size of .dat file)

XML backup (*.xml) RAMUsage = B * 8 (B = size of .xml file)

2 Mbytes = 60 Kbytes * 34


49/60



9.2 ODBC/ADOCE

By using ODBC (Microsoft service of x86 Windows) it is possible to handle larger databases

than supported by the IMDB in Visu+. This service is always used as long as the IMDB is

deactivated and Visu+ will create automatically a Microsoft Access file (.mdb) in the projectfolder. In case another database (like e.g. Microsoft SQL, My SQL) should be used it is

possible to create an ODBC DSN (Data Source Name) in the system administration settings

of Microsoft Windows. By referring the name of the DSN in the ODBC Manager properties,

Visu+ will use these settings for the specified database connection. Some databases

require a user and a password for the login, in this case the user has to be created with the

password given in the Visu+ User manager and the user must be defined as ODBC DSN

User in the ODBC Manager.

Figure 9-5 Activating ODBC

Key

A Deactivate the IMDB Manager

B Name and user of the ODBC DSN

In WinCE a service called ADOCE is used for database connections, ODBC is not

supported. Due to this fact all ODBC DSN used in the project are transferred during the

download to a touch panel in ADOCE. In Phoenix Contact HMIs all ADOCE links are

permanently connected to the implemented local Microsoft SQL CE Server.

The SQL Server is only loaded if needed and uses 3 Mbytes only for the service and an

additional 1 Mbyte for every connected ADOCE Link (e.g., data logger or recipe).

Key

3 Mbytes load for the MS SQL Server

1 Mbyte for every database connection

Because the database itself is stored on the flash or hard disk of the device the calculated

memory consumption does not depend on the size of the database.

3 Mbytes + y * 1 MbyteRAM =Usage


50/60

Visu+


The database is stored on the flash into a .sdffile, which can be opened with a .sdfeditor.

To access the file the Visu+ runtime must be shut down.




Open the "DLOGGERS" folder.

Figure 9-7 "DLOGGERS" folder in the ftp directory


Project directory


51/60



Figure 9-8 Log file (.sdfformat, SQL Compact Server) in the "DLOGGERS" folder

The file can be opened with the free tool Microsoft SQL Server Management Studio

Express.


52/60

Visu+



53/60

Debug


10 Debug

Visu+ runtime monitors the system functions while the project is executed and stores the

information in several log files. In case of unstable operation these files can be used for

debugging purposes. All log files can be opened with a standard editor and are located in

the LOGS folder of the project. To access the files it is necessary to close Visu+ runtime.




Project directory



54/60

Visu+


Open the "LOGS" folder.

Figure 10-2 "LOGS" folder in the ftp directory

Figure 10-3 Visu+ runtime log files


55/60

Debug


The most important log files are described below:

Most of the common errors can be located with the information of the named log files. The

other files contain very specific information and are normally not important.

System.log: General system information

User logging

Alarms DBMS (Database Management System) errors

System errors (e.g., low memory condition)

DBMS Log.log: Information and status of all database connections

OPC Client.log: Information and status of connection of Visu+ as OPC Client to the

AX OPC Server


56/60

Visu+



57/60

Support


11 Support

You can contact the Phoenix Contact Automation Support for further assistance or your

nearest Phoenix Contact representative.

To provide a quick solution please collect the following information first:

1. Error description

2. Version of the Visu+ editor

3. Device information

a) x86 Windows PC: Version of the Visu+ runtime

b) Embedded device: Device name and image version

(Setup menu ' Settings ' information)

4. Visu+ project

5. Dump of the flash memory of the device (copy of the Compact Flash card)

To do this, proceed as follows:

Stop the Visu+ RT

Access the ftp area of the device like shown in the debug section

Copy all files and folders


58/60

Visu+



59/60

8212_en_00 PHOENIX CONTACT A-1

A Technical appendix

A 1 Ordering data

A 2 Documentation

Products

Description Type Order No. Pcs. / Pkt.

VISU+ 2 is the development environment (engineering license) for VISU+ 2projects on Windows XP / VISTA systems or Windows 7 (32/64 bit) systems.

VISU+ 2 2988544 1

VISU+ 2 RT ... is the runtime environ-ment (runtime license) for VISU+ 2 onWindows XP / VISTA systems orWindows 7 (32/64-bit) systems withthe following limitation for I/O data:

128 bytes VISU+ 2 RT 128 2988586 1

256 bytes VISU+ 2 RT 256 2988609 1

512 bytes VISU+ 2 RT 512 2988612 1

1024 bytes VISU+ 2 RT 1024 2988641 1

2048 bytes VISU+ 2 RT 2048 2988528 1

4096 bytes VISU+ 2 RT 4096 2988531 1

8192 bytes VISU+ 2 RT 8192 2988557 1

Without limitation VISU+ 2 RT unlimited 2988654 1

VISU+ 2 RT-D ... i is the runtime envi-ronment (runtime license) for VISU+ 2on Windows XP / VISTA systems orWindows 7 (32/64-bit) systems withthe following limitation for I/O data;two direct driver connection are addi-tionally possible:

128 bytes VISU+ 2 RT-D 128 2988696 1

256 bytes VISU+ 2 RT-D 256 2988719 1

512 bytes VISU+ 2 RT-D 512 2988722 1

1024 bytes VISU+ 2 RT-D 1024 2988735 1

2048 bytes VISU+ 2 RT-D 2048 2988764 1

4096 bytes VISU+ 2 RT-D 4096 2988913 1

8192 bytes VISU+ 2 RT-D 8192 2988573 1

Without limitation VISU+ 2 RT-D unlimited 2988748 1

Description Type Order No. Pcs. / Pkt.

User manualProgrammable VBA driver interfaces (APIs) for VISU+ 2 ...

UM EN VISU+ VBA DRIVERINTERFACES

1

User manualCommunication drivers for VISU+ 2 ...

UM EN VISU+ COMMUNICATIONDRIVERS

1

User manualProgramming of VISU+ 2 ... under Windows for desktop systems

UM EN VISU+ PROG 1

Quick start guideVISU+ 2 ...

UM QS EN VISU+ TUTORIAL 1

User manualProgramming with VBA script language in VISU+ 2 ...

UM EN VISU+ VBA 1

User manual

Web Client technology in VISU+ 2 ...

UM EN VISU+ WEB CLIENT GUIDE 1

User manualProgramming of VISU+ 2 ... under Windows CE

UM EN VISU+ CE PROG 1

User manualConfiguring and operating the alarm dispatcher in VISU+ 2 ...

UM EN VISU+ ALARMDISPATCHER

1

Data sheetVisualization software for Windows systems Version 2.20 or later

DB EN VISU+ 2 ... 1

Quick start guideHMI Operator Panels

UM QS EN OT TP 1


60/60

Visu+

Visu Performance Guide 8212 en 00

Documents