I am going to China next week to investigate a complaint from a customer of ours about the "slowness" of the Wonderware InTouch 8.0 HMI that was installed for them a year ago.

Firstly, the specifications of the computers:
Win XP SP2 (Chinese version)
1 GB Ram
Hardware RAID card with two 40GB hard drives in Mirror (RAID 1).
Wonderware InTouch 8.0
- 134 screens
- Alarm Logger
- Custom ActiveX controls used to communicate to robotic controllers ProfiBus I/O
- Siemens S7 PLC using ProfiBus.
- Ethernet connections to robot controllers for File transfers (Job Files and backups)

The customer has continued to complain about the slowness of 5 of 9 HMI computers. These three are no different to any of the other computers, but these 5 are used most often. Other HMI computers in the plant have less IO communications, but also run the same version of the hardware (plant general spec) and InTouch software (just different screens).

List of things that I am going to check, and I would like to know from others for items that should be added to this list:
1. Memory performance (specifically Physical Memory Available/Commit Charge Peak).
2. Conditions of the Raid 1 system (faults, etc.).
3. Check items in the Windows Events Logs.
4. Check for any issues with limits on the Alarm Logs for InTouch.
5. Virus checks (computers are connected on plant wide network with CISCO switches, but separate to office network).
6. Hard Drive sector conditions (maybe using Spinrite (http://www.grc.com)).

Thoughts? Is there a known performance issue or “wall” that one can get to with screen objects that could impact HMI performance?

Thanks for any input.

Shawn Rimmell

 

Shawn,
Can't think of much beyond general troubleshooting. A few points:
1. Try the 4 computers that aren't used much on the common screens that the 5 access. If they're faster you can go through data caches, local Windows based computer maintenance, etc.

2. If possible check speed/lag times with many computers all on the same screen. Then check the case of only 1 or 2 connected terminals. Pay special attention to whether clients connect directly to PLCs or via the HMI server and how the system responds to heavier loading. You'll also want to pay attention to how much is going on with their process.

3. If there's any way to get a new, fast machine configured it would tell you a lot. If it's close to as slow as the others you have project design or network configuration/loading issues. If it's much faster you can look into cleaning up the 5 PCs as you listed below. Or, for what they're paying to fly you to China, it might be worth upgrading the PCs.

The rest is common sense - be observant. Good luck to you. I'm eager to hear how it goes.

----
Nathan Boeger
http://www.inductiveautomation.com
Total SCADA Freedom

 

Before anything else, I would check Windows Task Manager to see if the CPU usage was high or pegged at 100%. If so, I would sort the CPU column of the processes tab by clicking on it and determine which processes might be hogging CPU cycles.

Also, verify that something hasn't completely filled up your hard drives.

Is it still slow after a reboot?

Good luck!

 

Check for viruses, worms and spyware. When scanning for spyware, use several different spyware scanners as different ones detect different sets of spyware. Viruses, worms and spyware are supposedly very common in China and they spread very rapidly there, so it would not be surprising to find them on these computers.

I don't have any personal experience with viruses, worms or spyware (as I don't use MS-Windows on my own computing equipment), but I have heard of cases where there were literally hundreds of these programs running on a single computer and competing for CPU time, RAM, and bandwidth.

 

Defragment, keep history files on separate PC, try
Suitelink vs DDE communications.

 

Check log files and amount of data collected. I have had similar problems with WinCC and other Propriority systems. Sometimes the log files are so large that the system gets bogged down trying to write to them. Re-installing on a new PC works also but is painful. You can then re-format the original PC and go from there.

 

I worked on a project with Wonderware InTouch 8.0 and Siemens S7 PLC using A-B FLEX I/O. We had problems like yours. We went to the latest InTouch 9.5. We also upgraded the S7s firmware to the latest. There were some issues with the S7 time slice no allowing enough time for communications.

Some general suggestions:
InTouch Logging Deadbands – Make sure they are not too tight. I generally make them about 1% of full scale.

Event Logging – Only log what you really need.

Retentive Value on I/O Tags – InTouch has to write these values to disk every time they change. When View restarts the retentive values are over written on the first communications.

Communications Blocking – Organize the data into as few communication blocks as possible. Ideally it would be one block for values and one for status & alarms.

I hope this helps. Good Luck.

 

I Have worked with wonderware for an on-going project and some plant enhancements.

I'm not sure what I/O server you use with an S7 but increase its polling rate if possible

As mentioned above move historians to a seperate computer than Intouch installs

Also as mentioned above lower the amount of tags that log on event, and lower the number of tags that log, increase log deadband for logged tags

Check for bottlenecks in any communication node hardware if any

if all else fails replace wonderware HMI system with siemens, get them to convert your app to siemens simatic or whatever they have for S7, I know rockwell is offering to do that now.

 

In this system, do you use IAS? And if you do, what is the configuration? There is a free software to capture a traffic over the network that you can use to estimate it (think Snuffer or something).

 

You may want to check your video card. I have found on systems running 9.5 that if there is a lot of traffic on a system that it will start cashing memory seriously, bogging down the system. We finally moved to gaming video cards to solve this problem.