Sign in to follow this  
Followers 0
AlThePal

ControlLogix and Ethernet/IP queries

12 posts in this topic

I've been asked to design a system to monitor and control wind turbine circuit breakers (x16) spread over approximately 8km. As there doesn't need to be any local intelligence (no comms, no control), I've opted for a 1756-L61 ControlLogix processor with a 1756-ENBT Ethernet adapter, connecting to Point I/O modules connected to 1734-AENT Ethernet adapters. The Ethernet network will consist of 17 switches connected in a ring with Multi mode fibre. Being new to ControlLogix and Ethernet/IP I have a number of questions for you learned folks out there: 1. Does Ethernet/IP need switches with IGMP when used in a ring configuration? 2. Does anyone have any experience using Point I/O in a similar setup? 3. We also have the option of using ControlNet, but I thought Ethernet was an easier (and cheaper!) option - any comments? 4. Anyone have any experience with Moxa managed Ethernet switches?

Share this post


Link to post
Share on other sites
Can't comment on most of your post due to lack of experience but this one I can. Is monitoring of hese breakers mission critical. Do you need to know in 1 sec or 30 seconds after trip? ControlNet is deterministic and you can be gauranteed that each node gets a turn to communicate. Ethernet is first come first serve. If you use ethernet be sure you isolate it from other data sources using it. I'd hate to have to wait to find out a breaker tripped while an O & M manual is being printed.

Share this post


Link to post
Share on other sites
The whole network is dedicated to this task. Anyway, it is only planned to use the system for closing the breakers - they are opened by the main control system or by protection. I'll be interested to see how reliable Ethernet/IP is - Rockwell are certainly pushing it hard at the moment.

Share this post


Link to post
Share on other sites
Again I don't get to work with "The Dark Side" of Network Topology that often but I seem to recall we used Intelligent Switches that supported an "A" fiber and a "B" fiber port on each switch. "A" fiber was one subnet and "B" fiber was another subnet. This let us use one switch for PLC and Office Data Traffic and yet not have either collide with the other. You app sounds perfect for Ethernet IP. I'd visit the literature library of Rockwell and get the Ethernet IP Design guide and use it religiously.

Share this post


Link to post
Share on other sites
I don't know how far you are going hop-to-hop but multimode has a limit of something like 800 meters. 1. IGMP keeps broadcast traffic down. Since you only have one receiver, it won't matter. Ring configuration means that the routers automatically keep one link down as a spare. At any given time, the network is actually a tree (or a bus in your case), but the extra link is held in reserve and fired up when the ring breaks. 2. Haven't used Point I/O at all. No comment. 3. Controlnet is a proprietary version of Arcnet. It locks you into one vendor. It is a bus-based system. I'm not really a fan of it overall. The "deterministic" claim is somewhat specious...full Duplex Ethernet is just as deterministic, especially if you use QoS. 4. No experience with Moxa managed switches. There are several other vendors with similar stuff. I have heard good things about Sixnet. I have several Hirschmann unmanaged switches with no troubles. I have had numerous issues with Cisco equipment not rebooting properly or with IT people getting wild ideas about reconfiguring things without telling anyone.

Share this post


Link to post
Share on other sites
I would beg to differ with this point. ODVA maintians ControlNet along with DeviceNet and Ethernet/IP as open protocols. If you use an 8 point ControlNet Digital Input from Rockwell and it goes belly up and the only 8 point Digital Io you can find is from Omron or Siemens. As long as it meets the ControlNet spec they'll interchange. Some loading of config files might be needed but that is all. Tag Names and other such things will remain the same.

Share this post


Link to post
Share on other sites
You can get more information about the ethernet from here http://www.ab.com/networks/site-index.html

Share this post


Link to post
Share on other sites
Thanks for all your input. To reply to some points raised by paulengr: Most multi mode products give their maximum distance as 2km. The Moxa switches state 4-5km depending on the fibre used. I've used Moxa equipment for a number of years and have always found it to be excellent, and substantially cheaper than European alternatives. As you point out, I only have one master, so as far as I can work out IGMP (which would keep broadcast traffic to one part of the network) won't have any great effect. You mentioned about full duplex Ethernet being deterministic - this point has always confused me. Switches work by connecting one Ethernet device directly to another. However, if you have a network where basically you have one master (generally with one Ethernet port) and many slaves, only one slave can talk to the master at one time. Ethernet/IP uses multicast to send the data to the consumer(s) without the consumers having to ask for it - quite different to the classic serial command/response model. This means that slaves could be trying to send to the master at the same time, and so continually colliding and backing off - if effect you have a situation that is no different to using hubs instead of switches (although you still need intelligent switches to cope with a ring configuration). Is this correct or does anyone know better?

