DeviceNet and EtherNet/IP

DeviceNet was a revolutionary technology when it was introduced in 1994. You should realize that prior to that, the only automation network that anyone could readily name was Modbus. Even for devices that used proprietary protocols like chillers, everything was a request followed by a response over RS485 serial communications. Send the request, get the response, and move on to the next device request and response… ad infinitum. At the end of the device list, you started over. That’s how everything on RS485 (and RS422) worked. As far as anyone knew, that was the only way to do manufacturing networking.

When DeviceNet was introduced it was just like that scene from that old movie “The Day the Earth Stood Still.” The Alien spaceship lands and no one knows what it is, what it means, and where things will go from here. That’s what the introduction of DeviceNet was like.

Most people were completely stunned by the idea of bit-wise arbitration. DeviceNet is built on CAN (Controller Area Networking), and bit-wise arbitration is the process in CAN where all devices with messages to send concurrently transmit their messages. That’s unlike most technologies where one node talks and all the others listen and wait for their turn to talk. In CAN, every device with a message to send concurrently transmits their bits and continues transmitting until they realize that a higher priority message is on the bus.

The key to that CAN (and DeviceNet) prioritization scheme is that after transmitting a bit, each node listens as that bit is reflected on the network. Since zero bits dominate one bits, anytime a node sends out a one and identifies that a zero is actually on the bus, they know that there is some other node with more leading zeros in the message. Having more leading zeros is how CAN messages are prioritized.

A node that can’t verify that its one bit is on the bus stops transmitting. Any time two or more devices are sending the same sequence of bits, the devices just continue sending bits. The highest priority device – the one sending a message with the most leading zeros – eventually becomes the last device to keep sending. The genius in this is that an individual node never needs to know anything about prioritization. Messages are just transmitted, completely oblivious to any bus conflict.

Bitwise arbitration enables DeviceNet to achieve 100% bus utilization since there is never any destructive bus contention. In 1994, that kind of arbitration along with 500K baud data rates and power on the bus made DeviceNet a truly revolutionary new technology unlike anything ever seen before.

But 1994 was a long time ago. Now, the direction for automaton is clearly Ethernet (EtherNet/IP, ProfiNet IO, Modbus TCP, OPC UA).

So where does DeviceNet fit in an Ethernet world?
We all know that there are hundreds of thousands of DeviceNet nodes all over the world. And we also know that DeviceNet is not going to be easily replaced in those applications. The technology works and it’s well-understood and maintainable. It’s also price competitive to Ethernet – especially when you figure in the cost of Ethernet switches.

DeviceNet is, in fact, perfect for applications where the topography is such that nodes are arrayed linearly. That’s the DeviceNet sweet spot: nodes arrayed linearly like a conveyor line. Unless something changes, you can expect DeviceNet to be deployed in these kinds of applications well into the future.

DeviceNet also has the advantage that it is uses CIP exactly as EtherNet/IP does, only over a CAN physical layer. Instead of the TCP/IP stack and Ethernet physical layer, DeviceNet uses CAN.

CAN provides DeviceNet with several distinct application advantages:

• 100% bus utilization due to the bitwise arbitration discussed earlier
• Power on the bus allows devices to not require any auxiliary power
• Simpler, more cost-effective components (but more expensive cabling than Ethernet)
• More adaptable for lower cost sensors and actuators
• Simplicity, ease-of-use and cost-effectiveness
• Miswiring protection
• Standard 24 VDC Power
• Node insertion and removal under power

Is DeviceNet Obsolete or Complementary to EtherNet/IP?
DeviceNet if not obsolete, is at least on the downward trend. The open question is, will controller vendors continue to support it in the future or only provide access to protocols operating on standard Ethernet? If controller vendors introduce new controller lines that don’t support DeviceNet, that would likely be the death knell for DeviceNet. In that scenario, device vendors, like motor drive vendors, would also discontinue support for DeviceNet (device vendors always follow the lead of the controller vendors). At that point, end users will have no choice but to switch from DeviceNet to an Ethernet implementation.

The other headwind that DeviceNet faces is component cost. As fewer devices are made and the technology ages, component costs increase. Ethernet is continuing to get less expensive as industrial Ethernet is no different than commercial Ethernet at the physical layer. If there is a tipping point where Ethernet devices become comparable to or less expensive than DeviceNet devices, there will likely be an erosion of support for DeviceNet by end users.

Either way, manufacturing is not prone to radical changes. We should continue to have DeviceNet around to some extent for the next 20 to 30 years. It’s over 20 years old now. Let’s hope it sees a 40th or 50th birthday.