Add-on instructions (AOIs) enable programmers to design and create custom instructions for Rockwell Automation controllers. But can you trust AOIs? How do you know? Why use an AOI in the first place? These don’t seem like outlandish questions, so why don’t we dive into the subject and see what happens?
First, let me acknowledge that anyone interacting with the program—whether developer or maintenance personnel—will have to spend a little time learning how to navigate among the user-defined types (UDTs), add-on defined (AODs) and finally the AOIs. Let’s also discuss the need to properly validate an AOI. You must have tested the AOI thoroughly enough to trust that it reliably does the job for which it is intended.
I think most users of the Rockwell Automation ControlLogix family of controllers are familiar with UDTs. It seems to be common practice for developers to define UDTs to organize the properties associated with something that is repeatedly used within an application’s program such as locations or an ISA-88 unit or perhaps something as abstract as a Finite State Machine module.
AODs are a type of UDT in which the developer sets up a data structure for the respective AOIs.
The AOI is a collection of instructions that uses controller tags to instantiate the data structure of the respective AOD to accomplish a module of logic that is used repeatedly. One example can be alarms. Alarms need to notify people of their presence both visually and audibly. In addition, the operator interface needs to be given a message to display and log (prompt). Alarms must also allow the operator to both silence and acknowledge the alarm. That logic block and its tags must exist for each and every alarm that is in the system. It seems then that if we can develop a module of logic and tags that will always behave the same and avoid any chance of mistyping an entry, that would be a good idea. Enter the AOI. The AOI has a distinct appearance when it is used in a section of code within the processor. It is easily identified. The AOI is set up to have certain tags made visible and these serve to be the inputs and outputs that are available to the programmer.
There are also internal tags that can be configured to be accessible by the main application program for things such as human-machine interface (HMI) prompts. When programming each alarm, all the programmer has to do is enter the name of the AOI that he needs and then attach logic to it—much in the same way we deal with blocks of logic such as counters and timers in standard programmable logic controller (PLC) logic. We just can’t lift the hood on the counters and timers that are a standard part of the RSLogix 5000 instruction set. The AOI operates the same way except that it is incumbent upon the developer and user to validate the AOI so that they can absolutely trust how it functions. In addition, we can lift the hood on the AOIs that we develop in order to perform that level of testing.
You could get the same thing accomplished with a subroutine, but the big difference between the AOI and a subroutine is the ability to troubleshoot what is happening. Data moves in and out of a subroutine so rapidly that you can’t be sure which subroutine call you’re seeing at any given time. With an AOI, it is unique to the section of logic where it is instantiated.
In summary, I believe that the AOI is a very useful tool that can reduce if not eliminate error in dealing with highly repetitive modules of code. There is no reason to be afraid of them, but they do deserve respect and validation. When something goes wrong, it is natural to condemn the thing you understand the least. So if you haven’t invested enough time and energy to properly test the AOI, it will always be guilty until proven innocent.
Allow AOIs to be used. They are a great tool for modularity of code and ensuring accuracy of logic within them.
Ray Bachelor is chairman of the board at Bachelor Controls Inc., a certified member of the Control System Integrators Association (CSIA). For more information about Bachelor Controls, visit its profile on the Industrial Automation Exchange.
