Overloaded Ethernet IP network (?)

[TimWilborne]

What's your polling rate from the PCs and Panelview How many tags each My thought on plan B. Ethereal and figure out who's sending, who's listening, and who's falling asleep. Post packet captures along with the following secret code, "Calling Ken Roach, come in Ken Roach"

[RFurey]

200 Tags on the PC 300 Tags on the laptop (Though I have not been running the laptop RSView32 project lately because of the problems.) 150 Tags on each (3) Panelview. Where would I find the polling rate?

[TimWilborne]

It has been a while since I worked with RsView but it seems like you can set a polling rate for each tag then somewhere in the equivalant of Panelbuilders Application Settings you can set the master polling rate that tags can't exceed. Maybe near the communications configuration. Can't remember and don't have RsView

[RFurey]

Update: (In case anyone was following this thread) After a bunch of digging, I've been informed that my processor (1769-L35E) does not have enough TCP connections for the components I've added to the system. It is my understanding that the number of TCP connections is a function of the number and type of components that are accessing the processor, and not necessarily dependent of the amount of communication activity involved. According to the literature the L35E has 32 connections. According to Tech Connect, my component/connection breakdown is as follows; Panelview Plus 600 – up to 5 connections (may be less but it is not possible to limit how many) Panelview Plus 600 - up to 5 connections Panelview Plus 600 - up to 5 connections Ethernet Adapter for remote I/O (1734-AENT) with two output module 1734-OW4, three Analog module 1734-IE2V, three TC module 1734-IT2I. – 7 connections Ethernet Adapter for remote I/O (1734-AENT) with two output module 1734-OW4, three Analog module 1734-IE2V, three TC module 1734-IT2I. – 7 connections Ethernet Adapter for remote I/O (1734-AENT) with two output module 1734-OW4, three Analog module 1734-IE2V, three TC module 1734-IT2I. – 7 connections Desktop PC running an RSView32 project – 2 connections Laptop running an RSView32 and RSLogox5000 project – 3 connections Worst case (during troubleshooting) – 32 connections available, 41 connections required. Normal operating – 39 connections required. I think this is might be a good example of the word, screwed…. I am unaware of any painless fix to this problem. Post-ordeal observations a) After reviewing this thread I notice that the term connection was used a couple of times. Unfortunately I was not savvy enough to pick up on the significance of the term. b) My conversations with Tech Connect did not zero in on the number of connections until late in the game. c) The connection limitation of the L35E processor never came up during the initial planning stages with my local supplier, though it seems like a pretty apparent bottleneck now. d) I had to make repeated calls to Tech Connect to tally up an accurate (I hope) count of the connections I need for the remote IO, Panelview Plus, RSView32 and RSLogix5000. Apparently there was no one person with all the answers and I frequently got different answers to the same question. (I usually stop when I get the same answer from two different sources) I imagine that part of the usefulness of this forum is to learn from others mistakes. Here is my contribution. Edited December 11, 2006 by RFurey

[adamriffe]

Off subject... Where can I find this? We need DeviceNet help here. I believe all our problems are grounding, but a little help couldn't hurt.

[TimWilborne]

Well I thought that the Compactlogix could handle 64 connections but now that I read a little deeper I see it is 32. That is what I asked for the Task Monitor screen captures. Would have caught it earlier if I had RTFM (read the friendly manual ) instead of going off of the top of my head Thanks for getting back with us TW

[Ken Roach]

I am embarassed that I overlooked the CIP Connection count too. Option 1, then, is to go to a ControlLogix controller that can handle 64 connections per 1756-ENBT module and can handle 250 CIP connections total to the controller. Or find a way to simplify those PV+ connections. Since you have Ethernet PV+ terminals, they also have a serial port for DF1/DH485. Could you use 1761-NET-AIC modules to do DH485, or you could do a DF1-over-DeviceNet system with 1761-NET-DNI modules. Seems to me that you've already spent your time and money on designing for Ethernet, so the best course of action is to get a more powerful Logix engine to go behind the Ethernet network.

[BobLfoot]

Check out this Post And or this link to AB.

[BobLfoot]

The manual I just read showed 100 connections, but only 32 thru the built in port. Would the 1788-ENBT card attach to a 1769-L35E and give you a second ethernet port and an additional 32 connections. Yes the PLC would need two IP's in the subnet but you could use one for IP I/O and the other for Panelviews and RSView, RSlogix. How about it 5000 experts. Can it be done?

[Contr_Conn]

No 1788-ENBT if for flexlogix only. L35E Ethernet can't be expanded 1768-ENBT has 64 connections, but it will require 1768 compactlogix controller. Edited December 12, 2006 by Contr_Conn

[paulengr]

