AOI for I/O processing...real value? (ControlLogix)

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 code I'd repeat otherwise. Like twenty burners....they really deliver for stuff like that. But I can't stand using them for I/O handling. I've heard some companies actually try to block/ban their use and I can easily imagine why. They make it hard to find the actual I/O and maintenance people hate them. Maintenance derives none of the ostensible value they provide to ... to who exactly? I don't see their value for I/O. I use aliasing and SCPs, but I put those a rung with the aliased I/O clearly visible so we can FIND it. Yet people I respect use super fancy AOIs, sometimes with mind blowing levels of nesting and indirection. I think they're just showing off or enjoying the learning process ... at the expense of the end users and others. Thoughts? I'd like to present an argument against their routine use for standard I/O. One of the suggestions I've heard goes like this: Whenever anything is off widespread value without customization required, Rockwell will make an instruction for it. I've also heard Rockwell is abandoning the AOI approach to PlantPax and that seems favorable to my thesis.

williamlove said:

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 code I'd repeat otherwise. Like twenty burners....they really deliver for stuff like that. But I can't stand using them for I/O handling. I've heard some companies actually try to block/ban their use and I can easily imagine why. They make it hard to find the actual I/O and maintenance people hate them. Maintenance derives none of the ostensible value they provide to ... to who exactly? I don't see their value for I/O. I use aliasing and SCPs, but I put those a rung with the aliased I/O clearly visible so we can FIND it. Yet people I respect use super fancy AOIs, sometimes with mind blowing levels of nesting and indirection. I think they're just showing off or enjoying the learning process ... at the expense of the end users and others. Thoughts? I'd like to present an argument against their routine use for standard I/O. One of the suggestions I've heard goes like this: Whenever anything is off widespread value without customization required, Rockwell will make an instruction for it. I've also heard Rockwell is abandoning the AOI approach to PlantPax and that seems favorable to my thesis.

Click to expand...

I have been using PAx for years now, and everyone likes them. They are overcomplicated for most, as they are for a wide user base.

I've been using this concept since PLC5, object based programming, saves a lot of time, and helps with standardization.

Rockwell is not giving up on PAx, they are just going to be embedded in the "p" processors to save memory (LOL - have you seen the prices). So the PAx blocks will not need to be added, they will be part of the firmware.

When you have several programmers in different countries, PAx and AOIs are very useful.

To find the IO points, look for the IO tag and search it up, or go to the task for that device.

Also AOIs are really useful for validation, simulation and testing.

This is also aligned with S88 standards for Process and Batch or Continuous automation.

I will clarify one thing. I like AOIs. A lot. But not for I/O. I am NOT saying that object programming or AOIs are bad, quite the opposite. I've used them for important work. The burner example I gave is a good example. The best thing about that is being able to see the logic for individual burners instead of the blur that you'd see in a subroutine.

But using them with layers and indirection for simple I/O has been a thorn and I'm fighting it and I don't deny, I'm looking for ammunition. I'd like to hear more about the places that have discouraged or banned them. I'd like to hears other confirm what a pain they are when you're looking for the solenoid coil or the limit switch contact and somebody buried it in a two layer deep nested AOI.

We use AOI for I/O but not buried

I think the buried/nested/indirect referenced I/O is not an AOI problem but an over-engineered code problem. We use AOI's for I/O all the time, but we have the AOI instances in a dedicated routine, with dedicated unique tag names and the I/O maps are done from the I/O to AOI inputs/outputs in a dedicated buffer routine. This way we can convert to emulator by just deleting the I/O map routine and then use sim/tiebacks to/from the AOI's in a dedicated sim routine to do testing - when time to go to the field, delete the sim routine, import the I/O map routine and you're back in business.


IMHO, AOI's are fine for I/O processing - it's the most repeated code in most projects, so makes sense to have an AOI.


As for locating I/O, in our model you can cross ref any AOI sub-tag from anywhere in the logic, which gets you back to the AOI instance routine, then cross ref the AOI tag itself and look for the reference in the I/O map routine and that will bring you right to the card/channel layer. Sure it's two references, but it works from anywhere in the project, and it's modular/re-usable code.


So I guess this isn't ammo against AOI's, but it is ammo against nested, two layer deep indirect indexed AOI references - I totally agree, those suck. The counter argument from those guys against my style is that doing a dedicated routine with unique tags takes longer, but to me that's worth the tradeoff. They're going to argue "I can just change my index max from 10 to 20 and double the I/O" - but you can't find any of it - creating 10 new tags and instantiating is not that much extra effort, and if they are really adamant about wanting a quick way to double the I/O, or you have projects with 100's of tags, then tell them to write up some java, python etc that outputs the mnemonic code for the instantiation to text and then paste that into Logix .l5k file and import, keep the over-engineering outside the PLC project!

williamlove said:

