Thoughts on embedding AOI's inside AOI's

I have recently been running across more and more Control Logix programs from vendors that are embedding AOI's inside of other AOI's. I have run into one instance where it was three levels deep. I am wondering if anyone has any thoughts on the Pros and Cons of doing this.

My initial thoughts are: 1. From a programmers standpoint it would probably aid in development time, implementation, and consistency.
2. From an end-user standpoint this is probably going to be confusing and will make it more difficult to maintain and trouble-shoot.

Thoughts...

Sounds like someone going a little overboard with trying to ensure future job security

I believe Siemens allows something like 6 to 9 levels deep in their FB's and FC's... shouldn't be a problem with AB, should it?

At the same time, the more standard a piece of code is, the higher number of proven hours it will have thus leading to reduced troubleshooting time.
One thing to keep in mind though is to keep track that the higher level works with a particular revision of the lower level AOI's and not assume this.

yes...

AOI is one of those thing that can help or hurt, depends on how it's used.

We have a system that came from one of the biggie engineering firm. Looks like one guy did the base programming and another did the site commissioning. The commissioning guy can't decipher wtf the original programmer was doing so he opt out of the AOI structure from time to time but, not all the time. Also, there's at least 2 AOI level deep. After years (yes, years) of trying to "fix" it, we ended up flushing most of the code.

I've said it many times: if you don't want 3:00 A.M. phone calls then program so Bubba and Otis in maintenance can read it.

That isn't to say don't use AOIs. A well debugged and tested AOI can be a useful black box in that all Bubba or Otis needs to understand is what it does and what inputs are required for it to function, they don't need to know how it does it inside. It can actually make is simpler for them since it reduces multiple rungs of code to one.

So when it makes sense, when it makes the program more readable, use them. But don't use them to obfuscate the code.

harryting said:

We have a system that came from one of the biggie engineering firm. Looks like one guy did the base programming and another did the site commissioning. The commissioning guy can't decipher wtf the original programmer was doing so he opt out of the AOI structure from time to time but, not all the time. Also, there's at least 2 AOI level deep.

Click to expand...

I think this is more of a problem of people not knowing how to use standards.

If you use Plant Pax, then you know it uses AOIs nested in AOIs. All the good points about well-tested code apply. The really big point for me is documentation. If you have good documentation on how to use the AOI, then you have very little reason to look inside. I still do, and am amazed at some of the code I see but I don't really have to. When I do look inside Rockwell's AOIs, I'm usually asking "Why" not "How" because the documentation covers "How" pretty well.

As other have said - if you do it for the right reason, it can be excellent.

If you do it for the wrong reason, it can be hideous.

Example A: Bubba gets asked to find out why Analog Valve A isn't opening. He cross references the analog output and finds an AOI called "CTRL_VLV" writing to that output. On the rungs above he finds the logic that controls the setpoint for the CTRL_VLV AOI and goes about his merry way fixing the issue. Inside the AOI, there is a nested AOI called "SCP" which is essentially just a series of arithmetic instructions to scale the 0-100% setpoint to a 4-20mA output signal. Also inside is another AOI called "FILTER" which dampens the operation of the control valve to prevent "slamming". Inside that AOI is another AOI which performs some complex math in ST to simplify the filtering ladder logic.

This is a good application, because Bubba doesn't have to see or really care about any of it. He understands that this block will take his 0-100% setpoint and convert it to a nicely smoothed 4-20mA. As to how it works, well, Bubba can dig more into that in his spare time if he wants to. For the time being, Bubba has tracked the analog output back to a setpoint being held at zero because of a faulty pressure sensor in two rungs and five minutes, all thanks to the fact that the programmer tidied all of the fine detail of how a valve needs to be controlled up into some nice neat nested AOI's.

Example B: Bubba gets asked to change the time that Motor A runs on after a widget is detected by Photoeye 1. Bubba cross references the output that droves Motor A and finds an AOI that controls the widget pressing sequence. He opens up the widget pressing sequence to find out how it controls the motors, and finds nested AOI's for each of the three widget production lines. Nested inside these AOI's is an AOI that does basic motor controls, like start/stop/overload/etc.

This is a bad application, because Bubba is now three layers deep inside the Matrix and is confused as hell. Not to mention, now he has to work out whether he can change the run-on time of this one motor within this one line within this one AOI without changing other motors/lines/widgets, and even if he can, he probably has to do a download to do it.

Horses for courses, as they say.

cardosocea said:

I believe Siemens allows something like 6 to 9 levels deep in their FB's and FC's... shouldn't be a problem with AB, should it?

At the same time, the more standard a piece of code is, the higher number of proven hours it will have thus leading to reduced troubleshooting time.
One thing to keep in mind though is to keep track that the higher level works with a particular revision of the lower level AOI's and not assume this.

Click to expand...

Siemens can actually do a nesting depth of 24 in some of their PLCs, which is way more than I hope to ever need.

As I understand it, the big trick here in handling nesting between Siemens and AB is how much a change screws up your active process. To the best of my knowledge, on the AB side, any change to an AOI requires the PLC to be in Program mode, which means downtime. In Siemens, you can make logic changes without any interruption to the process. Data structure changes still require stoppage (or very fancy work) though.

ASF said:

Example B: Bubba gets asked to change the time that Motor A runs on after a widget is detected by Photoeye 1. Bubba cross references the output that droves Motor A and finds an AOI that controls the widget pressing sequence. He opens up the widget pressing sequence to find out how it controls the motors, and finds nested AOI's for each of the three widget production lines. Nested inside these AOI's is an AOI that does basic motor controls, like start/stop/overload/etc.

This is a bad application, because Bubba is now three layers deep inside the Matrix and is confused as hell. Not to mention, now he has to work out whether he can change the run-on time of this one motor within this one line within this one AOI without changing other motors/lines/widgets, and even if he can, he probably has to do a download to do it.

Click to expand...

This is no longer maintenance though... It's a modification of a function and at times the reason why it is deep inside is precisely so Bubba can't change it willy nilly.
After working in a company that upheld (as much as they could) their coding standard and built functions with configuration "switches" (usually just a DB), I would rather see that than hard coding as it is far easier to troubleshoot, modify, etc... Not sure about PlantPAx, but PCS7 does this as well in their blocks.

mk42 said:

In Siemens, you can make logic changes without any interruption to the process. Data structure changes still require stoppage (or very fancy work) though.

Click to expand...

This is still what I miss the most working now in AB stuff. The whole online editing thing just doesn't do it for me compared to the simplicity of modifying the block and downloading it. Or... modifying a bunch of blocks offline, run a compare with the online to confirm these were the ones changed and download without stop of process (unless the code change had a problem).