Sit Tight; EtherNet/IP QuickConnect is Around the Corner


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 …

Ivan in IT and His Paranoia about Cloud Communications


I have a friend named Ivan. Ivan’s from the old country. A really great guy. He likes the Green Bay Packers (it’s kind of required in Wisconsin). He’s fun, married with two little daughters. That’s a problem, but he won’t know it until they become twelve or thirteen. I haven’t given him the bad news yet.

Anyway, Ivan’s real problem is that he’s an IT guy. IT guys are an odd breed. They’re different than us factory automation guys. We’re about making things go faster and getting better quality. It doesn’t matter if we’re making cars, doors, medicine or those little straw umbrellas they put in the girls’ drinks (visiting the little straw umbrella factory is on my bucket list). Factory automation isn’t a club; we don’t have a secret handshake or anything (at least one that they’ve let me in on), but we do have our way of doing things and our own technologies.

Ivan in IT and the rest of his kind have a much broader mission – to protect the electronic infrastructure of the corporation and the assets in that infrastructure. They have all sorts of rituals and processes for doing that. A lot of them I can understand and appreciate. Others I think are, well, nuts. Some of that is because the opponent (hackers) they’re working against is pretty stealthy. They can be attacked and not know it. They can lose millions of customer accounts and not know until long after the theft happened. They really never know if everything is fine or they’re just oblivious to the attack. Paranoia is an asset for IT guys.

So as we go about integrating with the company’s business systems (forward-integration with customers and backwards-integration with vendors) we have to be very conscious of how our work is going to be perceived by Ivan and the other IT guys. If we’re creating any vulnerabilities that are going to make the electronic infrastructure less secure, their paranoia is going to kick in and they’ll stop us pretty quickly.

A pretty typical example of that came up just the other day. A few quality control variables in a Logix processor are pretty important to understanding the operation of a process in the food and beverage industry. There’s a woman who is doing some analysis and wants to collect those variables from three Logix processors at three different remote sites in “the cloud” – the cloud in this case meaning a sequel database.

For those of us who aren’t IT trained, we’d think about this in a pretty standard way. An application in the cloud knows when to collect these things; it sends a message to the processors requesting that data. In this case, Logix processors, being not all that friendly to IT systems, would have one of our products (a RTA box) as a front end. The RTA box would gather the data and make it available in an OPC UA address space. Because the box is an OPC UA server, …

EtherNet/IP Big Data Part 2

EtherNet/IP Big Data

In my last article, I discussed how to use EtherNet/IP Explicit Messages to transfer large blocks of data between an Originator (typically a Scanner like a PLC or PC) and a Target (some end device). In this article I’m going to discuss the various ways you can use I/O Messaging (also called Implicit Messaging) to move large blocks of data. Unlike Explicit Messaging, which moves a specific attribute between Originator and Target, I/O Messaging moves I/O Assemblies between Originator and Target. Understanding all this is critical without a foundation knowledge of CIP (Common Industrial Profile) data.

Here’s a cheat sheet on CIP terminology that you’ll need to understand all this:

CIP Devices: Common Industrial Profile (CIP) devices are devices which organize data in terms of Objects, Instances and Attributes.

Objects: Objects are groupings of like Attributes. For example, the predefined Identity Object is the collection of Attributes like Vendor Number, Revision Number, Product Code, Description and other Identity data.

Instances: Instances are Objects that duplicate the Attributes of an Object Class. A Flow Meter that monitors two water channels might have two instances of Flow Attributes, one for the first channel and one for the second channel.
Attributes Attributes are the data elements of an Object Instance.

Input Assemblies: An Input Assembly is a collection of Input Attributes, or real world inputs, that are collected together to be transmitted to a Scanner as a group

Output Assemblies: An Output Assembly is a collection of Output Attributes or real world outputs that are collected together to be received from the Scanner as a group

It’s critical to understand that an EtherNet/IP Adapter device simply connects the Scanner to the real world. The Scanner sends a set of Output Assemblies to the Adapter and the adapter device sets its real world outputs from the output buffer. The same thing happens cyclically to the inputs. The Adapter device collects inputs and cyclically send those inputs as an Input Assembly to the Scanner.

In normal operation, these Input and Output Assemblies are pretty small. For example, the Output Assembly for a sixteen valve, pneumatic valve is simply sixteen bits long. Likewise, the Input Assembly is typically also sixteen bits; the current state of each of the sixteen valves.
But often, and it’s happening more now than ever, an Adapter device has much more than sixteen bits of data. Sometimes it has 1K or 2K or 10K of data – much more than is allowed in an Ethernet packet, let alone an I/O message. The limits to an I/O message are what fits in a UDP packet (I/O messages travel as UDP packets). That means 1500 bytes, except when a Rockwell ControlLogix or CompactLogix are the Scanner. The I/O message size is reduced to 500 bytes for these devices.
When the Input or Output data you want to transfer exceeds the limits of a Rockwell Scanner or a UDP packet, there are several options:

