ControlLogix AOI versus Subroutine

williamlove

Member
Join Date
Jul 2007
Location
phoenix
Posts
59
I have been using AOI instructions as true subroutines. They have transformed my programming practices since I started doing that a couple years ago. I never used subroutines before, except to organize code. I never passed parameters. I just modularized my code and called them with JSRs that had no input conditions on the calling rung and no parameters.

When I learned AOIs I used them as subroutines. I liked the local variables not cluttering up the tag database. Most of all I liked only having to edit logic in one place. I could not quite figure out how to get the same thing out of subroutines with parameters, so I continued to use subroutines only to organize code.

Recently Rockwell has claimed subroutines have been improved with the addition of parameters.

AOIs have proven to have everything I need for modular programming. But they don’t allow online editing.

Will someone experienced with both please compare using an AOI with the new parameter capabilities of subroutines and tell me if the latter can do everything an AOI can? If they can, and if they allow online edits, then I should probably stop using AOIs for everything and switch to the subroutines.
 
Last edited:
Personally, my opinion is that an AOI should only be used for logic that needs to be instantiated over and over. Anything else should be subroutine, or a new program.

My AOIs are device level (typically)
- Valves, Motors, Analog Transmitters, Analog Control valves...etc.

Some AOIs I have created are for complete math operations.

This way, my AOI logic is "tried and true" and only needs modification to add additional features. All other logic that is created may need to be maintained and "open" to engineers and maintenance for online editing.

Doesn't make sense to me to ever create unique code and package it into an AOI if there is only a single instance of the call. I don't see the benefit of it. I usually am working on very large systems, and it's simply too much risk to encase logic in an AOI which I can't modify online.

Can't comment on the parameter features.
 
I am asking for someone experienced with the new features of subroutines (parameters) to compare it to the functionality of an AOI. Is there anything one can do that the other simply cannot? It appears on the surface that the new subroutine capabilities might actually match the AOI and if it also allows full online editing of logic it would exceed it. But I'd like to know if any of you have actually tried both and can compare them?
 
I am pretty sure that you have been able to pass parameters to subroutines for some time.
The benefit of an AOI over passing parameters to a subroutine is that the AOI is instantiated, & therefore each instance logic can be monitored.
Is a lot more difficult to do that with a subroutine that is called multiple times.

Of course, this is based on using an AOI/Sub with parameters for relatable code as Paullu says.
Using an AOI for unique code defeats the purpose of using it, IMO.

But, a subroutine can be edited online...
 
Hi

From Version 24 you are correct as routines do have a new way of passing parameters.
Before you would have code for let's say a valve. The code would handle the opening,closing,alarms etc for one valve at a time. You would use the jsr to pass the parameters into the subroutine for each valve and then the jsr would return parameters. This was very good to write but not always easy to trouble shoot.
You could change the code online But was not easy or possible if an array had been used.
An aoi in my mind is the like this but not the same. Along then comes version 24
And I have only used this new Parameter passing twice so this is how I used it.
You right the code in a rountine for your area , station of a machine etc, I would not use it for a valve or a motor. You can have local tags, global tags and now tags that only another routine can connect to. In the local tag database you can now connect tag to other tags like inputs. It very useful if let's say you have 5 tanks and each has a level sensor, a valve or a number of valve , a pump etc
You can create the code for one and then test that and then copy, past and then just change the connections to your I/o, scada etc. Now you can change each tanks code if needed without affecting the other 4 tanks. I still use my valve Aoi
With in this system

I will see can I gat a link to ab site fo Some better explanation

Donnchadh
 
You will find a comparison of Subroutines and Add-On Instructions in Logix5000 Controllers Design Considerations manual (1756-rm094_-en-p.pdf), page 48 and 49.

Similar information can be found in TN 50182 Subroutines vs. Add-on Instructions (Access Level TechConnect).

Also, TN 41744 RSLogix 5000: Online Editing for Add-On Instructions (Access Level TechConnect) explains how to edit an AOI online using Partial Import Online.
 
I looked at that TN 50182. It does not really answer my question although it hints at subroutines not quite being as good as AOIs. I say that based on the two rows called "Data Encapsulation" and "Execution Performance" which seem to suggest (to me at least) that the AOI still is better. I have to admit, I can't quite grasp a true answer to my question from that chart; I am still going to use AOIs for now. (Also I have to say, the partial import workaround to online editing is not satisfying because you have to name the new AOI something else and cannot delete the old one. That leads to clutter and confusion and sloppy practice...like when old copies of ACD files are left in the folder with the latest.)

I came away from the chart thinking there is something still inferior about subroutines, but I have already admitted I am not sure. I do know that AOIs and UDTs have transformed my programming, making my programs kind of object oriented and I have gotten lots of good feedback. Interestingly, the Design Considerations document seems outdated...the chart on page 49 in particular (compared to the one in the TN).

