Controlnet vs ethernet vs devicenet

Decided to start this as a new thread.

I never quite understood the differences,pros vs cons between Control Net,Ethernet and Devicenet. Can anyone speak on this I know its off subject but looking into a Control Logix on Ebay I found one with all three installed. Why?

Device net is intended for local connection of sensors, actuators, drives etc.
64 devices can be connected on a network.
The main function is controlling I/O at the machine level. Limited power is available using the 4 core wiring to power up sensors and light loads.
Multiple vendor hardwares are supported.

Control Net is a higher level, with up to 99 devices on a network.
Generally uses coaxial cable with high level of shielding.
It's purpose is interconnection of PLC units, HMI on the factory floor level up
To upper management IT level.

Ethernet has a number of flavours, cheap hardware, open, not really intended for device level but can be used. Almost unlimited devices, Connect ability is the main selling point here, almost any PC has an Ethernet connection, and through the Internet access is possible to connect to your factory from anywhere in the world.

Unless you already have an overwhelming installed base of Devicenet or Contronet then Ethernet trumps them both. For many of the reasons Liam points out. Now many of the new products coming out come with a built in two port switch that allows for linear topologies and makes things even simpler.

In my opinion ControNet should never have been developed.

Wikipedia has nice little summaries of each. There are real advantages and disadvantages to all of them, but I do everything Ethernet and have never regretted it.

DamianInRochester said:

Unless you already have an overwhelming installed base of Devicenet or Contronet then Ethernet trumps them both. For many of the reasons Liam points out. Now many of the new products coming out come with a built in two port switch that allows for linear topologies and makes things even simpler.

In my opinion ControNet should never have been developed.

Wikipedia has nice little summaries of each. There are real advantages and disadvantages to all of them, but I do everything Ethernet and have never regretted it.

Click to expand...

There is still is one ControlNet feature none of the "modern" communication protocols have been able to achieve yet:
ControlNet is a deterministic network; data transfer timing is exactly the one defined by the user.

EtherNet/IP's RPI stands for Requested Packet Interval; if it is set at 10ms it doesn't really mean that the data is updated every 10ms. I could be 7ms, 15ms, 3ms, 30ms, etc. The large bandwidth of Ethernet communications usually quenches the randomness.

However, the NUT (Network Update Time) of a ControlNet network is permanently enforced by the Network Keeper.
It is always the one set at scheduling time, no more, no less.

Highly time critical, accurate applications require a deterministic approach, and, as of August 2012, the only network protocol providing this feature is ControlNet.

As others have said Ethernet trumps all. Contronet is deterministic and has it's place but that level of determinism compared to ethernet IP is needed only on very rare projects.

I love the diagnostics and such that you get with devicenet but it is getting a little long in the tooth and IMO needs a replacement. I would like to see the price point of ethernet come down to a level that it could be more on the sensor diagnostic level like devicenet. It is getting adopted into large sensors now like linear encoders /feedback and some process meters and valves controllers.It would be nice to see ethernet ip making the same device level inroads as IO link. I wish more vendors would start supporting IO link also.

Liam Moran said:

Device net is intended for local connection of sensors, actuators, drives etc.
64 devices can be connected on a network.
The main function is controlling I/O at the machine level. Limited power is available using the 4 core wiring to power up sensors and light loads.
Multiple vendor hardwares are supported.

Control Net is a higher level, with up to 99 devices on a network.
Generally uses coaxial cable with high level of shielding.
It's purpose is interconnection of PLC units, HMI on the factory floor level up
To upper management IT level.

Ethernet has a number of flavours, cheap hardware, open, not really intended for device level but can be used. Almost unlimited devices, Connect ability is the main selling point here, almost any PC has an Ethernet connection, and through the Internet access is possible to connect to your factory from anywhere in the world.

Click to expand...

So each gives you the ability to network your PLCs so you can edit parameters and the program from any internet connected PC? But the differences are numbers of devices able to connect,transfer speeds and transfer consistentcy, and type of connection? Can you give a real world example of how to use each one where it would be ideal?

I still dont quite understand devicenet. I know I have read its for connecting sensors, actuators and other devices,but why and how. I know this sounds stupid but isnt that what I/O modules are for? Can you ellaborate on this and give an example?

Without knowing the facts, (perhaps someone like Ken Roach would know), it is my understanding that determinism is being developed for EtherNet/IP.

I remember reading that it was a feature they wanted to add, just don't know how far down the road it has got.

Anyway, to answer a previous reply - when ControlNet was first introduced, it knocked the spots off EtherNet/IP, which was 1 or 10MB/s (ControlNet runs at 5MB/s). This was due to the scheduling of critical I/O data, which EtherNet/IP could never achieve.

Of course, EtherNet hardware has moved on, most installations now run at 100MB/s, hubs have been superseded by switches, and I/O updates could be achieved faster than ControlNet, even with the odd "collision" or two.

So it's not just a question of which is the best network - it boils down to what you want to do with your network, and if you need determinism, you'll be stuck with ControlNet - unless (until?) determinism has been successfully implemented in EtherNet/IP.

Skiroy said:

So each gives you the ability to network your PLCs so you can edit parameters and the program from any internet connected PC? But the differences are numbers of devices able to connect,transfer speeds and transfer consistentcy, and type of connection? Can you give a real world example of how to use each one where it would be ideal?

I still dont quite understand devicenet. I know I have read its for connecting sensors, actuators and other devices,but why and how. I know this sounds stupid but isnt that what I/O modules are for? Can you ellaborate on this and give an example?

Click to expand...

