ControlLogix network: Ethernet vs. Controlnet

A customer wants us to change from ControlNet to EtherNet on a new installation using networked ControlLogix PLCs. Can anyone explain/discuss the pro's and con's of such a change? Thanks

Why? The only way to makes sense of such a change would be to understand the reasons behind their desire for such a change.

In brief both media types will do the job they are designed for perfectly well. The main differences are:

ControlNet:

1. Passive coax media, very easy cable redundancy, excellent industrial noise immunity, robust vibration resistant BNC connectors. Trunk/drop line configuration requires the least amount of cable to be installed.

2. Very good bandwidth and throughput, CNet is just about the fastest network out there in common use.

3. Data transfer is deterministic, ie you can schedule data to be moved at the exact intervals you require, down to 2msec.

4. The single biggest downside is the need to use RSNetworx for CNet to do the scheduling and this cannot be done with the processor online.

5. Using dual redundant media makes it very easy to physically add new nodes, because one channel will continue operating while the other is being worked on.

Ethernet:

1. Very standard hardware, well understood by IT people. (This may be seen as a downside by some!) However much of that hardware is not always well suited to all industrial environments, both physically and electrically.

2. Most nodes will support some form of WebServer for diagnostics and config.

3. Performance is good, but not determistic, and I believe that throughputs are usually not much less than 8-12 msec.

3. Easy to add another node online with point to point wiring. No requirement to cut into a trunkline and schedule a network. But of this because there is a problem that "every man and his dog" think they understand Ethernet, and so there is a very strong tendency for the system to get added to, modified and hacked in an uncontrolled manner, which will lead to problems.

4. The most important requirement is that larger systems will require some skilled input from a network engineer to ensure the switches are both correctly specified, configured and maintained.

Both networks may well do the job, but to determine which is the best, we need to know what the end-users thinking is and what their motives are for requesting the change.

I agree with much of what PhilipW says with some reservations.

His main point of 'why change' is a very good point and should be heeded. This sounds like a request that may not be based on any technical engineering. It may just be that the customer BELIEVES they understand Ethernet while ControlNet is black magic to them. I don't consider this a valid technical reason. So the big thing is find out what they want to change for.

As PhilipW said, ControlNet provides very good noise immunity. However, in the Ethernet/IP jobs I have done noise has never been a problem for me. Granted, I wasn't running Cat5 past a welder or wrapping Cat5 around a 200 HP motor three or four times. But in the jobs I did noise wasn't a problem. I kind of equate ControlNet's noise immunity to the 4-bolt main bearing caps in the old Chevrolet V8's. Sure, you can't argue that the four bolts were stronger than the two bolts. But when was the last time you heard of someone breaking the main bearing cap bolts in their motor? I personally never have.

Yes, ControlNet data transfer is deterministic. The problem is that the PLC scan is much less deterministic. So if I get data into my plc at a 2 msec interval with sub-microsecond jitter, what does that do for me if my plc gives me 10 or 100 microsecond scan jitter?

I think Ethernet/IP get a bad rap when it comes to data throughput. People compare it to ControlNet without looking at architecture. By it's nature ControlNet becomes a segregated network. This isn't based on any technical requirement of ControlNet; it's just logistics. Joe Off The Street has no reason to connect to ControlNet. So he has very little opportunity to adversely affect it's performance. Contrast that with EtherNet/IP, where someone might tie an EtherNet/IP I/O network into the main plant network just so they can program from their desk upstairs without considering the consequences. In that case, yes, the performace may be bad. But if you conceptually treat EtherNet/IP like ControlNet you don't get into nearly as many issues.

I had a chance to run a test of data transfer rates between two ContolLogix PLCs. I set up a 4000 element real produced/consumed array pair betweeen the two plcs and transfered them as fast as the setup would let me. I did this twice, once using two ControlNet bridges connected directly together and once using EtherNet/IP bridges on our base company network. I know, one of the big no-nos. I got much better performance with the EtherNet/IP setup. I'm pulling this from memory but I think it was about a factor of 10 faster. Granted, the data update jitter was probably higher with EtherNet/IP but I ultimately still got the data faster.

People often equate determinism with speed. They are not the same thing. If can have a data update period of 10 seconds and as long as the system never violates that 10 second period it's deterministic. 'Determinism' has recently replaced 'vector drive' as my new favorite word in the 'useless outside of context' category.

