Sluggish HMI

[BJR 0]

This is on the same network that has one of my AENT adapters crashing sometimes. http://forums.mrplc....showtopic=22158 I think it could be related and also could be a clue to both problems in general. The HMI has started to randomly not update. By that I mean that you can push a momentary push button and have it not react to touch. I pushed one button (momentary PB with a bit address to PLC) 12 times this morning and it did not respond until the last time. I had to push one of the screen change navigation buttons 4 times to change the screen. I've already checked the calibration of the touch areas. It is accurate pointing when it works but sometimes does not respond. Also, sometimes a button will respond to touch but then when you release it, it will hang on to being pushed for several seconds before it updates that you released it. Here is my question. Is this normal in the attached pic? Why are there more than one occurence of the same address? 192.168.102.50 ( i understand that will show up more than once as the target)is the plc, .3 is the PV1000plus, .20 is the SQL server. 10.11.1.121 is the real connection to the corporate network. IT created a VLAN of 192.168.102.x to keep machine traffic from crossing over to the regular 10.x.x.x corporate servers. Edited 20 Dec 2011 by BJR

[BobLfoot 302]

Looks quite normal to me. HMI will make several connections to the PLC based on how data is grouped and requested.

[BJR 0]

Thank You. That was bothering me. I won't let that distract me now! Are there any diagnostics on those web pages that you know WILL help me? Very few of them have detailed information in the manuals. Not seeing anything obvious, I am in my gut still suspecting that the server is really busy because they are not archiving data. Someone is supposed to evaluate and archive that in January, so maybe this will all go away. IT has told me that without knowing exactly what traffic to target and study that in general they can't really evaluate the Ethernet network. Any easy way to sniff out the whole network effectively?

[dmargineau 6]

It is always a wise rule of thumb to pursue a segregated topology when designing/implementing a modern Ethernet based control system. It doesn't matter how skilled your IT department is and how professionally they go about their business, they will NEVER comprehend the REAL TIME RESPONSIVENESS concept which IS A MUST within any automation application. After quite a few "incidents" similar to the one described by you, we have decided to eliminate the chance of diminishing (or worse!) the effectiveness of our automation systems by installing of individual communication bridges each intended to be used for a single, definite purpose segment (subnet). There are bridges used ONLY for I/O and Drives traffic (maybe one HMI included), bridges used ONLY for HMI traffic, bridges used ONLY for SCADA data transfer and bridges used ONLY for LAN interfacing. I know this is quite a massive financial investment, however, chances of something happening with the implicit automation data transfer are reduced to a minimum (operator interfacing included). Since each bridge could be configured according to the "importance" of the data transfer it is intended to handle, the designer/user would be able to fully take advantage of the modern automation controllers capabilities, nearly eliminating the "third party collisions" occurences. Edited 21 Dec 2011 by dmargineau

[BJR 0]

I definately understand your point. This was not very well planned out. It started as a PLC, HMI and maybe 7 Point I/O cabinets (one "machine"). Hooked that up to a data collection server and they are using a gateway and VLAN to keep it out of our email, file traffic, etc. Then we added 3 more machines to the data collection with more point I/O, HMI. Wish I knew a lot about Ethernet to help IT manage it better. I'm sure we could have done a better job even without your suggestions on segregating. What is puzzling is the amount of time it appeared to not have issues. I think the company that wrote the SQL software may have the capability to analyze what is going on when they come in next month. Hopefully they will see it right away and it won't be too costly of a lesson to learn. Thanks for the feedback everyone.

[rdrast 3]

I have a very difficult time swallowing this, as the network here is relatively huge, all one network, with more than 50 PLC's, 150 HMI's, many process computers, printers, and even IP video systems. We have no networking issues at all. What we do have, is some smart planning, many inexpensive managed switches, higher end concentrator switches, but most importantly, we take serious pains to make sure all terminations are solidly done. Crimping an 8 pole plug on the end of an Ethernet wire is absolutely not acceptable. Using any termination point or cable less then a quality CAT5 is not acceptable. About 90% of our network is 100mbps copper, 5% 1000mbps copper, and 5% fiber, split between the 1000mbps backbones and 100mbps general circuits. Most of the Logix class processors are still at Firmware 16, so spew multicast messages like fools, but still we have no issues. Looking at even our heaviest loaded concentrator switches, I would be hard pressed to see a peak usage on any port of more than 25% of the port capacity.