There's an easy way out of this mess. Move the Panelviews to point to one of the HMI stations instead of directly to the PLC. That frees up 15 connections. I also don't understand why the Remote I/O's are so aggressive about using up so many connections. If you switch them from producer/consumer to explicit I/O (block transfers), then you can control the amount of traffic very easily. Right off the top of my head, you won't need to poll thermocouples faster than once every second or more anyways (show me a thermocouple with a rise time over a fraction of a degree per second...). I usually don't poll analogs more than 5-10 times per second (5 ms is usually considered "high speed" for 4-20mA loops...although voltage loops can be much faster). These can all be scheduled to occur sequentially using explicit polling, dropping the 7 connection requirement per remote I/O down to 1 or 2 at the most. Doing either of these two things brings the total number of connections down to an easily manageable amount. I have had to do this sort of thing many times in RIO networks. On a PLC-5, there is a similar limit on the number of block transfers it can buffer and when you hit it (and you usually only hit it when there's some sort of I/O failure happening at the same time), it starts giving you all kinds of screwy I/O errors. Since running down a couple of these over times, once I start dealing with more than a half dozen of these things, I start looking at "process speeds" (the actual maximum expected rate of change of the PROCESS) and throttle back the I/O accordingly.

[RFurey]

According to a conversation with Tech Connect, you can't get to tags in a non-processor. If there is a trick that would allow me to browse tags in a RSView32 application (or better yet, another Panelview), I would be interested. I'm not too sure it would be a good idea from a system reliability standpoint to piggy-back a panelview behind another device or application but I'll consider crossing that bridge when/if the time comes. From what I've been told, an 1734-IT2I (thermocouple module) will always take one connection regardless of the traffic. If this info is not nessessarily true, I'd like to know. Thanks.

[RFurey]

I investigated this very thing, concerning my Flexlogix 1794-L34 system with a 1788-ENBT Ethernet card. According to RS, the 32 connection bottle-neck of the 1794-L34 is in the processor, not the card. Adding a second 1788-ENBT does not add another 32 connections.

[Contr_Conn]

I don't know who told you, but this is incorrect. FlexLogix controller has 100 connections and EACH ethernet module has 32. But this is a low power controller and it should not be used with application like this in any case. You should use controllogix. 1756-RM094

[rpraveenkum]

you can verify the used & loading on any rockwell ethernet devices by hit its IP address in IE many diagnostic pages also avaliable

[BobLfoot]

While on the topic of connection counts , etc. In 2005 I was working on a large redundant controlnet application. If I recall the numebrs correctly then manual stated that we could have 64 connections per CNB module. But the application guide advised never exceeding 48 connections per CNB and said that 32 was rally the practical limit. Later we did a system with ethernet HMI and had 128 HMI units on one L61 PLC. Wound up using 7 1756-ENET untis to load share the connections. Bottom line - Just cause the spec is 32 or 64 or 128 connections on a comm module, don't expect good or perhaps any operation if pushing that limit.

[RFurey]

Just to avoid any possible confusion, the FlexLogix controller is part of a second Ethernet system, not the one that has been (mostly) discussed in this topic. I did mention the Flexlogix system in a different topic that ended up getting merged with this topic when it was suspected that the seperate Ethernet problems I was experiencing were related. Coincidently, I think I found the reason for the Flexlogix Ethernet problem yesterday after determining that the Flexlogix system only uses 24 connections. (I will continue to dig into the total number of possible connections for the Flexlogix controller and see if I can get some sort of consensus as to the true number of connections.) Firmware Revision 2.3 Corrected Anomalies This revision of firmware corrects this anomaly. The 1788-ENBT module, when used with the 1794-L33 or 1794-L34 controller, was writing to the dual port interface at the same time as the controllers. This anomaly could cause the MS LED indicator on the 1788-ENBT module to go solid red and communication through the module to stop after approximately 30 days of continuous operation. That's some anomaly.

[Contr_Conn]

1788-ENBT can give you true 32 connections, but depending on RPI and other traffic you may hit other limitations first (packets/sec, CPU) Only some controlnet cards have connection limitations discussed above. About anomaly that fixed in 2.3: you will see controller working and ENBT faulted every 30 or so days. It still may happen with 2.3 as well. Take a look at crash display page (ENBT module webpage) - if anything on this page then contact techsupport.

[paulengr]

Hmm...I see some obvious solutions here. I'm guessing that the 7 connections is because you are doing implicit I/O (producer/consumer) vs. explicit I/O (block transfers). Even with old Remote I/O once you got past a certain point, you can blow the buffering on a PLC 5, especially if you have a faulty I/O module or cable very easily. Then you get all kinds of strange crashes until you find the culprit. Thermocouples and RTD's rarely change temperature by more than fractions of a degree per second. Analog I/O usually can't be pushed much beyond updates of perhaps several per second. So why not simply schedule those I/O requests explicitly? If you do so, won't it drop your connections down to just one or two since you won't have multiple queries active at a given time? Second idea...can your Panelviews talk to the HMI's instead? That would certainly free up resources.