PhilipW does make some good points about durability. Outside of the straight-up fact that you can set up a redundant ControlNet system (which, as far as I know CAN'T be done with EtherNet/IP) the ControlNet media is a much physically tougher media. Once it's in and working it's hard to hurt.

OK, time to get off the soapbox. I'll just say again that you have a working system with no technical issues. I sure wouldn't change that unless I can get a good reason why. Sure, the customer is always right, unless he's wrong.

Keith

Thanks for the good discussion. The customer wants to change the system (I think) because they are afraid that their technicians won't understand the ControlNet. They have EtherNet in most of their lines. I'm not sure what kind of speed issues the network has to deal with, cause the engineers who normally program and install the systems are out on jobs. If I can get any more information, I will share it. thanks again for the feedback.

In my opinion that's not a real good reason to change. ControlNet is a solid network. It really isn't very hard to deal with. Once the network is in the data transport medium is transparent to the user. Transferring on ControlNet looks just like transferring on EtherNet/IP. I actually think that ControlNet diagnostics are a little better than EtherNet/IP diagnostics. So if they are worried about fixing it, that's not a good reason to go EtherNet/IP.

Keith

I would recommend using CNet for your control net traffic such as connecting to I/O racks, drives and such. I would use Ethernet for HMI communication etc... that seems to be a typical installation of PLC systems that I have seen.

I doubly encourage adopting Sheldn's approach.

In the past, presently, and in the future, I will continue to insist absolutely on seperating the I/O subsystems from any ethernet network. Not because of the deterministic nature of ControlNet, but rather due to the fact that Ethernet, more specifically, IP and it's variants, will inevetably fall to the IT department's domain. Even with the very best managed networks, disaster can strike. Want real fun some day? Find an ethernet switch or hub somewhere with two ports open on it... take a patch cable, and plug the switch into itself... watch the ensuing fun! (NO! DO NOT DO THIS!!! EVER!!!!).

Unless the network is configured with switches that support STP (Spanning Tree Protocol), and is properly isolated by STP switches, this will cause every single IP addressed device to shut down due to seeing a duplicate IP address. Smart, or even managed switches, without STP will not shut this down as a packet-storm, as they think everything is fine based on the MAC ID's.

I do put the HMI's on Ethernet, as it makes centralized data-collection, as well as quickly going online for troubleshooting, or backing something up, very easy. Of course, I also insist on having hard-wired Start/Stop, and of course ESTOP circuits. I never run line starts from an HMI. Personal preference.

Even without the IT department monkeying around (and, if they don't have one today, they will in a year, or 5, or 10), segments of and Ethernet network, if not the whole network, can be taken down by an uncooperative (or failing) device. I have one computer that will work fine for a few hours, but eventually will start locking up ethernet because it has a bad network card. It's fun to have around as a demonstration of what can happen.

I second rdast's comments. It is important to segregate the communications links (Control and Higher Level) and let each do what each does best. I think you will start to see that obscure as protocols that once were media specific such as Profibus and Fieldbus are moving into Ethernet media with Profinet and what ever fieldbus is calling their protocol over ethernet in addition to Ethernet I/O. At the end of the day it is a good idea to keep these busses separate. In the old days you could only connect Remote I/O RIO devices to a RIO link and that was a good thing. It didn't get you thinking that you could install a bunch of switches to connect it all together so that every device can talk to every device while neglecting the need to assure I/O through put.

Separating the busses also is good if you get caught up in the IT versus engineering whether the link is CNet Coaxial cable or CAT6 cable or any other media.

Getting back to your CLGX comment, the nice thing is Rockwell has the individual modules to connect how you would like or based on the advice from the others on this thread. Yes it can start to add up when you have CNB(R) and ENBT modules in racks etc... but this common architecture works quite well from my experience.

If you use EthernetIP, get IGMP snooping switches, that's for sure!

It is an unfortunate truth of any organised human endeavor that you need to very carefully account for the human element. Of all the things said above about Ethernet based networks the only valid argument against them that I see is the human element. With the advent of the PC everyone thinks they know what to do with an RJ45 connector. So your Ethernet based systems are ripe for someone plugging in or unplugging something they shouldn't.

The hardware argument doesn't do it for me. I can come up with at least as many ways to bring down a ControlNet network as I can an EtherNet/IP network. Probably more since ControlNet more closely checks things at the hardware link level.

Sheldn made the comment about letting each network do what it does best. Well, I would propose that, with the obvious exception of redundancy, EtherNet/IP largely does what ControlNet does better than ControlNet does it. Its the same upper level protocol running on a different hardware layer. You would expect the higher performance hardware platform to perform better.

The unfortunate truth is that more people will mess with an Ethernet system than will mess with a ControlNet system. That single fact can make EtherNet/IP less reliable than ControlNet, and in some cases, disqualify it from consideration.

Keith

As was mentioned earlier in the thread: CNet will keep the IT dept. at bay. My experience has been that if it is Ethernet it will be taken over by IT and treated like an e-mail server. A protocol that an IT manager has never heard of will be treated like a rattlesnake with rabies...it's yours-you deal with it. If you are the integrator that is installing and commissioning the system this isn't a concern. If you are an engineer or technician that is responsible for the control system it gets tough to keep a process running while shackled with e-mail operating procedures.

I set up a 4000 element real produced/consumed array pair betweeen the two plcs and transfered them as fast as the setup would let me. I did this twice, once using two ControlNet bridges connected directly together and once using EtherNet/IP bridges on our base company network. I know, one of the big no-nos. I got much better performance with the EtherNet/IP setup. I'm pulling this from memory but I think it was about a factor of 10 faster

Click to expand...

I'm light on the exact details here, but I suspect that with 4000 REALS you were way past the 512 byte limit that CNet puts into one packet, thus it probably had to break each transfer up into multiple NUT's, whereas the ENet connection could send it all in one hit?

That is possible. I don't have all the processors and bridges around here anymore. I can't run an appples-to-apples test at a lower byte count to see what the performance level would be like. It would be an interesting test, though.


Keith

kamenges,

How did you test the through-put with your test setup? I have all the hardware needed and would like to try. I have set up produced consumed using ENBTs and CNBs, but cannot figure out how to compare the results.

I am a maintenance tech who has worked with DH+, serial, Cnet, and Ethernet I/P. I have only had one controlnet problem. A repeater failed. Its red light was on. We replaced it, and it started up and ran immediately with no need to understand any of it. I have had to re write the C-Net unscheduled messaging logic on one machine, but had no problem sorting it out. From the PLC software perspective it's as easy to understad as DH+ messages.

Ethernet I/P is being used here for I/O on one machine. It's isolated from the IT departement, and is trouble free. There were special precautions taken to ensure orderly shutdown if there is a problem with communication.

We have quite a few non I/O ethernet applications. We haven't had any problems there either.

I have read a report from Rockwell several years ago about data throughput on CNet, Enet I/P and DH+. I remember that C-Net and E-Net I/P had the same value something like 5,000 words (integers?) per second I think, but I don't remember which ethernet speed was compared.

I have searched for that document, but haven't found it on the website.

Just my 2 cents
Paul