Sign in to follow this  
Followers 0
PLC_man_Stan

Ethernet IP or Control NET

Ethernet I/P or ControlNet   17 votes

  1. 1. Should Ethernet I/P or ControlNet be used for remote I/O

    • Ethernet I/P
      13
    • ControlNet
      4

Please sign in or register to vote in this poll.

9 posts in this topic

I'm just about to start a new project which will see us upgrade a PLC5 DH+ system into ControlLogix. We have a huge Ethernet Engineering network that most of our kit sits on. My Boss wants to use ControlNet for the remote I/O and i would like to conitune to use Etehrnet IP. He wants to use ControlNet becuase the original network did not seperate the engineering WAN from the machien LAN so when we had a bad input card it wiped out the whole of the engineering network. I have now addressed this issue by ensuring each machien has two ENBT cards on for the engineering WAN and then one for the remote I/O on the system. It works well. The trouble i have is that my boss has said the decision is mine so naturally i'm going to go with ethernet Anyone have any reasons for or against?

Share this post


Link to post
Share on other sites
If you are looking purely for opinions, then here I specify ControlNet only for all remote I/O and drives. I personally do not like using Ethernet for control of I/O or drives, but do use Ethernet for the HMIs on lines and to talk up to the SQL Servers. Ethernet is just too easy to corrupt, especially when the IT department gets involved (which they will). Maintaining two separate Ethernet networks for every machine is also a pain, and no matter what, eventually someone will come along and patch the two separate networks into one.

Share this post


Link to post
Share on other sites
Yeah opinions really i know both systems will do the job, i was looking more for a definate technical answer to back them up though. Your argument on the Ethernet for remote I/O is very valid though

Share this post


Link to post
Share on other sites
I used to think that Controlnet was the way to go, but I have been won over by Ethernet I/P. The savings in hardware, and the more available devices that can use it, outweigh the very valid risks outlined by rdrast for me.

Share this post


Link to post
Share on other sites
Arguments against Controlnet: 1. Controlnet is a pain in the rear if you ever have to troubleshoot it. Get your oscilloscope out and prepare to tear your hair out. 2. Controlnet is an "open" standard but only AB implements it. You can get Ethernet/IP compatible devices from almost anyone these days. 3. CAT 5E is much less expensive than coax cable. 4. CAT 5E is easier to terminate than coax. 5. Ethernet gives you much more flexibility in terms of network topologies and design and traffic management since the network is an "active" system. 6. You can set up, configure, and troubleshoot Ethernet without buying RS-Networx. 7. Controlnet is "once and done" as far as network setup goes. You can add/change Ethernet/IP devices online. 8. Controlnet is 1/20th of the speed of Ethernet assuming 100 Mbps Ethernet (higher speeds are possible). Arguments for Controlnet: 1. Redundancy "at the device" (with EN2T and AEN2T cards now this argument doesn't hold up), eliminating a potential single point of failure between the device and the first switch. 2. No active devices (switches and routers) needed. Supposedly this is a cost savings but the increased cabling, termination blocks, and individual card costs trump this. 3. It is slightly more "idiot proof"...the flexibility and ultimate control available with Ethernet comes at a price. 4. Controlnet is "deterministic" in the sense that both packet rates (RPI's) and packet jitter can be precisely controlled. With Ethernet/IP, you can control RPI's but packet jitter cannot be 100% controlled. Then again, when you are running at 20 times faster speeds, it really doesn't make any significant difference. Note that AB just came out with servo control over Ethernet/IP but they never developed this for Controlnet (they used SERCOS instead). 5. You can only implement ControlLogix redundancy with Controlnet.

Share this post


Link to post
Share on other sites
1. ControlNet is a liscensed protocol, owned by Rockwell Automation, whereas Ethernet/IP is a foundation fieldbus (lower hardware costs for Ethernet/IP) 2. There are other Fieldbus technologies out there other than ControlNet and Ethernet/IP 3. If one was to envision the future of remote I/O protocols by looking at the past direction, I would say that Ethernet/IP has a future and ControlNet will eventually die. Look at DH+...reliable, rugged, deterministic remote I/O protocol, but it was liscensed and costly and is now dead. The last point...whether you guys pursue ControlNet or Ethernet/IP for remote I/O, get your darned networks separated. Too many engineers think Ethernet/IP packets flow directly from the device to the PLC located nearby but find out a front office IT system upgrade can shut a production line down. A $500 managed switch was needed to fix a problem that cost a customer $0.5M unplanned downtime due to poor control network design. Leading up to "the big failure", the customer's IT department was adamant about NOT wanting to separate the networks (due to having to manage more network gear). Do your homework and DESIGN your control network instead of respond to a catastrophic problem when it occurs.

Share this post


Link to post
Share on other sites
Hear Hear! This happend to us not that long ago. We have now not only seperated the IT and the Engineering Networks completely but we have also isolated the control on each machine with a seperate ENBT module.

Share this post


Link to post
Share on other sites
When the topic of IT comes up in regard to production networks, and it will, I highly recommend the Teddy Roosevelt school of thought. Speek softly and carry a big stick! Begin by making it clear to management that the IT staff will have to be on call for each hickup in the production arena. Then, when somethng happens, tell IT that they need to restart all the routers and switches, and report all lost time between the time that you make the request until it happens, as an IT related delay. I played this game for a long time and it surprised me how often this solved a problem. Network components can and do look normal but fail to do all that they are required to do. They can get corrupted and act up, and look completely normal via SNMP monitoring, to the run of the mill IT "expert". Another protective measure that takes some of the fun out of it, is to tell management that you need to be in the reporting loop for version maintenance on all network devices. SOX regulations require that this be done, so you might as well know when the changes are to be made, in advance. I'm currently faced with a need to interface with an office network and so I'll get an updated view of the situation before proceeding. I'm not looking forward to the experience but VPN access does offer some advantages. Best Regards, Bob A.

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