EtherNet/IP AOI vs. AOP

I’ve always complimented Rockwell Automation for simplifying how PLC programmers can connect a PLC to “foreign” (non-Rockwell) EtherNet/IP™ devices. The Add On Profile (AOP) functionality makes it very easy for a PLC programmer to define the EtherNet/IP™ assemblies as a series of tags to use in a PLC program. Before V20 of RsLogix, programmers had to move bytes from the input assembly to a tag of the data type for the data.

For example, let’s assume you had an EtherNet/IP™ energy meter and bytes 4 to 7 of the input assembly contained voltage A as a floating point number. You would have to write instructions to move those 4 bytes into a floating-point tag before you could process the voltage A value. And, before writing these instructions, you would have to dig up the meter documentation to find where voltage A was stored in the Input Assembly. You’d have to do this for every field of the input assembly and every field of the Output Assembly. Very “icky” in ladder logic programmer jargon.

But with an AOP, your EDS file documents all these fields in your assemblies. As the ladder logic programmer, you have access to all of that data as tags. No more chasing down some spurious, old revision documents to try to discern these values. No more copying data to get it named, or in the best-case scenario, naming the data in the assemblies.

That’s a great feature, and I have advised every single one of our EtherNet/IP™ Adapter source code customers to get an AOP. Rockwell has to approve it, but I can honestly say they’ve been very fair and very helpful about the approvals. Their team has been a joy to work with.

Recently I’ve heard some grumbling from customers and RTA’s engineering staff that AOPs aren’t the way for customers to go. That AOIs (Add On Instructions) are the right way to do this.


Let’s start with what AOIs are. An AOI is an Add On Instruction (AOI). Vendors can now create their own instructions. It’s another cool add-on from Rockwell (actually it’s been there since RsLogix V16). If you, as a PLC programmer, create some nifty code, you can lock it up in an AOI, and your customers and your competitors will never know what magic you’ve implemented. Very nice for system integrators who have intellectual property to protect.

So, the question is, why would a device vendor, say a robot manufacturer putting its robot on EtherNet/IP™, use an AOI? There are a couple of reasons.

If there is special processing of the data the robot is sending back to the PLC, and the PLC programmer is going to use special processing in several different parts of his PLC program, then an AOI is applicable. Especially if that processing is a trade secret kind of code. Or an AOI would be applicable if the robot could respond to commands. You may want to build an AOI called “Start Robot” which encapsulates commands or special data needed to send to a robot.

In general, an AOI is about programming. It’s about simplifying programming code or hiding code from prying eyes. AOPs are about defining data fields to be easily used.

These two things couldn’t be more different, but I find a lot of people confusing the two. Rockwell gave us two very useful tools for building manufacturing applications, but maybe they could have named them something else. AOI and AOP are just way too closely related. The functionality is somewhat related, and the names add fuel to the confusion. But now you know the difference and can help me set people straight.

Life for all of us in the AB PLC world will be easier without this confusion.