[rpraveenkum]

1788-ENBT use 32 CIP connections & 64 TCP connections Cip connections used for I/O controls & TCP connections used for unsheduled connections such as messaging & HMIs you can check the usage by hit its IP address in Internet explore

[CMoody]

I have a network where I have a head-end plc, which is a CompactLogix 1769-L33ER and six Micrologix-1400s that handshake with 6 Panel View Plus 7s.  The Plcs are split up between two different electrical enclosures.  The first enclosure has the head-end CompactLogix and three of the micrologix-1400s that are connected to a Phoenix Contact 8-Port Managed Switch.  Three of the Panel View Plus operator interfaces are also connected to this same switch.  The Micrologix Plcs are in ports 2,3,4 and the panel views are directly across in 6,7,8.  The Compact logix is in port 5 and a Wonder Ware PC is connected to Port-1.  The WW PC is located about 40' away in a control room where there is also a small managed 10/100/1000 D-Link switch.  The second enclosure has the other three Micrologix-1400s in it that connect to the same number ports of the other Phoenix Contact Managed Switch.  These three Plcs handshake with the other three PanelView Plus-7s.  There is also a link to the control room from enclosure-2 to the WW PC in the control room.

These devices are being used to control six individual lanes of a reactive steel shooting range.  The head-end Plc doesn't do very much work except sit there and monitor the six Micrologix-1400s to see if there is a challenge from one lane to another.  None of the Micrologix-1400s are communicating with each other at this point until the Head-End receives a signal that maybe lane-6 wants to challenge lane-1, for instance, to a shoot off.  Then the head-end allows the two processors to open up communication messages between the two.  Then scenarios are shared and a shoot-off is done with the two lanes.  

Meanwhile, the Wonder Ware PC has nothing to do with any of this shoot-off or handshaking that is going on.  What the Wonder Ware PC is used for is building Scenarios and downloading those different scenarios to all of the Micrologix Plcs at one time or, one at a time.  The PC keeps results in a database and is mostly used to download and handshake with the six Micrologix-1400s.  He don't care at all about the panel views or the head-end Plc, all he cares about are the Micrologix.

To get to my problem now!!! 

Everything works great between the Micrologix-1400s, The Panel Views, and The Compact Logix.  When the Compact Logix processor is connected to the Ethernet network, it slows the network down so that the back and forth handshaking between the Micrologix-1400s and the Wonder Ware PC have problems.  Certain bits are not executed correctly or the status isn't updated fast enough.  If we unplug the Compact Logix Ethernet cable, everything goes back to normal with the Wonder Ware PC and the Micrologix-1400s handshaking.  As soon as we connect the Compact Logix again, the Ethernet is very slow and don't update correctly.

 

The Compact Logix has very little programming in it and It would be awesome of somehow the Head-End Compact Logix processor didn't even know that the Wonder Ware PC was there.  I can go online with the CompactLogix using a Web Browser an see a lot of "Time Wait" logs between the Compact Logix and the IP address for the Wonder Ware PC.  I have some message blocks in the Compact Logix that talks to all of the Micrologix processors but, I have them staged to update and there is very little programming in this processor.  

 

Can someone please point me in a direction of how to cure this network problem.  I would love for the Wonder Ware PC to "Only handshake with the Micrologix-1400s" and not any of the Panel Views or the Compact Logix.  Is there a way to set the switches up for the Head-End Compact Logix to not even see the Wonder Ware PC on the same network?

Sorry for the long Post!!!  Whew!!!

 

CMoody

[CMoody]

M230731-E-220 Ethernet Network.pdf

M230731-E-220A Ethernet Network Control Room.pdf

M230731-E-220B Ethernet Network Lanes 1-3.pdf

M230731-E-220C Ethernet Network Lanes 4-6.pdf

[panic mode]

51 minutes ago, CMoody said:

I would love for the Wonder Ware PC to "Only handshake with the Micrologix-1400s" and not any of the Panel Views or the Compact Logix.  Is there a way to set the switches up for the Head-End Compact Logix to not even see the Wonder Ware PC on the same network?

Any modern Ethernet switches will automatically only forward traffic to right ports. In fact this is an issue of one wants to listen to traffic between other nodes. And this is what managed switches are for. one can create own rules to forward traffic to specific port (for listening/monitoring) or block off unwanted traffic or force certain behavior such as forcing baud rate, enabling/disabling auto negotiation etc,

[BobLfoot]

May be a rabbit trail, but are you using non-repeating Prime Number Update Intervals on all your OI Topics?

Or did you set everything to the default 1000 ms update rate?