ControlLogix AOI versus Subroutine

Thanks for posting the follow up, great food for thought!

williamlove said:

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.

Click to expand...

Sorry for late followup.

In this instance it seems very basic, and if I were sitting in your shoes I might consider any AOI as well. However, if I knew the sequence might be changed or tweaked for some reason or another I would be hesitant to use an AOI.

From a program perspective, I've had similar challenges with batching applications. I have had to edit the 'same' subroutine logic in 200 separate programs of a PLC while commissioning. While a bit tedious I simply couldn't stop the PLC because of systems that were running production. It had to be done online or wait until 3rd shift over the weekend.

While tedious, it was simple copy & paste. Because the subroutines used local program tags I could modify the logic in program #1, verify it worked properly, then "Select All" of the rungs, copy, move to program #2 and paste over the old logic all the way through. Some of those program tags were aliased to controller scope tags to link my IO. So as the logic was copied into each subroutine, the alias definition automatically updated. A bit more time to update your program, in this example 200 programs probably took a good 15-20 min depending on how fast the edit could be accepted. But gave me all the flexibility I needed.

Again not saying one way is better than the other, all depends on the project and risk associate with it.

Content deleted, please see next reply.

At first I didn’t understand your answer because it didn’t seem an advantage to have separate programs over separate routines. If you read my comment in an email it probably changed over what you see here.

That’s because after I thought about it I realized that being able to reuse logic with the same (local program scoped) tag names is an advantage.

But right now my AOIs have been accepted. I have established a convention of putting a rev number on the AOI name e.g. Mold001 and incrementing it when I have to edit online. ("Edit online" means open up another instance of Logix, make the change, import the new rev Mold002 into the online instance, and change all the calls to be to Rev002 instead of to Rev001. Everyone in the group knows the rev with the highest number is the latest. When we have a chance to download we will delete all but the latest, change the name back to Rev001, and download. That's to keep the clutter down.

I think my next choice would be the classic subroutine with indexed indirect addressing.

If I just have to see the logic for each instance (instead of the blur of a common subroutine) and if I was forbidden to use AOI, then I would try your method. So thanks for explaining it.

Hi William, that's a nice approach for online changes to AOIs. I like them a lot, especially the ability to monitor individual instances. But so far I've been constrained to using them in "stop-start" individual machines where nobody cares about stopping the controller. This look like a good workaround for live changes.

UPDATE: After doing my startup I'm sorry to say I can't recommend AOIs for any logic that you even just might have to change under pressure. It’s too bad because it is a true subroutine and is perfect for duplicate units since you can watch an individual instance run and troubleshoot. But without being able to edit it online you might get in a jam....I did. Even simple stuff like a motor start routine is risky because if you have to flip the estop bit or add a permissive or do anything, you are screwed if you can't download. It was too late for me on this startup, it was too much work to convert the AOI to an alternative. I suffered for it on the startup.

It’s worth pointing out, I am going to double the number of units (molds) and with the AOI still in place I only have to change an array subscript and do a few other things. So it will really show its value there. But nobody else really understands or cares and I now have a reputation as being an elitist programmer too eager to try esoteric stuff when in fact I am just trying to write good programs. Until I can edit the AOI online I will not put complex logic in an AOI. By complex logic what I really mean is anything I might want to edit online under pressure, like during production.

Agree.
AOI's are fantastic for small bits of code that never change. I use them for my motor starter logic, and MOP's, and such, but never ever ever in place of an editable control subroutine.

I enjoyed this discussion. I struggle with this all the time because of 2 things: can't edit online quickly... and I never know who will have to figure this out after I pass it on.
But some things are just screaming to be encapsulated.

I only use AOIs for code that is standardized and doesn't change, for example; the company calendar (period/week/day/shift), and a logic clock, which operates independently from the built in wall clock. I do pretty much everything else with subroutines.