Architecting an EtherNet/IP Device

I’ve always liked surprises – good ones, anyway. An interesting business opportunity that I didn’t expect is a nice surprise. The chance to visit some faraway place is a nice surprise. I’m pretty easy to please – surprise me with a nice piece of cherry pie and I’ll be your friend forever.
Bad surprises, not so much. And I hate to give them out: “Yeah, that project we said we’d finish next week? Well, a couple of months is more realistic. Next year for sure.” That’s no fun.

I do surprise customers regularly with EtherNet/IP. They are always wary of how difficult the process of integrating EtherNet/IP into their device is going to be. I always surprise them by telling them that the software integration is the easy part. Once we deliver the software, a device can be acting as an EtherNet/IP Adapter in as little as an hour or two.

There are only a couple of things to do. One, you have to create a task for EtherNet/IP. That task needs a way to measure time – not clock time, just elapsed time. It has to determine when to send Input messages back to a Scanner, and when the communication channels time out. Since most embedded devices don’t have a clock, a ticker count will do. Just create an ongoing tick counter that is incremented at a convenient rate (usually 1 or 5 milliseconds) and the EtherNet/IP task will use that for its time measurement.

Once the task is installed, it is ready to receive and process EtherNet/IP Explicit messages. These are the messages that a Scanner sends that explicitly request a piece of data from an EtherNet/IP Adapter device. With no other code from a user application, the EtherNet/IP task can respond to requests about the required EtherNet/IP Objects – objects that by specification have to be in every EtherNet/IP device. A Scanner can ask what the vendor ID is, what the software revision is, or any other of the required attributes from the required objects.

Building the Object Model

That software integration is the easy part. It’s totally mechanical and very straightforward. Once it’s complete, the fun begins: building the application Object Model.

Building the Object Model can be extremely easy or very difficult. It can require two minutes, or hours of real analysis and a lot of thought about how your customer is going to use your EtherNet/IP Adapter device. If you are building a very simple device like a pneumatic valve, there won’t be any challenge at all: 16 bits of inputs that deliver the valve state to the EtherNet/IP Scanner and 16 bits of outputs from that Scanner that set the valve state.

But that’s not usually the case. A few months ago I was working with a customer that has a data collection device. That device has a variable number of modules, a variable number of data points, and can change its configuration on the fly. That’s probably the worst kind of application for a tightly-coupled protocol like EtherNet/IP to handle (there are ways to handle it, and I’ll talk about that in a future article).

I have other customers in the marking business, and others in the printing business. Those are always exceptionally difficult to design. Our marking customer can deliver any kind of mark to the product. It might be simple text, it might be very long text, it might be a 2D barcode, or even a very complex 3D barcode. And sometimes that information might be several thousands of bytes. It makes for a very interesting and challenging day to figure out EtherNet/IP Object Models for those kinds of devices.
But I like surprises, and I really like how our team finds unique and innovative ways to solve these kinds of problems.