I will clarify one thing. I like AOIs. A lot. But not for I/O. I am NOT saying that object programming or AOIs are bad, quite the opposite. I've used them for important work. The burner example I gave is a good example. The best thing about that is being able to see the logic for individual burners instead of the blur that you'd see in a subroutine.

But using them with layers and indirection for simple I/O has been a thorn and I'm fighting it and I don't deny, I'm looking for ammunition. I'd like to hear more about the places that have discouraged or banned them. I'd like to hears other confirm what a pain they are when you're looking for the solenoid coil or the limit switch contact and somebody buried it in a two layer deep nested AOI.

Click to expand...

I get it now, yes I agree with you, too many modules in the chain confuses things, and also opens the door for more mistake / errors.

KISS - Keep It Simple Smart Guy.

I do not use the PAx AI_Chan for example, just straight into the P_AIn.

I do not like some things in the PAx, but they are getting better. For example, the confusion that can be created by having Fail alarms on the .Inp_PV and the HIHI, HI, LO, LOLO on .PV.

I will always want/need to look inside the module from time to time and locking them in the FW is a mistake IMHO.

We will not be going past 4.x, and when 4.x is unsupportable, I will be creating a simplified version.

Rockwell is still listening to their accountants too much.

I also am not a fan of AOIs inside of AOIs, but I understand why it is done, just way too much tape on the glasses for me.

When I was doing this in PLC5, I would have two subs that are identical. One for scanning all the devices (Master), and one that you could use for troubleshooting (Diag). Basically you would enter in a device number (usually 0-99) at the word level, and it would stop scanning that device in the master (skip the number), and scan that single device in the diag subroutine. Once the testing was complete, that Diag sub could be deleted, but a lot of the time, the plant wanted to keep the Diag subs. You could see any device you wanted without indirection. Lots of fun!

williamlove said:

I've also heard Rockwell is abandoning the AOI approach to PlantPax and that seems favorable to my thesis.

Click to expand...

You heard wrong... First, Rockwell's motive to exist is profit (nothing wrong with it, by the way) and it explains the moves they're making.
There's profit to be made in DCS systems by trying to undercut the big players like Emerson (although Rockwell's offering is pitiful at best) and leveraging places that have PLC control systems like SLCs and where the DCS style coding would be useful so they have a foot in the door already.

They dropped AOI's in favour of firmware instructions in certain processors and even then only for some instructions (the basic ones that have had years of testing), there's still AOI's for PlantPAX. The reason they do this is to promote lock in to more expensive processors which do simplify the development somewhat.

If Rockwell cared about ease of use we wouldn't have AOIs and instead have Function Blocks and Subroutines would either be called Functions or have internal temporary memory and enforce parameter type and allow you to name them. Since people defend them despite these glaring shortcomings, they don't have to care about fixing them and chase higher profit (as any healthy company would do).

cardosocea said:

If Rockwell cared about ease of use we wouldn't have AOIs and instead have Function Blocks and Subroutines would either be called Functions or have internal temporary memory and enforce parameter type and allow you to name them. Since people defend them despite these glaring shortcomings, they don't have to care about fixing them and chase higher profit (as any healthy company would do).

Click to expand...

Oh, please. AOIs are functions. They just don't support re-entrancy/recursion. Part of the realtime design of PLCs is to never allocate memory at runtime. So AOIs have to be accompanied by a tag containing their local variables. Climb off your high horse and think about the constraints of the environment.

Never seen an AOI used for IO, seems extreme use of AOI that adds no value.
What was wrong with aliasing or mapping IO in a file or maybe buffering IO?

If your emulating code that would make sense to use an AOI for IO. Never really thought of that as a good use.

Jim3846 said:

Never seen an AOI used for IO, seems extreme use of AOI that adds no value.
What was wrong with aliasing or mapping IO in a file or maybe buffering IO?

If your emulating code that would make sense to use an AOI for IO. Never really thought of that as a good use.

Click to expand...

It can help with Validation, Testing and maintenance functions.

Scaling as well.

All these functions are built in to the PAx objects, for example DI, DO, A_In and A_Out.

But I agree, I would not have one AOI just to pass the IO in and out of the software, and then have other AOIs for processing the signal (alarms, scaling, mode control etc).

pturmel said:

Oh, please. AOIs are functions. They just don't support re-entrancy/recursion. Part of the realtime design of PLCs is to never allocate memory at runtime. So AOIs have to be accompanied by a tag containing their local variables. Climb off your high horse and think about the constraints of the environment.

Click to expand...

I don't have to think... I look at other manufacturers and all but Rockwell have these constructs.

Perhaps Rockwell developers should do the same instead of thinking?

Also, have you had much luck downloading a single AOI into a processor or changing one online? Asking for a friend...

cardosocea said:

asking for a friend...

Click to expand...

lol.