Merging modern software development with electrons and metal
Random header image... Refresh for more!

Ethernet Fieldbus Wars: One answer

There are two million different Ethernet field-bus standards.

OK, there aren’t really that many, but it seems like there is.  Which one to use?  One approach is to look at the suppliers you like and see who they support.  For example, I like AMC and Copley drives; they both have CANOpen drives, but for Ethernet, Copley only sells EtherCAT drives and AMC only sells Ethernet PowerLink drives.

I don’t have time to list all the vendors I’d normally consider and what standards they support, but I did notice they almost all use one of four choices:

  • The motion control vendors use either EtherCAT or Ethernet PowerLink
  • The embedded PC / PLC / Input-Output vendors support Modbus/TCP or Ethernet/IP.

Also, the IEEE-1588 precision time protocol (used by Ethernet PowerLink and Ethernet/IP CIP) is going mainstream in a big way; I will write more about this topic later.

I find it interesting that the drive vendors and I/O vendors use different standards; I wonder how many people need a lot of motion and a lot of I/O.

And, yes, my view is very much a personal,  North American, discrete automation view.  But I’m not saying any of the other field-bus choices are bad; just apply the same approach with your supplier list.  For example, if your preferred vendor is Siemens, it’s obvious which way you should go…


1 Carl Henning { 06.05.09 at 2:59 pm }

Tony, I wish you had finished that sentence with the word… PROFINET… which by the way does apply to drives and IO. Supported in North America by PTO ( and the PROFI Interface Center ( And if your preferred vendor is any of many other vendors here, you will also find PROFINET as an Industrial Ethernet choice.

2 Jacques @ AutomationSolutions { 10.15.09 at 6:28 am }


As far as I know Ethernet Powerlink doesn’t use IEEE 1588.

I think the reason for the difference you’re seeing comes down to the fact that many customers who have a lot of I/O don’t need the quick cycle times and low jitter you can get with real-time industrial Ethernet. For applications with a lot of I/O and low realtime requirements, Modbus/TCP is a great solution because it’s very cheap to implement and widely available.

My guess is that you’ll see more and more vendors of slave devices supporting a bunch of common real time Ethernet protocols. Adding real time Ethernet to a product used to be a big development effort, but you’re starting to see products like the netX chip from Hilscher ( that make it a lot easier.

Companies like B&R are already taking this approach with their I/O devices (see for example

3 Tony { 10.20.09 at 4:58 pm }

OK, a correction: IEEE-1588 is not in the original Powerlink spec, but is mentioned as “will be added”, and a quick check of EPSG DS301 V1.1.0 shows fields (optional, I think) for IEEE-1588. BTW, when it comes to precise time synchronization, IEEE-1588 is as dominant as Ethernet is in networking. And the gains from hardware synchronization support are real.

The Hilscher netX chips are interesting (e.g. the large amount of SRAM, DRAM support, multi-protocol support, IEEE-1588 support, hub/switch support), but definitely have their issues such as only BGA packages, small cache (a 200MHz ARM9 with a small cache is definitely bandwidth limited), no floating point, and lousy peripherals (ADC and PWM are pretty limited compared to motion-oriented DSPs and Cortex-M3s). The netX approach is roughly similar to Freescale’s PowerQUICC MCUs, especially the MPC8360 (but the 8360 is substantially more capable (e.g. gigabit Ethernet) and complex; pricing might be about the same as the netX 500).

The netX chips aren’t well suited for small companies, and would require a redesign for many vendors (e.g. Cognex Insight uses PowerPC IIRC), which isn’t likely to happen. BTW, the open source stack for Ethernet PowerLink (thanks, Systec) should also make it easier to add real time protocols.

I still suspect that most manufacturers won’t be adding real time protocol support until a lot of their customers ask for it. I know regular Ethernet is quite fine for tasks such as communicating machine vision results from smart cameras to robots. Also, I don’t think multi-protocol support will become that common; I think most companies will pick one or two to support.

I could easily expand this into a full post, but unfortunately right now I’ve got other tasks to do.

Leave a Comment