InTouch View 'freezes'


Thread Starter

Phil Irvine

We have three PC's :
PC1 communicates to 2 Siemens S5 PLC's via H1 I/O server (SuiteLink) and 2 Flow Computers via bespoke I/O server written with I/O server Toolkit (NETDDE)
PC2 communicates to 2 Siemens S5 PLC's via H1 I/O server (SuiteLink) and 1 Flow Computers via bespoke I/O server written with I/O server Toolkit (NETDDE)
PC3 communicates to 1 Siemens S5 PLC via H1 I/O server (SuiteLink) and 1 Flow Computer via bespoke I/O server written with I/O server Toolkit (NETDDE)

Each PC transfers data with the others using SuiteLink. Each PC can execute the functionality for all PLC/Flow Computer combinations.

Each PC retrieves data from a remote 'Host' machine running SQL server 2000 and runs an Active X control to validate data.

The system operates fine when first started but after approx. 2 days the machines have slowed significantly. The handshakes between the InTouch applications/PLC's give sporadic alarms(10second time-out) which gradually get worse.

Eventually a machine (or sometimes all three machines) completely lock-up requiring a re-boot to rectify the problem.

Has anyone any ideas? (or preferably a cure)??

Best Regards,

Phil Irvine
Control Systems Engineer.

Check your NT Eventviewer and the Wonderware Logger. Do you see any related error messages?

good luck

Anthony Kerstens

Have you checked for memory leaks?

The knowledge base has instructions on
using Performance Monitor to do this.

Anthony Kerstens P.Eng.

Vic Ellescas

I think we quite have the same problem, but we have GEGenius Bus/PCIM thru Wonderware Intouch 7.1 on which we just upgraded from Intouch 5.6b. The intouch is running 7.1 on Windows 2000 on eight PC's. We used the service pack 2 for Windows 2000 to correct the problem.
Vic Ellescas
Elect. Engr.
Thanks Anthony,

I'd taken some performance monitors but hadn't fully interrogated them until I received your response.

The InTouch View is using excessive amounts of memory.

I set up a test system In-house and navigated around the available mimics. The InTouch View process used more and more memory until the View locked-up. After some time Windows gave a 'low on virtual memory' error and the InTouch View gave an 'out of memory' message.

This is not normally seen on the operational system as it operates 24/7 and as soon as the fault is seen the machines are restarted.

Any ideas on how I can get InTouch View to release the memory or stop it from taking it in the first place?

Best Regards,


I had a similar problem with InTouch but I was using their SPCPro add on as well. We went through many renditions of service patches with them trying to determine the problem. In the beginning, we had a leak that would eventually lock the host up in about a week. In the end, before we stop using SPC, we were getting about 3-4 weeks before the host locked up. The problem went away once we stopped using SPCPro. This was about 1.5 years ago that I worked on this. I have not heard if there was a permanent fix. At the time, Wonderware knowledge they had a problem with the SPC software and therefore the reason for the memory leak. Hope this helps.


Finding memory leak conditions can be a bear. Diagnose from knows to unknowns.

Does a new InTouch app or something like Reactor Demo produce a memory leak?

If so, you may have an installation issue, either with InTouch or the OS. DLL conflicts are a common cause.

If not, it's likely something specific in your duty InTouch app. You mentioned an "ActiveX to validate" data from a W2K MSSQL machine. Does a
new app with just this ActiveX in it leak when the control is exercised? i.e., methods executed, properties assigned. Can you drop the ActiveX into a VB app and replicate the leak condition? If so, check resource utilization in the control.

Are you using SQL Access to access MSSQL data?
If so, make sure you release resources (result sets and statement) with a SQLEnd() and SQLClearStatement() functions. If memory resources are not released, it can create a memory leak condition, similar to the kink you

Hope this helps.

Bob Grinde