Transferring 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 the target to transfer 10K of data, as you might, if you want to move an image, a block of energy data or a file of quality data on some raw material, it’s a lot more complicated.
If you called me about this, the first thing I would say to you is that you are using the wrong protocol. EtherNet/IP is an I/O protocol – that means that it is designed and optimized for moving small amounts of data between a factory floor I/O device and a controller. It’s not designed for moving large data sets around. You might want to consider FTP or a similar protocol designed to move large numbers of bytes around.
But let’s say that your Originator already is an EtherNet/IP device. Your Target is an EtherNet/IP device and you really need to move that 10K of data to the Originator once a day or once or hour, or maybe intermittently. EtherNet/IP is what we have to work with, so how do we do it? What are the options?
Let’s start with some background. The Explicit Messages between your EtherNet/IP Originator and Target have to fit in the payload of an Ethernet TCP packet, which is around 1500 bytes. You’d like to think that you could use nearly all of that to transfer your data, and that’s pretty much true. The TCP Header is going to consume some of those bytes, and the Explicit Message Header is going to consume some more, but in the end, you’re still left with 1400 or more free bytes.
Great, you say, we do seven or eight messages and we’re done. That’s true if a PC or some other kind of device is your Originator. In that kind of EtherNet/IP Originator you can probably transfer 1400 bytes on every request and be on your way. Seven or eight messages we can live with every few seconds or every few hours.
The rub is that most EtherNet/IP Originators are not PCs or other devices with the capability to send and receive large EtherNet/IP messages. Instead, most Originators are Rockwell ControlLogix or CompactLogix PLCs. The packet size for these devices is limited to a paltry 500 bytes. With only five hundred per packet, we now need twenty explicit messages to get that 10K data of data transferred.
And we also need some way of organizing all these messages and responses. Most of the time the receiver is going to want a sequence number or packet number to know that they’ve received each packet in the sequence. Our Originator can stream all twenty requests out at the same time, but some might not arrive. They should be in the right order; the IP protocol takes care of that, but we have to have some mechanism to deal with missing packets.
Another requirement for this to work is that the vendor of the Adapter device must provide a service code and a higher level application layer that allows the Originator and Target to initiate the transfer and manage any missing packets. There are lots of ways to do this, but this kind of data management is not built into EtherNet/IP. The vendor of the Target device must provide it and the Originator must conform to it.
There’s lots of ways a vendor can handle large data transfers, but the two things to remember from this article are that 1) EtherNet/IP doesn’t provide infrastructure to manage transfer of blocks of data using Explicit Messaging, and 2) PLCs have limited buffer sizes for receiving large blocks of data.
In the next article I’ll discuss how you can manage transfer of large blocks of data in an I/O message.