Ethernet Problems

S

Thread Starter

Simon Walker

I am currently starting up a large project with approx 20 HMI's/PLC's. In particularly, WonderWare and SLC 5/05's and suffering some slow downs. We are using switches and unshielded CAT5 cable (as advised) and can not seem to find the route cause. Is it worth getting somesort of network analizer, if so which? Or is it best to contact a company to come in and test it for me? I have followed the guidelines as closely as possible but am now scratching my head as to which way to turn for help. Anybody out there with some advice would be greatly recieved.
TIA
 
B

Brian Milliken

Dear TGIF I have had quite a lot of experience with ethernet in an industrial enviornment. I do not think an Net Anlzr. will help much. Is your System a managed or unmanaged, have you looked at EMI. You can email me a [email protected] for further comunication.
 
You sure its network problems and not wonderware programming problems? wonderware - if programmed incorrectly can cause a seeming 'slow-down' of network comms simply due to bad coding by the scada developer. what i mean is, if you have tags being written to/from the plc's in too great (& unnecessary quantities) you'll get a flooding of your comm-ports. it may seem like a 'slow-down' but in actual fact its just processing too many tags being written/read from the plc's
 
W
There are some issues that you might not have considered:
- 5/05 PLCs are rather slow at ethernet communications.

- These PLCs have a configurable option to process all outstanding communications requests between scans, or only a limited number of requests, the latter being the default. Note that the former option can substantially impact determinism and scan rate (negatively).

- Since PCs are MUCH faster at ethernet comms, you should definitely have a primary data collector PC which gets the data from all of the PLCs and disseminates to the HMIs, rather than each HMI polling the PLCs from which they need data. The main idea here is to eliminate all redundant requests for data from each of the PLCs.

- use RSLinx for your communications gateway, as it is (or at least used to be) much more efficient in terms of optimization.

If you share some more details about your configuration, I (we) may be able to provide more assistance.

Wes
 
There are a couple of issues to look at, is your access name using dde and are you advise when active? Since you have so many machines if your tags are dde and/or remote tags you could be polling every plc from every pc.

If you want to view data from differnt databases on different pc you may want to look into suitelink. If your acceess names are set to advise when active the data will only be polled when the screen is active with that tag. It will appear the system is slow but reality it is not. Beware that if you make all access name active all the time you may end up with the same problem.

To solve this set a script with items you need to monitor, alarms, data collection etc, so they are always running and will be updated, and leave in "advise when active mode". Last use rslinx to view comm status it has some very powerfull tools. Use the active topics/items under dde/opc to see all your tags being polled. If there are any errors they will show up here, bad address and so on if you need any help email me [email protected]

Good luck
 
C

Cristian Gliga

Hello!
Try to use a PC wich runs an OPC server. The server would collect all the information from the PLCs and the Wanderware SCADA PC would act as an OPC client. This configuration will speed up the communication.

Hope that helped.
Cristian Gliga - Systems Integrator
 
We are using RSLinx but are not using a primary data collector. We will employ this but I fear it is not the end. Thanx. I was also not aware about the selectable Ethernet speed. I will also investigate but presume to be factory default, therefore the lesser of the two evils.
 
Thank you all for your responses.

One issue we have is that the CAT5 is run in PVC conduit, under floor (concrete), next to AC conduits of the same. How can I prove bad installation is to blame (if that is the problem?)

Next, we have 3 prog terminals on line at any time. Will this cause the prob, thus it is a temp prob only? (Not tested that scenario yet)

Does the icon on RS reflect comm speed?

How can I prove reliability of net connections?

Thank you all again
 
No one can pin-point where the problems are without a network analyzer check out: "www.industrialnetworking.com":http://www.industrialnetworking.com or "www.mynetalert.com":http://www.mynetalert.com/ Determine the problem areas first. The PLC or HMI's.

Some good suggestions have been made already. A data concentrating HMI (only one PC that access the PLCs in a certain area). Also add topics to the IOServer for fast(priority data only), med, and slow polling for each PLC and group your data from the PLCs. Keep alarming in the HMI not the PLC. Watch for when tags are active, used in windows, window types that overlay keep tags active, alarm or histoical logging, or used in scripts. Minimize these if possible.
 