OPTION 1 – Use Multiple IP Addresses

In a PC environment …

EtherNet/IP Big Data

rta-blog-image-templateTransferring large data sets in EtherNet/IP using Explicit Messaging
I keep a big bag next to my desk. It’s filled with questions I’ve gotten over the years from customers. Some of them are really good and make me think. A lot of them are just good questions that always confuse the casual user of a technology like EtherNet/IP, and others, well, some of them are just peculiar.

I remember one guy that sent me an email asking about the battle for the Argonne Forest in World War I. He wanted to know how the battles of the 77th Infantry Division affected the progression of the overall battle in Europe. Wow! I admit to being a history buff, but I’m not a professor of World War I history.

Well, I looked into the bag, and for today’s article I spread out a bunch of questions on my desk that all revolve around EtherNet/IP assemblies, moving huge data sets over EtherNet/IP and making your EtherNet/IP device look like two devices. It’s a bit technical, and if you’re new to EtherNet/IP, you may just want to watch my video introduction to EtherNet/IP or read the 6.5 things you have to know about EtherNet/IP.

The reason that moving lots of data over EtherNet/IP is important to so many people today is because today, more than ever, they have devices that generate lots of data. This hasn’t been a big issue in the past, but it is gathering steam. More and more devices are going to become archivers, archiving all sorts of production, maintenance and operational data. That data needs to get transferred someplace, and since the device support EtherNet/IP, that’s the apparent first choice.

It’s just that it isn’t always easy to do that. There’s two messaging options in EtherNet/IP, Explicit and Implicit, and in today’s article I am going to focus on how to move large data sets with Explicit Messaging.

Explicit Messaging is the mechanism in which an Originator (the one “originating” the message) sends a service code (an action to perform) to a Target. The Originator is usually a PLC but doesn’t have to be. The service code can be one predefined by the EtherNet/IP specification or a vendor service code created by the vendor to support some special service, like transferring a large data set. The Target receives the message, performs the service requested in the message, and returns a response that includes a status code.

It’s important to know that this can be, but usually isn’t, a scheduled service. There is no requirement for an Originator to ever send an Explicit Message. The Originator can send it every 50msecs or every 50 days or once and never again. It’s strictly at the whim of the Originator.

EtherNet/IP Explicit Messaging is pretty simple and straightforward if you are setting the drive’s ramp time to 50msec or getting the value of Input 17 or issuing a command to start a recalibration process. But if you are sending a message requesting …

Modbus Conformance

Modbus_ConformanceIf you’re a device manufacturer and you’ve ever developed an EtherNet/IP Adapter, BACnet/IP Server or a ProfiNet IO Slave device, you are cognizant of conformance testing. These organizations are sticklers for making sure that products are not released to the market without validating that they have the minimal required functionality. This is very typical of most industrial protocols. Most trade organizations specify a protocol test that has to be successfully executed to get a certification statement or logo that a device vendor can use to indicate that the device conforms to the specification of the technology.

This is, of course, extremely important to a lot of very big, very important customers like automotive manufacturers. They don’t want to spend their time sorting out the whys and wherefores about why product X doesn’t work well with product Y. In fact, it’s absolutely the last thing in the world that they want to be doing. They want to buy a certified product specifically so they won’t be fighting that battle. They know that there is high probability that your certified product is going to perform correctly in their application.

Modbus has been a little late to this party. For a lot of years, there was no conformance test for Modbus products. A developer would create something, test it in some fashion, and ship it. It was left to the user to figure out what worked and what didn’t work.

In the time since, the Modbus Organization has remedied this problem. They not only established a test procedure, they contracted with the University of Michigan to implement it. You now have two options for certification of your Modbus Slave device or Modbus TCP Server device.
One, you can self-certify. That means that you download the test and execute it yourself. You pledge that your product meets the minimum functionality of a Modbus device as specified by the test.

Two, you can purchase testing from the Modbus Organization. The test lab at the University of Michigan will perform the test for you and validate your device. That, of course, is going to cost you some cash and some time. But you get a second set of eyes and third party testing.
You can find out all about testing, including what tests to perform and what options are available, by visiting the Modbus Organization certification web page at

If you visit that site, you will notice that only your Slave or Server device can be tested. There is no test for Master or Client devices. The Controller side of many programs cannot be certified through the trade organization’s test facility.

You will also note on that site that only Modbus TCP Server devices can be tested. The Modbus Conformance test is designed for Modbus TCP Ethernet devices, not Modbus Serial devices. To test a Modbus RTU Serial device, you must use a gateway that can connect your Modbus Serial device to a Modbus TCP Client. Any Modbus Router can be used for the test, …