Share this post


Link to post
Share on other sites
The input data from the I/O is multicast. Without IGMP snooping, these transmissions are passed to every port on a switch. Thus, every adapter on the switch sees every transmission from every other adapter and has to reject them. Depending on RPI, the adapters can get very busy rejecting messages.

Share this post


Link to post
Share on other sites
That's a good point Gerry - I didn't think of the effect of traffic on each of the Point I/O Ethernet adapters. I guess that if the switches had IGMP snooping, they would funnel all multicast traffic to the central PLC, leaving the Point I/O adapters unbothered. Then again, do the Point I/O adapters have to spend any processing power rejecting the data, or do they just ignore it, waiting for an opportunity to send their data? If another adapter is sending data to the central PLC, they will not be able to send anyway, as both the fibre backbone and the link between the PLC and its switch is occupied. Do you have any answer to the problem of multicast data from Point I/O colliding when trying to reach the central PLC? I can't see a way round this, but don't know if it a problem in the real world.

Share this post


Link to post
Share on other sites
Collisions are not the same as flow control. This is a misinterpretation of what is going on. Ethernet/IP is not going to fix this problem. Packets will not collide and back off. In an Ethernet with one segment, regardless of how the hardware is implemented, all nodes are effectively wired together on a single wire. If any one node broadcasts, the others all receive it simultaneously. If any two nodes broadcast, both packets are destroyed and nobody receives them. The backoff/retransmit stuff makes the delay not only longer but also random. In an Arcnet network (Controlnet is an implementation of Arcnet), one node on the network holds a "token". That is the only node that is allowed to broadcast. When the node releases the token, then the next node gets a turn. The token floats around the network, going from one node to the next according to their node numbers in order. Even if a node has nothing to do, the token must be passed on. This is as short as possible since nodes can "pass" the token simply by remaining silent. This collision vs. token passing thing is what makes Ethernet "nondeterministic". If I knew exactly how much traffic was on the network and when, I still could not sit down with a calculator and paper and tell you exactly how much delay and throughput a given packet will experience. That is not the case with half-duplex Ethernet. I can minimize this somewhat. If I put in switches operating at half duplex, then it means that each device is on a separate network segment. The only possibility of collision is if a device transmits at the same time that the switch attempts to transmit a packet to the device. However, the possibility of collision still exists. With a switch-based network however, we can do full duplex Ethernet. In this mode, the transmit and receive lines are separate. Since there are two separate paths, a device can send and receive one packet simultaneously. There is NEVER a possibility of a collision any more because each direction on the wire is a single network segment with a single device on it. At this point, if I know the throughput of every device and every segment, and I know the delay on each device including switches, I can calculate the exact response time for every packet...I'm back to an Arcnet world. What you are referring to is an entirely different problem. If the switch or the node or whatever is currently busy receiving another packet, the packet will go into a queue until there is time to handle it. There are various queue designs to handle arbitration from one queue to the next, but most systems use either some variation of RED (prominent on a lot of routers) or round-robin these days. If you exceed the bandwidth of any given part of the network on a temporary basis, the packets will be held in queues until the queues can be drained. If you do this continuously, eventually the packets will be destroyed because the queues overflow. This is not a collision. It's simply saturating the bandwidth and/or storage capacity of the network. It doesn't matter if you are using Ethernet, Arcnet, FDDI, or RS-485. The end result is the same no matter what network you use. Ethernet/IP is sort of like doing a file transfer in a lot of ways, but this is somewhat different from conventional control network protocols. When you do a file transfer, you initially send out a request for a file. Then the file server starts transmitting a stream of packets until the file is done. There is only one request, but the response could be several gigabytes in size. Most of the time, control networks only have one packet worth of data at a time. So there is one request packet, and one response. Ethernet/IP allows the requester to set up a single outstanding request where the response is received periodically and continuously, every time there's an update. The real bandwidth savings is in the fact that the responder also can respond ONLY when there's a change. So for instance temperature readings may not send another packet for several minutes. Thus, Ethernet/IP by itself has nothing to do with collisions or bandwidth limitations, but you can still run into either one if you exceed your network capacity.

Share this post


Link to post
Share on other sites
The adapters do have to process the messages to reject them and it can interfere with proper operation. There can't be a collision sending to the PLC as the switch will not attempt to transfer data from more than one port at a time.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0