Wonderware Communication Issue

O

Thread Starter

OK

we use Wonderware in Client Server architecture using kepware to poll filed data into WW server via DDE mostly which feeds WW Clients. I would like to mention that I did further testing.

First I ran the same application without scripts and, with the FullDB(12000 tags) loaded into the application, facing the same issue.

Then I isolated the Network switches of all the LAN domains but still to no avail.

As we are using Kepware as OPC server for fetching field, I turned off Wonderware Suitelink service and also shut down the runtime of Kepware then ran a minimal application with a few tags on two screens and the issue didn’t replicate.

Interestingly the issue also didn’t replicate on Wonderware client application i.e. it only happened where we had the OPC server fetching data into Wonderware (server) which further provides to client applications. System resource and network usage were also observed to be normal during this test.

We also ran the same test with MBENET as I/O server and faced the same issue of slowing/intermittent data.

Can you please elaborate upon any such limitation and provide us technical details of any workaround.
 
For communicating with modbus over Ethernet, the DASMBTCP service works quite well with Wonderware. I believe the MBENET ioserver is deprecated. The nice thing is that then you can use the Wonderware System Management Console for configuration, and to display debugging messages and look at what the system is thinking. In addition, you can then poke wonderware tech support to fix any reproducible bugs you find.

I handle a pretty large wonderware application (8,000 IO tags), and there's only a couple things I noticed: First, with Wonderware you need to limit the number of writes. It really confuses their back-end if you write multiple times to the same address. If you have scripts in your wonderware program that write a calculated value to the PLC every cycle, for example, you should use a condition script to write only when the values involved with the calculation change.

If you're using Kepware as an OPC Server, then you might want to consider using the FSGateway service to communicate with kepware, then let wonderware communicate with FSGateway. Then the FSGateway can take the brunt of communication with Wonderware nodes, and it can handle optimizing the requests to the kepware server. The nice thing is that you should be able to manage how often data gets pulled from the kepware server, which might help you reduce traffic. If kepware is trying to serve as fast as it can, and Wonderware is trying to pull data as fast as it can, I can see your systems being dragged down with useless polling.

The only time I really saw a massive drag down of the system was a time when I decided to try pulling a bunch of strings out of a modicon PLC. Having just 4-5 long strings being pulled at high frequency out of 20 HMIs was enough to completely bog down an otherwise very snappy system. If you're trying to do such a thing, then looking at a different way will definitely help.

If you're using managed switches, then you should look at using an SNMP monitoring tool to look at the traffic on individual ports to figure out where the traffic is coming from and going to. SolarWinds is fairly expensive, but works really nicely. PRTG Monitor is also a nice product, but it does cost money. There might be free and open source monitoring solutions out there, but I haven't really looked.
 
Top