A couple of comments made about when AOIs and subroutines are appropriate to use is off topic (although I thank you for your time anyway). Sometimes AOIs and subroutines are appropriate and sometimes they are not but I'd like to avoid that matter in this thread. This thread is meant to be a comparison between AOIs and that latest subroutine technology in Logix. I don't have a system to work on at the moment. If I did I'd investigate and post the answer.

The answer I'm hoping to get is a "here's the real scoop...". I was wishfully seeking a kind of compare and contrast statement similar to what I’d give if I knew the answer and was telling you in a conversation. I'm hoping to avoid wasting time with subroutines if they are still somewhat inferior to AOIs (which is my perception now).
 
"The real scoop" - It's to new of a feature for anyone to have practical experience at this point. You're asking for a clear answer and I doubt it exists, at least on this forum. Your method of packing everything into various AOIs is a bit out-of-the-ordinary, so trying to understand exactly what you are trying to discern is a bit of a challenge.

I'd like you to make it clear in your comparison, aren't you really trying to compare a Program to an AOI? Seems more appropriate since Programs provide tags and logic which can be created in a modular fashion. Where as routines are simply just logic, granted you can pass "parameters" in and out.

As far as the new Program Parameters feature, it simply reads to me as a method for a Program to interact directly with another Program and provide a method to map data in a similar fashion as an AOI. Previously you had to use controller scoped tags to allow programs to interact with each other since "program scoped tags" are local to the program. Of course, creating a "program scoped tag" and aliasing it to a "controller scoped tag" gave you a method to take advantage of the benefits of program tags while allowing the global interaction of controller scoped tags. My interpretation of Program Parameters simply allow you to bypass the need for controller scoped tags. But perhaps you will consider this off-topic since I don't have practical experience with it yet.

Here is a lab I found, review lab #3. Maybe it will help you in your evaluation, maybe it will not.

http://www.rockwellautomation.com/r...otm/sessions/manuals/L18-RockwellSoftware.pdf
 
Paully, thanks for your time. But the answer to your question in the second paragraph is no. I'm asking for a comparison between routines and AOI, not programs and AOI. I will thank you again for your opinions and information but I am still hoping others will take a crack at it. If no one can do that I will try it myself when I have a system to go online to, and I will post the results.
 
I said I'd update this if I actually tried it out on a live system and I have.

This discussion pertains to a situation like having 20 burner sequences and you want to write one routine instead of 20 routines.
The choices are:
  1. Write twenty routines with direct addresses.
  2. Write a subroutine and use indexed addressing.
  3. Write a subroutine and use parameters. This is what I was asking about when I started the thread.
  4. Write an AOI.

1. Twenty direct address (i.e. normal) routines: Has a big advantage over indexed or parametrized subroutines from the standpoint of watching logic…the rungs mean something. Has an advantage over AOI in allowing online editing. The big disadvantage is the time to create and maintain twenty routines. And what if it was a hundred? For me if there’s more than 3 to 5 I’m not going to maintain separate routines.

2. Indexed Addressing: I did this twenty years ago. You call the routine with the index set to one, then increment the index and call the routine again, then again until you’ve handled all the cases. The good thing is that it is very simple. The bad thing is that you can’t tell what’s going on by watching the rungs like you can for normal logic. You also can’t have local variables that have to persist (think timers and one shots) so those have to be indexed too.

3. Parametrized Subroutines: When I started this thread I was under the impression this might offer functionality as good as the AOI. I have concluded that is not true at all. I spent two days investigating and actually testing with logic on a live system. I find it inferior to the AOI. I also could not see much advantage to using this instead of subroutines with indexed addresses, except the addresses look a little cleaner. But you still can’t troubleshoot a single case by looking at the rungs because all the cases are a blur. One of the biggest problems I had was one-shots and timers. I concluded if I was going to use this method I’d pass a structure in. I might be inclined to just use the indexed addressing method. Let’s not argue; it’s a matter of taste to some extent.

4. AOI: Two advantages. One is you don’t have to be as careful about local variables which are common to all cases. Like ONS addresses. That’s because local variables are never common to all cases. Timers and one-shots work as expected without any extra thought. The other advantage (the BIG advantage) is that you can watch the logic for a given case. I have twenty burners and I can watch the logic for burner five just as easily as I could if it were in a separate routine. But I can’t edit it. That sucks. I hope that changes.

And I hope I helped others evaluate this set of choices. 🍺

There is a workaround for online edits for an AOI…importing changes with a different name. You can’t rename it or delete the old one online. So it still sucks compared to online editing and creates clutter until you clean up offline and download later. But it will get you by if you must edit and simply cannot download.
 
Hello, me again :rolleyes:

First thanks for posting an update to this, it's always appreciated when things come full circle.

