Developing Allen Bradley AOIs (Add on Instructions)

[Chris Elston 78]

I would like to create an AOI that is mapped to some local I/O and Ethernet I/P address bits. If my AOI is to be reusable (imported from PLC to PLC), there could be a chance that the Ethernet I/P addressing would be different in each PLC. Someone would have to go into the AOI and map the I/O that is used in the AOI. What's the best practice to map Ethernet I/P I/O mappings to your AOI? Can anyone give some pointers? I have an idea how to do this, but I am not sure it's the best way. Just wanted to poke your brains and make sure I did not miss anything in the AOI configuration and creation stage. And...I do know that Add on Instructions are "not intended for outside access" or Allen Bradley uses the term "Encapsulation". I want to sort of kind of...break the "Encapsulation" concept of AB. Edited 23 Nov 2011 by Chris Elston
added a few more comments...

[b_carlton 61]

Make the changable items input or input/output parameters. The internals of the AOI are meant to be the non-changing factors. If the information is a large group of items then create a UDT with that structure. Gather all the relevant information into a tag using that UDT then pass the tag as an input/output variable. That makes all the information the AOI needs in one item. Edited 23 Nov 2011 by b_carlton

[Chris Elston 78]

I was looking at one of the AOIs AB made, I think I see they called I/O "references" and are mapped at the top of AOI, then "commands", etc...Why not follow their model, since they probablly know the best method I assume. Here is a screen shot of an AOI AB made.

[b_carlton 61]

While this is just one instance of an AOI it is best to open the definition of many and look at the structure of the parameters and the logic. The order of the parameters you see depends on the order they are entered in the definition.

[Chris Elston 78]

Yes, I have laid out all my parameters on a 6 foot x 4 foot white board. I am good to go! I might have answered my own questions by looking at other examples and concepts of how others have designed their AOIs. There seems to be different styles of how folks design things, just like writing ladder logic, so I was trying to understand if the method I had come up with was something that would make sense to others and follows the same (or best layout) of how others designed AOIs. Thanks for the feedback.

[daba 4]

Chris, just remember what AOI stands for Add-On Instruction - Instruction being the operative word. Try to forget that the AOI is "just a subroutine", it isn't, and don't be confused that they are programmed in the same way (Ladder, FB etc.) as the rest of your code. Think of an AOI just the same as any other instruction - like a Timer for instance. When you program a timer, it asks you for a tag, of data-type timer, that the instruction will work with. The tag contains all the data-storage needed to make the timer work. An AOI is just the same - you create the AOI with the parameters that you want to use with it - if the AOI needs access to I/O, then add the I/O points you need as parameters. The AOI creates it's own UDT, you don't need another. Then when you put the AOI in your code, that is when you have to supply the actual I/O tags. Edited 25 Nov 2011 by daba

[bouws 1]

One thing that frustrated me until I figured it out... Input or Output parameters can only use BOOL, SINT, INT, DINT, REAL data types. If you want to pass a STRING, UDT, or something else you need to use the InOut parameter.

[Chris Elston 78]

Ok I got one question. I haven't designed alot of AOIs but the one I am working on right now is about 23 rungs long. It sequences through I/O and has to wait on a some servo motor's to start moving, moving, then stop. What is the general perspective from you guys who use AOIs to keep the RUNG TRUE until it's done? I created an InCycle status bit, then I latched it around the "start bit". Would that be normal if I released an AOI would you as a programmer do that to make sure that the AOI fully executed? It doesn't hurt my AOI that it's not held until the DONE bit is complete, but it creates an error, which when the AOI goes false, the error won't come out of the instruction because it's false. I could put it in the enablefalse, but my main question is... When you use AOIs, do you just latch the AOI on the outside to ensure that the AOIs completes? Or should I redesign my AOI that if the rung goes FALSE, before the AOI is complete I should handle that inside my logic? Just wondering what you guys thought.

[b_carlton 61]

Another approach is to have the AOI generally enabled (System Is On) and have the start of THIS PARTICULAR use, like the axis move, be triggered by setting an IN BOOL variable, presumeably on a rung just befor the AOI instance, to maintain the visual connection. Edited 29 Nov 2011 by b_carlton

[Chris Elston 78]

So your saying something like this concept?

[b_carlton 61]

Yes, though I haven't done a lot of AOIs so you may want to take it with a grain of salt. But the programmer is used to keeping certain instructions on, think timer, and, if necessary, providing a latching condition if the initiating condition is momentary. The main thing would be the documentation detailing the need, if it arises for this and the consequences of only momentairly enabling the AOI.

[Chris Elston 78]

Your thoughts here are my concerns. I am trying to design it to make the easiest sense to most. It's easy to write it 100 different ways, but I didn't know if there was a general "crowd" or "bandwagon" that everyone is following a certain concept of how an AOI is designed and it behaves. Having two rungs bug me... But not having it latched is far worst. Having it enabled all the time is good, but wouldn't be required. I also like the thought of it NOT scanning all the AOI if false. Maybe I will just go down the documentation road....and make sure it's documented to latch the AOI when executed and wait for the DONE bit back.

[daba 4]

I would prefer to see the self-maintenance with the In-Cycle bit. But you also need to consider the logic states within the AOI code when the rung is false. When you configure the AOI, you have the option of executing a different routine if the AOI rung is false (Enable-In False Routine). This may be useful to you. See the "Scan Modes" tab of the AOI properties dialog. You may be getting a bee in your bonnet about executing the AOI all the time... Does your application really require the marginal scan-time gain you might get - compared to the more simplistic code you will end up with? I guessed you are perhaps trying to build your "sequence" from AOI's - and while I can "sort of" see your thinking, I've never considered that concept before. Having said that, I can see similarities with the motion instructions in ControlLogix, so perhaps your ideas aren't so off-the-wall. Interesting to see how it develops.... Edited 29 Nov 2011 by daba

[Chris Elston 78]

Correct, I am trying to make the AOI the same behavior as the Motion Instructions, because basically it is a motion instruction. If everyone is conditioned at using the built in instructions, then mimicking that will make mine easy to understand. But I assume, in the AB motion instructions, if the AOI goes false before the motion is complete, I assume the axis still completes it move, so that's where I am stuck. It takes a bit once the AOI is executed for motion to start and motion to end to send a confirmation back to the AOI has completed. If motion is started in my AOI, then the rung goes false, the motion will complete, but then the "complete" status doesn't come back to the AOI because it's false. That's what I am struggling with is the concept of designing it so to make the programmer have my AOI true all the time or design it where once it's started executing, handling all the house keeping like you say the incycle bits. etc. I have attached the logic, the enableinfalse, and the tags of what I have right now. Basically I am going with a SEQ style in the AOI, because later on, I want to add some error trapping, and I need the SEQ to handle the communication hand shaking between the PLC and servo drive. I would like the AOI to behave the same way as an AB motion instruction, and I have tried to model after what Allen Bradley has already posted in their sample code library to keep their standards and my standards the same. aoi-logic.pdf aoi-enableinfalse.pdf aoi-tags.pdf

[ControlsGirl 2]

Did you learn how to program in a scripting language like C before ladder. I am just now getting into writing AOIs and I instinctively want to use them like a call to a function in C. I only execute it when I need to. However, I just spoke with some older controls engineers at my work and they say they like having it always enabled with some kind of bit that passes that initiates some function within. I guess that is where ladder is different. You can stop the process of an AOI be disabling it, even in mid cycle. In normal scripting, it executes to complete before jumping back into the rest of the code. I just had an "Aha!" moment