Optimizing Intouch


Thread Starter

neo freeman

I am developing an InTouch HMI for a relatively large system. Since this entails a lot of tags and screens, I want to optimize the performance of InTouch. Does anyone know of Optimization Techniques for Intouch (i.e. window settins, scripts, graphics layout etc.)? I wonder if Wonderware has come up with one. It will surely be of great help to us programmers. Advices from seasoned programmers out there, your two cents worth or rules of thumb, will be very much appreciated.

Hi Neo! Some ways to optimize the performance of your InTouch program:

1. Minimize the use of bitmaps in your screen. Any additional bitmap in your program will have a great impact on your memory (even if you have a GB of it).

2. Although you can not resist the use of graphics (or they are really needed), try to minimize the number of your screens. Remember that all of your screens are temporarily stored in a certain buffer in your memory (to be easily accessed when needed). Have you noticed the first time you switched a screen but it takes 3 seconds to appear but the next time you accessed again and it pops-up immediately? That's the reason why.

3. In the WindowViewer Properties, check for 'Optimize performance for memory' box, 'Always load windows from disk' box (I think some or all of these are checked by default), try to minimize boxes with checks on the Windows Configuration. The more boxes you check, the more you use your memory.

4. Use a PC that is more than enough to hold all your requirements (speed, memory, configurability, etc.) You should also check for the CMOS parameter of the PC to get optimum result. Avoid buying a PC that you know giving headaches. Some PCs are not 100% compatible with the cards you plan to install. Be aware of that.

5. The bottom line here is how you optimize the use of your memory (and the speed). Try to analyze the system that you are about to develop. From time to time, you might find something that will make your system powerful.

I hope you will find something useful here. Regards.
There are no such thumb rules available, atleast not in my knowledge. I have developed Large no. of intouch applications i normally use followig rules.

1. Differentiate the tags as per the speed of updation is required. define different topic name in i/o server for polling tags at different interval.

2. keep minimum required windows open at run time.

3. Check Log data and Log event for those tag which are very important. If u think that this tag is not require for logging dont just add it to Log data, this may occupy ur pc memory. ypou can always add tag for logging when required in later stage.

4. in historical trend keep a limit for the span of trend. Normally 1 day span is more then sufficent. Initally keep the history for 15 days and u feel that more is required and ur system is working stable then increase the time gradually.

5. Keep the alarm buffer min. and display the window that contains the alarm grid only when required.

6. keep excution time of scripts as per requirement. i thing 1000 msec time is enough for most of the scripts. dont go for execution time less then 250 msec unless the script is very critical.

i think this will help u alot

if u need any furthur assistance please mail me at "[email protected]", mailto:[email protected]

Others have given some great advice for optimizing the InTouch HMI. I would only add that building a large InTouch HMI operator interface is no different than building a large operator interface in any other system - including a DCS.

. Start at the foundation of who will use the system and what will they do.
. functionally describe all of the screens, including distributed alarms, system diagnostic pages, trend pages, graphics needed, and HMI screen navigation that you plan to use. Describe Popup screens that you plan to use and what action makes the popup disappear and if the operator can move, hide, or minimize screens. (Note: Personally, I think popups are overused and minimization has no place in an operator console.)
. Now, you can use different topics for fast and slow data, avoid overuse of bitmaps, etc. to really create a great HMI.
I used InTouch to replace DCS consoles where we had hundreds of displays using bitmaps, a tag DB of 30,000+ tags running on 266Mhz, 128mRAM computers (we did use a separate tag server)and could have any display called up and refreshed in less than 3 seconds.

[email protected]

Anthony Kerstens

As much as possible, keep I/O access grouped so that Intouch can pull in large amounts on information in as few polls as possible. For example, keeping bits within a small block of registers, etc. Data that won't be needed as frequently could be polled on a slower topic.

Also, Intouch only polls tags that are active. Tags are defined as active when they are used on an open window, are in a running script, are being logged. So, more active tags might result in more polling, depending on the specific windows.

Asynchronous quick scripts run on a separate thread. Use them for long executing scripts as I/O updates would otherwise be frozen. For example, SQL scripts, recipe scripts, etc. If you have a script that is copied many time, maybe with small changes, make use of an quick function for the common elements and call it when needed.
Clever use of tag naming can help because you can use indirect addressing and quickfunctions to do the same task for many similar objects. Recipe
manager is also very useful and not just for standard recipe functions, we had to create a help page for route availability where the page showed which items were preventing a route from running - potentially this meant one screen per route with 800 routes, by using recipe manager we were able to use one screen and indirectly pass tag names, this also helped because any future changes just meant a text file edit and no screen mods.

Creating tags in Excel is also a good way to save time especially if you start the naming convention correctly.