How come you haven't compared to using multiple Programs? You reference subroutines, then parametrized subroutines. But a program is more comparable to an AOI in what you're trying to accomplish. And from my understanding, Programs have the new parameter feature, not subroutines. Subroutines within a program of course can use that feature....I'm just trying to align my thought process with yours.

Moving on, and this is just for additional discussion points, not trying to say one way is better than another.

I've done various batching systems, doing much of the same repetitive logic. It's essentially identical, but references a different batch tank. Not any different than your burner situation. Each is a unique sequence per batch tank. Say I need a sequence to add a raw material to the batch tank, the sequences are the same, the local tags are identical, the only real difference is how they are linked to the physical IO. To me programs and AOIs are extremely similar with some obvious differences. AOIs can be instantiated where programs can't. Programs can have multiple subroutines, AOIs can't. Programs can have online edits, AOIs can't.

Programs are just as modular in my opinion. Create 1 program test it out, export it to a .L5X file, import back into the logic and change the references to program 2, 3, 4...etc and boom you have your additional logic. Sure it's a few more steps than calling an AOI, but seems like a better option to maintain online edits rather than importing new AOIs to "sort of" accomplish online edits. At that point it's just personal preference I guess.

If your equipment is not identical, you can easily make minor changes to account for it in the program rather than having to crate another type of AOI, or allowing your AOI to have some type of configuration bits to activate/deactivate portions of logic based on the variance.

Certainly there is an amount of complexity in the logic to consider. In batching, the need for organized subroutines are required to keep all the logic sensible where as within an AOI you don't have this option. But hey if the logic very simple then the advantage of additional subroutines in program are irrelevant.

I hope you did't mind my additional talking points.
 
Paully, I will explain my system as briefly as I can before I ask a question pertaining to your response. I hope you will read the description; but the question is clearly separated in the last paragraph in case you want to go straight to it.

My process deposits a special slurry and sand on a wax impression to build molds. The logic sequence is the same for each mold except for the choice of which dip tank, which sander (a carefully drops sand on the part as a robot moves the part around inside the drum), and the dry time. While most molds are drying one of them gets dipped and sanded. A mold can have up to 50 dips although most get dipped, sanded and dried about ten times. Up to twenty (20) molds can run in the system at one time. There is shared equipment…notably the robot and the conveyors with hooks that store the molds during various stages of dipping and drying.

It is the dip sequence that I have put in a subroutine/AOI. The dip sequence is set of steps. One of the molds is actively stepping through one of its dips. All the other molds are in the long drying step of one of their dips. All those sequence are active; it’s just that one is changing more while the other 19 are running a long timer in their last step. Whenever the robot is free, it means one of the molds that are done drying can claim the robot and start another dip. The dip number of that mold is incremented and the subroutine/AOI goes back to the first step. The only time the subroutine/AOI is dormant is when there is no mold.

The AOI is perfect because I just pop one down. It works great and people acknowledge the power because they can watch it execute for a given mold. Most importantly, I only have one routine to edit.

There may be an expansion to where up to 50 molds will exist.

I am trying to understand what I can do with a Program organizational unit to have a subroutine that I can call for all twenty (or fifty) molds without having to edit all of them whenever something in the dip sequence needs a tweak. If you can explain that, I’ll admit I didn’t grasp it, and I will go try it out (on a mockup example) this coming week. But if it requires maintaining twenty (or fifty) programs, it will not work.

Thank you.
 
Certainly all of the merits of using AOIs verses subroutines you pointed out can be considered valid but I can tell you in the industry I serve (automotive), its frowned on to use AOIs in place of subroutines or programs precisely because they can't be editted online.

Once, even when I used a AOI as a custom instruction to control air cylinders, a customer asked me to do it "discreetly" because the staff supporting the line didn't feel comfortable not having the ability to make changes without a lot of hassle (starting and stopping the PLC or replacing the AOI with a new one). So, in place of each instance where I used the AOI, I replaced it with discreet logic in a subroutine. A subroutine for each air cylinder. Yeah, memory usage went up but the customer didn't care as long as it fit and he had simple access to the logic.

More often then not, the K.I.S.S. method is what the customer wants.
 

Similar Topics

Hello, I was wondering if anyone has a ControlLogix block or routine for encoding and decoding base64. I figured I would ask before diving into...
Replies
1
Views
247
Hi Guys, I just wanted to ask regarding to an error that we got troubleshooting the PLC system. Everything is working well then we tried to add a...
Replies
15
Views
5,319
Hi Guys, I just wanted to ask regarding to an error that we got troubleshooting the PLC system. Everything is working well then we tried to add a...
Replies
0
Views
995
I've worked on a handful of projects that relied on a Prosoft module for Modbus comms with other systems (older PLCs, boilers, chillers, much...
Replies
5
Views
2,116
My company imposes programming standards and insists on using AOIs for AI, AO, DI, DO points. I like AOIs and use them as subroutines when I have...
Replies
10
Views
2,997
Back
Top Bottom