Tips for using the Visu+ software Application note 8212_en_01 PHOENIX CONTACT 2013-10-21 1 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.
2 Table of contents 1 Description... 1 2 Table of contents... 2 3 Hardware requirements... 3 4 Software requirements... 3 5 Starting a project... 3 5.1 Design of the screens... 3 5.2 OPC communication... 3 5.3 Communication drivers... 4 5.4 License restrictions... 4 6 Refactoring Explorer... 5 6.1 Displaying the Refactoring Explorer... 5 6.2 Using the Refactoring Explorer... 6 7 Memory management... 7 8 Screen properties... 9 8.1 Recommended maximum number of objects... 9 8.2 Memory management for screens... 11 9 Managing OPC items...13 9.1 Optimizing an OPC group... 13 9.2 Dynamic assignment of OPC items to variables... 13 9.3 Synchronizing OPC items... 14 10 Scripts...15 10.1 Global scripts... 15 10.2 Local scripts... 16 11 Databases...17 11.1 IMDB... 17 11.2 ODBC... 18 11.3 General recommendations regarding the use of databases... 19 12 Debugging...19 8212_en_01 PHOENIX CONTACT 2
3 Hardware requirements OT xx TP xxx TP 3xxx 4 Software requirements Visu+ 2.xx AX OPC Server 2.40.xx or later 5 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 This list is only a suggestion, the requirements may vary depending on the project. 5.1 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. Graphical elements Various graphical elements are available in Visu+. The following table provides an overview. Function TP xxx Win32 1 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 3D buttons/gauges No Yes Trend Yes Yes Diagram No Yes DB Viewer Yes Yes Embedded screens Yes Yes 1 PC runtime environment Due to the limitations in WinCE, not all of the available functions and objects can be used on a HMI device. Recommended maximum number of objects on a screen Hardware platform Recommended maximum number of objects TP xxx / OT xx 64 TP 3xxx 128 Win32 (PC runtime) Unlimited 1 1 Depends on the performance of the PC system used 5.2 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 3
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. 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. 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 Communication driver TP 3xxxT/M PB PROFIBUS TP 3xxxT/M MPI S7-MPI TP 3xxxT/M CO CANopen TP 3xxxT/M SER 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: 8212_en_01 PHOENIX CONTACT 4
Hardware platform Max. number of I/O bytes TP xxx / OT xx 4096 TP 3xxx 4096 Win32 (PC runtime) Depends on the license 1 1 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. 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. Figure 1 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. 6 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 5
Figure 3 Refactoring Explorer The following buttons are available in the Refactoring Explorer: Open: Rebuild: Stop build: Display jumps to the faulty object in the screen Rebuilds the list 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 Opening the Refactoring Explorer 6.2 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. 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. 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. 8212_en_01 PHOENIX CONTACT 6
Figure 6 Object partially off screen Figure 4 Off-screen object 7 Memory management After selecting the screen and scanning it with the Refactoring Explorer, a corresponding error message is displayed in the Refactoring Explorer (see Figure 5). 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: 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. Embedded HMI device 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. 8212_en_01 PHOENIX CONTACT 7
1 2 3 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 Visu+ RT 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 5 6 8212B001 Figure 7 Memory management in WinCE 5.0 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. Recommendation: if using an HMI device with WinCE 5.0, upgrade to WinCE 6.0 if possible. Checking memory resources 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. Under Execution, activate the Show Status Bar checkbox. 1 2 Visu+ RT OPC server Figure 9 Activating the status bar in Visu+ 3 4 8212B002 Figure 8 Memory management in WinCE 6.0 8212_en_01 PHOENIX CONTACT 8
Copy your visualization project to the HMI device. After restarting the project, the status bar will be displayed during runtime. 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 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. 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 Recommended maximum number of objects TP xxx / OT xx 64 TP 3xxx 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). If the Low Memory Condition error message is output, stable operation is no longer ensured. 8 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. 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. 8212_en_01 PHOENIX CONTACT 9
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 Number of screen objects in the Project Explorer 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. 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. 8212_en_01 PHOENIX CONTACT 10
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. Under Style, Advanced, activate the Static Object in Background checkbox. 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. Under Style, activate the Keep always in memory checkbox. Figure 15 Activating the Static Object in Background checkbox Figure 16 Keep always in memory 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, 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. 8212_en_01 PHOENIX CONTACT 11
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. Under Style, Close Screen Delay, enter the desired delay time in milliseconds. 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. 8212_en_01 PHOENIX CONTACT 12
9 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 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. Under General, Update Rate, enter the desired update rate in milliseconds. 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. Under InUse Variable Manager, activate the InUse Manager checkbox. Figure 20 Activating the InUse Variable Manager Figure 19 Setting the update rate for an OPC group 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. 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. Under General, activate the Deactivate Not In Use checkbox. By default in Visu+, all OPC items that you have added are grouped to form an OPC group. 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. 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. Under Dynamic, click on the... button. In the Tag Browser that opens, select the desired OPC item. 8212_en_01 PHOENIX CONTACT 13
In addition to OPC items, a driver can also be used directly in this way without having to create a task. Figure 22 Activating the Read Dynamic Items at Startup checkbox 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. 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). 9.3 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. 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
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. 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 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. 8212_en_01 PHOENIX CONTACT 15
Priority 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. 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. 10.2 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. Figure 26 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 Memory required for Basic Interpreter CL Memory depends on the length of the source code n 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. 8212_en_01 PHOENIX CONTACT 16
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. 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: 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 Figure 28 Use IMDB Manager checkbox 11 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. 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. Under IMDB Historical Manager, Write on disk every..., enter the desired time in seconds. 8212_en_01 PHOENIX CONTACT 17
Figure 29 Setting the backup interval Figure 30 Activating the Save as XML File checkbox 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). 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. 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
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 Allocated memory Approximately 3 MB Approximately 0.75 MB Approximately 1 MB per data logger Figure 31 Activating the Show Output Window checkbox 11.3 General recommendations regarding the use of databases 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. 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. Any messages regarding functions are displayed in the debug window during runtime (see Figure 32). Figure 32 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. 12 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. Under Execution, activate the Show Output Window checkbox. 8212_en_01 PHOENIX CONTACT GmbH & Co. KG 32823 Blomberg Germany 19 phoenixcontact.com