DeviceNet, as its name implies, does not "give you the ability to network your PLCs so you can edit parameters and the program from any internet connected PC" ControlNet and EtherNet do allow this sort of data traffic.

High level communications are not what DeviceNet is about. Think about DeviceNet as a system that allows "chunks" of data to be Inputs, and Outputs, from the PLC.

All of the "chunks" are fixed size, and allow no variation in their data length. Si it's not a "communication" network, just a "data-transfer" network, so is only suitable for I/O that has fixed data sizes to work with.

dmargineau said:

ControlNet is a deterministic network; data transfer timing is exactly the one defined by the user.


Highly time critical, accurate applications require a deterministic approach, and, as of August 2012, the only network protocol providing this feature is ControlNet.

Click to expand...

This is only true if you are looking through Allen Bradley goggles.

Let me qualify my point regarding why ControlNet never should have been developed.

Was it that they could not have developed determinitic format using Ethernet? (see Sercos III, EtherCAT, Powerlink)

Or why not simply use something that was already developed, had determinism, and practically the same performance. (ie Sercos). And was already being used on the Kinetix.

And regarding the need for determinism, I am sure it is because I live in a smaller world where these things just don't come up, but I have yet to have an application of my own that required it on any grand scale. Usually any small part of what I am doing that would require determinism gets it with the motion controller network and is kept separate from the main control. It would be nice to know what percentage of applications ControlNet was installed on because it was over specified and they didn't know that they didn't need it. Or what percentage it was installed on because they were not sure it was needed and erred on the side of caution.

I feel the same way about DH+, and even to a certain extent DeviceNet. It seems like they went out of their way to come up with something proprietary. I am all for it if what you come up with something that blows that pants off what is out there, but when it is more so just the same only different, then what's the point.

I agree with Damian. "Determinism" is most often a red herring. It's one of those terms that sounds really good, but on close inspection has little practical impact except in rare circumstances.

It is now very economical and practical to put local intelligence anywhere you need very fast and/or predictable response. Whether it be a motion controller or a networked micro-PLC, you can handle time critical control functions on the spot with hardwired I/O or smart sensors or a combination of both. For example, a local LCP with a micro-PLC can control most VFD functions nicely over a dedicated comm link, with the micro-PLC executing the control logic based on setpoints transmitted from a master PLC or SCADA system. Machine protection functions are handled by the micro-PLC, and E-Stop and critical functions can be hardwired. Determinism in master to local comms isn't important. Remote I/O and micro-PLC cost differentials are insignificant compared to the total cost of a projet.

Want to wire sensors to local "dumb" I/O and use a comm link so time critical control can be handled at a master? Fergeddaboutit!

Where does MODBUS fit in? I am used to Allen-Bradley PLC5s, ControlLogix and CompactLogix, talking DH+ earlier, and now Ethernet.

Any time we are commissioning, the ethernet networked equipment is talking with no problems but other departments spend hours and hours figuring out why their modbus based communications aren't working. Its always "register" this, "register" that, "offset" this and "offset" that, yada yada ad nauseum.

I cringe when I see a new project with a modbus device (usually an RTU like a Scadapack 32, or a transmitter using RS485) interfaced with my PLCs because they usually install a Prosoft module to handle the modbus and forces ME to also deal with the register bs.) Hate it.

What real benefits are there to choosing modbus over ethernet for either a machine level or plant level installation? We still have to remotely talk to these devices from all around the U.S.

To me the biggest advantage to Modbus is that it is implemented on many devices from many different vendors. It may not be the native protocol on most devices but it is close to being a universal second choice. As such, it makes it the protocol of choice when you need to get devices from different manufacturers to talk with each other.

I agree with Steve. Modbus is trying to be that one size fits all. Once you start getting there everyone implements it just a little different.

I do some testing for a few companies EIP, Modbus RTU, etc. EIP can be just as bad as Modbus. I have some companies that do RIO. The more modules they have they more the configuration change.

Skiroy said:

So each gives you the ability to network your PLCs so you can edit parameters and the program from any internet connected PC?

Click to expand...

No, that is a separate conversation, really.

Skiroy said:

But the differences are numbers of devices able to connect,transfer speeds and transfer consistentcy, and type of connection? Can you give a real world example of how to use each one where it would be ideal?

I still dont quite understand devicenet. I know I have read its for connecting sensors, actuators and other devices,but why and how. I know this sounds stupid but isnt that what I/O modules are for? Can you ellaborate on this and give an example?

Click to expand...

I like devicenet for VFDs. It is highly reliable and flexible, but as others have said, any opportunity to move to Ethernet/IP should be taken along with proper diagnostic techniques to get to at least good determination.

If you can detemine the comms are lost and take appropriate action, that is close enough to deterministic for me.

Controlnet keeps I/T out of it and is pretty solid in my (now over 7 years ago) experience: If it breaks, reset/replace the dead device or the one with the red flashing lights and look over your cables...I only saw two hardware failures that were just R&R and up again.

Devicenet is similar but overkill for only discrete i/o, great for low to medium sized control networks with drives and simpler devices. Easy to troubleshoot, not too hard to configure and monitor.

JeffKiper said:

I agree with Steve. Modbus is trying to be that one size fits all. Once you start getting there everyone implements it just a little different.

I do some testing for a few companies EIP, Modbus RTU, etc. EIP can be just as bad as Modbus. I have some companies that do RIO. The more modules they have they more the configuration change.

Click to expand...

Modbus was the one shoe that everyone needed to fit for a long time.

So yes, all other manufacturers have heavily supported it for what, 40 years? Make a list of devices you have used that don't have Modbus support.

I like the Modbus protocol, but have only worked on existing implementations except for one. If it ain't broke...