ControlLogix Produced/Consumed Tags over Ethernet

M

Thread Starter

Mark L. Goldstein

We have an application that has about 10 PLC and about 30 operator stations. All are setup to communicate over one ethernet. Response time is very slow.

I have been told that when we put the Allen-Bradley ControlLogix Ethernet cards on the network, they create their own subnet and transfer a lot of extraneous data. The transfer speed is very slow. We are using switches (not hubs) like Allen-Bradley recommends but we are still having the problem.

Does anyone have an idea of what is happening and how to fix it?

Thanks,
 
You need to get a handle on how much data you are passing on the network 10 PLC's and 30 operator interface can put quite a bit of load on the PLC ethernet interface.

 
Easy!!!

Use Modicon PLC's and global data, and you will see the result. You may be able to re-use your operator stations.

HTH

Trajano
 
chances are that you tax the network (are the cards still 10 base?) esp if all 30 hmi's are polling the PLC's

I would suggest thinking about using HMI's or PLC's as data concentrators to reduce the 30 hmi's from polling the PLC's

You can setup an additional PLC to bring in all your values you wish to see in the 30 HMI's or use one HMI to collect from the 10 PLC's (and then let the 30 HMIs poll that one HMI).

 
To answer this question you need to look at other factors that could be affecting response times.

For instance, how much data are the operator stations (Panelview?) polling and at what frequency? With 30 stations possibly hitting each PLC that could be putting alot of overhead in communication (in addtion to the PLC's talking to each other).

Try to increase the polling rates on the terminals (and stagger them slightly so they are all polling at slightly different rates).

Also, what series Controllogix processor are you using (the L55 or L63) and what are the scan times? There is a considerable improvement with scan times and communication with the L63 (even though the specs from AB don't really say there is a difference). If you are using an older series and have scan times of over 500ms (and have operator terminals polling faster than that), you'll see a poor response time in communication.

 
G

George Strachan

I would startby separating the control network (PLC's) from the HMI Network (information highhway) his can be split further. Do comms between CPU's hog the bandwidth(phase comms messages). Pack data into one message rather than have numerous messages. Ensufre scan classesonly poll data of the same type (thia can make big difference)

Hope this helps.

George

 
K

Kelvin Proctor

Mark,

Your switches may not be any use to use in the current configuration. As best I understand it (having worked on the EtherNet/IP protocol, but not actually used an AB PLCs recently) the issue is likely to be related to IP multicasting.

When you establish an I/O connection over EtherNet/IP, IP multicasting is used to send packets from the producer to all the consumers (or publisher/subscribers if you prefer that terminology). This can cause problems for most switches on the market currently (and especially the cheap ones). As the switch does not have any understanding of IGMP (Internet Group Management Protocol) it does not know who belongs to which IP multicast groups. Thus it simply sends the packets to all ports. Suddenly quite expensive switches are no more effective than simple hubs.

The best solution is to use IGMP aware switches. These are relatively few and far between at the moment (are much more expensive than simple DLink or Netgear switches). I know the new Cisco industrial ethernet switches are IGMP aware. (Look at the Catalyst 2950 series on the Cisco web site) I also believe Hirschman also have similar products, as may some others.

Depending on the size and layout of you network even one of these as a interlink switch might significantly reduce the network traffic.

This may not be the real problem you face but I would recommend finding out about IP multicast packets and have a look at your network with a packet sniffer and see what sort of traffic you are seeing. This should provide you with some sort of clues.

Cheers,

Kelvin
----------------------------------------------------------------------------
-------------------------------------------------------
 
No, not an issue and does not create own subnets.

1. How do you have the C-Logix communicaitons set up and configured, IP address, subnet mask and default router?
2. How well are you data concentrated in your PLCs, gathering data from all over?
3. How often are you gathering data?

Need more info.

Dave
 
R

Ranjan Acharya

Try implementing virtual LANs with managed switches. Ten PLCs is quite a lot on one unmanaged network. Remember that PLCs are not IT systems and are not well suited to being on large networks with lots of background jabbering.

RA
 
H
This is one of those questions where everyone answering is right to some extent. To get better answers you will have to provide better data. To provide better data someone will have to do some homework. If you want some real help contact me via my web page:
http://www.plc-control.com.

This kind of problem can be solved (and should really never have become a problem) by data exchange mapping. What is required is a bit of organization. If the amount of data is limited I would set up a round robin data exchange, no sense having all operator stations beat on all the PLCs.

Hugo
 
L

Lynn at Alist

This "extraneous data" rumor is not true. The traffic on the network is there in the same manner as the fat on a person - you put it there by yourself either with a fork or your program structure.

The problem with ControlLogix and object-oriented programs is the 'easy way' to do things is the worst way measured in network load. It treats every data item as an object and potential message target. Thus while Modbus/TCP can move 125 words of data in 1 TCP message, the same design under ControlLogix *MIGHT* create 125 messages.

There are many solutions - most direct is to manually repack your data into 'Assemblies' or groups that can be moved in fewer messages. There are tools to help with this - talk to someone familir with Rockwell (like your local RA/AB App Engineer who most likely will be very keen to
see your network situation get better so you buy more equipment!).

I also think Wonderware and some OPC vendors now sell 'special' versions of their tools for ControlLogix. These take the fact that say one page has 40 data objects and then handles both ends (PLC included) of the pack/unpack to move the data for this page in 1 message instead of 40
messages.

- LynnL
 
A
Hugo,

Your problems stems from the nature of the Ethernet/IP. It sends UDP messages which are broadcast packets and these will get broadcast over ALL the switches to ALL devices unless stopped by a router.

We had a recent problem where an AB Flex I/O on Ethernet was causing MAJOR problems with a National Instruments PXI chassis causing its task to slow from 7s to 1.5 minutes.

There is no way to segregate UDP broadcasts using switches (that I know of). The method we've adopted at Archimedes is to segregate the two networks. We actually use ControlNet for other reasons but the HMI network uses separate ENET modules, fibers, switches and subnets. We do that for other reasons as we also share the HMI subnet with hi-speed acquisition systems.

I investigated this problem very early on in the detailed design of the PLC systems at Archmedes and discounted sharing the "Control" and HMI networks on the same subnet. I have a processor, CNB/D and an ENBT module in each 17 slot chassis.

I would suggest that you examine your network design and separate the two traffic systems. I doubt that this problem can be fixed by using switches as it would have to stop UDP broadcasts.

HTH...Andy Sibley
mailto:[email protected]
http://www.at-sd.com

 
Do a google on "IGMP snooping". This is a technique that switches can use to limit the broadcasting of UDP packets to only those nodes that require it. The Rockwell Ethernet/IP producer/consumer messaging supports IGMP.

Hugh
 
Top