I first heard about EtherNet/IP sometime in the late 1990s. Up to that time we had been working almost exclusively with DeviceNet. DeviceNet was a huge step up over serial communications protocols like Modbus. For those of us working with multi-drop serial communication links operating at 19.2K baud, DeviceNet was like stepping into a race car. It offered 500K baud, connected devices, duplicate address detection, LEDs with defined behavior, plug and play operation, power on the wire…it was heaven for us developers. We were in the big time.
But not everybody got it. There were still a lot of serial folks out there and they didn’t really understand the sea change that DeviceNet brought. I still remember a phone call I took sometime in 1998. It was a “code cowboy.” For those of you unfamiliar with the term, Code Cowboys are guys that code everything. They’re completely self-reliant and never use anybody else’s code. They don’t understand the concept of building on top of work that someone else has done. They do it all themselves.
Well, the 1998 version of the Code Cowboy asked me where he could get the “guzzintas” and the “guzzoutas.” In English that means what goes in and what goes out. As we talked, I realized that he had no understanding of connected communications – how one device establishes a connection with another device and then uses that connection for communications. For him, everything was I send this, I get that back. I never did find out if he ever figured it out.
So, in the late 1990s we’re working with DeviceNet in a big way: developing I/O boards, selling stacks, making gateways. Life is good. But there’s a problem. The problem is that DeviceNet requires every device to go through a start-up sequence (Duplicate Address Detection) where it announces itself on the network. Essentially every device says, “I’m a DeviceNet device on Address X” and waits to see if there are any other devices on the network with the same address. If it doesn’t hear any complaints about it taking Address X, it repeats the sequence. If, on the second attempt, it doesn’t hear anyone object to it being address X, the device becomes Address X on the network.
Time is of the essence
The problem with all that is that it takes time. That means when an operator at the GM Final Assembly plant hits the big Green Button to start the line, ten to twenty seconds pass before the line starts because you have all these devices doing Duplicate Address Detection. I honestly don’t know if it’s true, but I’ve heard that those few seconds that could cost a company like GM over two million dollars a year.
To solve that problem, DeviceNet added something called QuickConnect. QuickConnect enabled devices to bypass a lot of that start up and get communicating earlier. It was a great addition to the technology. RTA was one of the first companies to implement that technology. Our robotic tooling customers were the first ones to deploy DeviceNet QuickConnect.
Now, that same kind of enhancement is being added to EtherNet/IP. There are many situations where we want to power on EtherNet/IP devices and get them communicating immediately. To meet that need, there has been some specification work done to create QuickConnect for EtherNet/IP.
The trouble is that as of the date of this article (2015), there are not yet any devices to support QuickConnect, and Rockwell PLCs don’t support it. The ODVA Certification Test suite doesn’t support it. Even though it hasn’t really been deployed, we’re getting calls from customers who want this technology. But without a way to validate our implementation and a way to certify application code, it isn’t something that we can deliver in 2015. So, if you’re one of the customers that desperately wants EtherNet/IP QuickConnect, please sit tight. 2016 is almost here and we may be able to support it then.
PS – RTA has a very easy to use gateway for moving ASCII data into Rockwell PLC Tags over EtherNet/IP low level communications. Click the link for more information.