> You sure its network problems and not wonderware programming problems? wonderware
> - if programmed incorrectly can cause a seeming 'slow-down' of network comms
> simply due to bad coding by the scada developer. what i mean is, if you have tags
> being written to/from the plc's in too great (& unnecessary quantities) you'll get
> a flooding of your comm-ports. it may seem like a 'slow-down' but in actual fact
> its just processing too many tags being written/read from the plc's

RSLogix grinds to a near halt when uploading/downloading. Monitoring software is
almost useless! (read on)
 
you may also want to try using a 10BaseT hub, rather than 10/100. I have done numerous projects with 5/05's and Wonderware, and have had problems using 10/100BaseT hubs.

It seems the packets from the PC(s) get backed up in the hub waiting for to reach the slow SLC-5/05, until the hub locks up. I have been using 10BaseT hubs recently and have had no more problems.

I've also heard using a switch instead of a hub will also work.

Also, check your 'tick interval' and try using Suitelink rather than NetDDE to speed up the comms. If you have more than one PC connected, have only one PC communicate with the PLC, and set up the others to get the tags from that PC.
 
K

Kenneth Brewer

You didn't mention if these devices are on their own network or share a network with p.c.s running office programs. Something Rockwell doesn't mention about their ethernet PLC's is a built in feature called "Throttleback". Look on Rockwell's web site for article #G17776. Throttleback is when a ethernet PLC receives more than 16 packets in a 10ms period which causes the PLC to drop ethernet communication for a period of time. Also, check the length of cable runs, keep runs from the switches to devices less than 100 meters. You might also use ping and tracert commands from dos to see what the response time is between nodes. Good luck.
 
P

Peter Whalley

Hi Simon,

Try sending a large number of pings across the network from one PC to another. Look at average and maximum time delay and number of lost packets. Just type ping at the command line prompt and you should get help info. Try say 1000 pings and see what you get. On a LAN you should get delays of a few ms and very few if any lost packets.

Regards

Peter Whalley
 
Excellent question. We can not get up with the controls guy (had not got chance yet!)to question his reason. One scenario is that if the shielded cable is connected wrong it is worse than the twisted pair un-shielded. That is the only reason we can draw. However, I am open to further views. It is the same question we are asking now. Please read reply to original post for more info.
 
Thank you all again for your help. We have since moved all CAT5 away where possible from mains. Used RSLinx and reconfigured to an IO server scenario. Things seem better. I also dropped on a protocol analyser (J1955A Agilent Advisor Software) trial edition "www.onenetworks.com/agilentadvisor/J1955A_product.asp":http://www.onenetworks.com/agilentadvisor/J1955A_product.asp . It told us we had virtual zero utilization, no collisions and was happy to see no jabers or runts! (whatever they are but they sound mean!!) That being the case, we think it is not traffic which leaves three causes,

1. WW software
2. EMI (but expect collisions)
3. component breakdown somewhere

We have thanx to "Woodhead Conectivity" a possie of Ether-Cowboys coming down with the six-shooters Weds to help us out. I think the lesson here is to use certified cables, strictly adhere to the guidelines and buy me some decent diagnostic tools.

The help you all have provided is greatly appreciated. I will let you know the outcome tomorrow.
 
K

Kenneth Brewer

Communication problems are hard to troubleshoot, it is hard to pinpoint the source of the problem. Is it the HMI software, PC's, PLC's or the network. You might look at the Rockwell Software site under support and look up article #G17776 which talks about broadcast storms which inhibit ethernet communications at the PLC. Also look at article #G18218 - Selecting a Subnet Mask for 5/05 CH1 and article #A17634 - Ethernet Connections. From reading these articles it sounds like the advise already given, a I/O tag server will fix your problems.
 
M

McConnell, David P

We experienced slow response on seven Wonderware Consoles operating with a single A-B PLC5 with an Ethernet sidecar and communicating thru ABTCP. We
initially thought it was an ethernet problem just as you seem to believe.

The problem turned out to be congestion at the PLC interface caused by each of the workstations attempting to converse with the PLC simultaneously. We solved the problem by setting up one of the workstations as an "ABTCP Server" and pointing all of the remaining workstations at that server. With the load (bandwidth contention) removed from the plc, performance increased dramatically.

We also set up a secondary server with automatic switchover if the primary went away. There are at least two tech notes in the Wonderware Knowledge base describing this procedure. If you email me off line I can give you further details on this setup.

David McConnell
Lead Controls Engineer
Rocketdyne Propulsion & Power
Stennis Space Center, MS
 
Top