PLC Slow ethernet communication response

C

Thread Starter

Carlos Soriano

Need some help about this issue.

Our plant has an SCADA system using 6 Rockwell Control Logix 5000 PLC and Intouch Wonderware Software in an Ethernet network.

5 Plc's have a quick response when wonderware ask for visualization data (open screens) but one of them has a delay from 30 to 45 seconds to update data on screens.

We already change Ethernet cables and switches without any good results.

I used also a laptop with RSLogix 5000 to try to check PLC configuration and took same amount of time to answer.

Any ideas to resolve this slow response???
 
G

Gerald Beaudoin

Check all the parameters in the ENBT module. There is a diagnostic tab in the "Properties" that can give you some useful information. Also, perhaps try swapping the ENBT with one that is working OK. At least then you will have a better idea of where to look.

Good luck
Cheers

Gerald Beaudoin
 
Is this a new application or existing and problem just started to occur? It could be the setup in Wonderware depending on what version and configuration it may not be the PLC controller. You could compare the configuration in your device driver for each of the six controllers.
 
C

Carlos Soriano

To Gerald Beaudoin
We already check via browser ENBT Module diagnostic page and we could not find any issue. We will change this module by a new one as soon as we get it from supplier. Thanks for your response.

To Andrzej, I never use Wireshark for control network I will try to figure out how. Thanks Andrzej.

To Mark, I already check this item System Overhead Timeslice and I compared it with others PLC and it is the same in all of them, but I will try to put some higher number, I will inform results. Thanks Mark.

To Scott, our SCADA system has 8 years in operation and during last couple of years PLC time response has been increasing. We are made some minor ladder changes, one or two additional rungs; I think this could not be an issue? Thanks Scott.

We will try to fix this issue, in the meantime we will hear any suggestions, and once again thanks all of you for your ideas.

Regards.
Carlos Soriano
 
Hi Carlos, Did you fix the slow response issue?

we are just experiencing the same situation with L63 Controllogix 5000. the problem started this week. it was working properly for 5 years. we are also using wonderware intouch.

Thanks
 
D

Dinesh Chauhan

Always remember to click on "Auto negotiate" in settings of ethernet module. Sometimes it might be due to different speed settings on both ends. (like one on 10 and other on 100 MBPS)

Regards,
Dinesh Chauhan
IOC
 
I too am having this issue! Compactlogix 1769 l35e and wonderware intouch software. We replaced a 1769 l32e which had gotten so bad we couldn't upload the program off it. Loaded a previous save of the program to new PLC, it worked good for two months, now the issue is sneaking its way in again....
 
You should only use Auto-negotiate if you are connecting a PLC to a switch/VLAN if you are unaware of the existing settings. Processor to Wonderware communications is optimized when not using auto-negotiate because the switch and/or processor will not drop the comms during a timeout. Dropping comms could lead to the delay in that particular processors response and unless you are looking for it, like in the log files of SMC or TOP Server or whatever DAServer you are using, you won't notice it. Overhead time slice can make a significant improvement in that processor's response. Default is like 20%, but Wonderware recommends 40-50% for 5000.

Justin
 
J

James Ingraham

Justin,

I am severely confused by your answer, in particular this part: "...when not using auto-negotiate ... the switch and/or processor will not drop the comms during a timeout." Huh? What kind of comms and timeout are you talking about here? If there is an Ethernet-level error, there's essentially no difference between having auto-negotiate on or off. You'll get a "Link Down" either way. If it's above the Ethernet / data link layer, auto-negotiate has already happened and it doesn't know or care about an IP or TCP or HTTP timeout. I just don't understand what your statement means.

-James Ingraham
Sage Automation, Inc.
 
Top