Add-On Instructions (AOI) in Logix – More Tips

A customer asked me a question this week about Add-On Instructions that I had not considered before. I’m still struggling to see how you might deploy it and would love your input.

Add-On Instructions can call other Add-On Instructions in their routines. In other words you can nest AOIs and you can nest them up to seven levels deep. For the official documentation on AOI usage look at Logix5000 Controllers Add-On Instructions (Publication 1756-PM010C-EN-P) in Rockwell Automation’s Literature Library and refer to page 22 for information on nesting. To quote the manual, “This provides the ability to design more modular code by creating simpler instructions that can be used to build more complex functionality by nesting instructions.”

If you are not familiar with AOIs you can find several examples in the Sample Code Library. There is also an Add_On_Instruction_Samples.acd program that gets installed with RSLogix 5000 that you can access from the start page under Controller Projects then Open Sample Project.

I just can’t really picture a situation where it would simplify code to use this nesting technique. If anyone wants to help educate me and the rest of the readers please comment below or shoot me an email with a RSLogix 5000 project using this technique if you like. I will append this post with the advice.


About Doug Brock

Doug Brock has a broad range of factory automation and wholesale distribution experience and is an expert on the application of the Baldrige Criteria for continuous improvement efforts.
This entry was posted in Controllers and Accessories. Bookmark the permalink.

6 Responses to Add-On Instructions (AOI) in Logix – More Tips

  1. Lee White says:

    You’re right AOIs are a welcome addition to RSLogix 16. They provide the ability to generate user defined instructions (AOIs) with sufficient indirection for a higher level of programming abstraction, modularity, and encapsulation.
    Abstraction – No longer must one think in terms of individual bits of functionality when laying down complex code. Now, he can bundle all logic into a single, opaque, instruction (AOI) to represent an entire S88 equipment (or control) module. This makes the implementer more effective by not being required to think accurately in terms of individual bits and such. Now, he (and even a junior engineer) can lay down entire 2-state modules, AI modules, and other higher abstractions.
    Modularity – The introduction of AOIs allows one to deliver functionality that can be tested in isolation, implemented by the thousands via spreadsheet and L5K import, updated project-wide without replication error, and reused in later projects (for different customers).
    Encapsulation – Best of all, AOI usage allows a senior developer to generate complex abstractions and hand them off as black boxes for a more junior guy (ie: lower cost) to lay down for implementation.

    The above concepts are working tenants of classic programming design which allow developers to work smarter by implementing at ever increasingly higher levels of abstraction (standing on the shoulders of giants is a nice analog here).
    From a programming standpoint, the depth of implementation “nesting” is related to how well a developer (or team of) can decompose and express a solution in digestible, testable, and reusable chunks of code that will save time (development and testing) in installation, startup, and future project work. Rockwell AOIs provide that.

    Drawing a direct parallel to classic programming (C, C++, Java, C#, etc…), we can claim the construct of a Rockwell AOI as being logically and functionally equivalent to a C-Style function call. Classic programming languages have as well nesting limitations of method calls which are imposed by the stack height (reserved memory for the stack) of the target process scheduler. The nesting limit in these classic programming languages is a direct function of how much data gets pushed to the stack for each method call.
    Drawing a separate parallel back from classic programming, we find the reason for a nesting level depth limit of Rockwell AOIs is directly related to the stack height limitations in the target ControLogix processor (used to parse these AOIs). This stack height limitation, although seemingly arbitrary (at 7 deep), is based the firmware developer’s requirement to maintain reasonable scan rates in worst case processing conditions and still provide a reasonable maximum data width of a single AOI, reasonable maximum number of scheduled interrupts, and the max number of parallel tasks.

    In building a working automation framework (in RSLogix) using AOIs, I haven’t hit the nesting depth wall (7 deep) when creating higher abstractions such as complex equipment modules, but I have created such AOIs with 4 levels of nesting: an outer wrapper, with inner finite state machine, with inner bit ratchet, with inner numerical manipulation.

    Hope this helps.


    Lee White

  2. Greg McCormack says:

    Yes I love AOI’s and intelligent programming… The biggest thing that lets this software down though ( and it’s competitors to smirk ) is the fact that you can’t make changes to AOI’s on a running processor – you have to make the changes offline and download the whole code again. ( as of Dec 2014 )
    I want this code to rival Siemens – but sadly Siemens despite it’s complexity and lack of assistance to the programmer still has two main advantages :-
    – You can modify Functions that are used multiple times AND
    – You can do partial downloads.

    If Rockwell could sort editing AOI’s online – it would be where it deserves to be – AT THE TOP of the pile.

  3. Greg McCormack says:

    You asked about nesting AOI’s …

    I have a controller block called “Ctr1” and it acts like an envelope containing two lower order AOI’s – one is a standard PID loop and the other is a “MoveAndWait” control. Both lower order controllers need to be enveloped in logic that delivers either an External Setpoint OR an Internal Setpoint and the enveloping software can deliver ramping and other functionality. There are just two rungs calling the lower order AOI’s – and a —[ ]— and —[\]— to toggle between them.

    Yes you could have done separate “Ctr1” and “Ctr2” AOI’s but that doesn’t allow easy switching between the PID and the MoveAndWait.

  4. veco says:

    AOI’s suck, just over complicating things that are not complicated

    • Doug Brock says:

      Some people would disagree. The good news is you can choose to use AOIs or not. They are just another tool in the programming toolbox.

Leave a Reply

Your email address will not be published. Required fields are marked *