You are not registered yet. Please click here to register!


 
 
plc storereviewsdownloads
This board is for PLC Related Q&A ONLY. Please DON'T use it for advertising, etc.
 
Try our online PLC Simulator- FREE.  Click here now to try it.

New Here? Please read this important info!!!


Go Back   PLCS.net - Interactive Q & A > PLCS.net - Interactive Q & A > LIVE PLC Questions And Answers

Reply
 
Thread Tools Display Modes
Old September 13th, 2021, 02:27 PM   #1
williamlove
Member
United States

williamlove is offline
 
williamlove's Avatar
 
Join Date: Jul 2007
Location: phoenix
Posts: 59
Tech 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.
  Reply With Quote
Old September 13th, 2021, 03:49 PM   #2
celichi
Lifetime Supporting Member
Canada

celichi is offline
 
celichi's Avatar
 
Join Date: Apr 2008
Location: Dundas
Posts: 260
Quote:
Originally Posted by williamlove View Post
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.
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.
  Reply With Quote
Old September 13th, 2021, 04:40 PM   #3
williamlove
Member
United States

williamlove is offline
 
williamlove's Avatar
 
Join Date: Jul 2007
Location: phoenix
Posts: 59
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.

Last edited by williamlove; September 13th, 2021 at 04:46 PM.
  Reply With Quote
Old September 13th, 2021, 05:20 PM   #4
radfahrer
Lifetime Supporting Member
United States

radfahrer is offline
 
Join Date: Nov 2006
Location: Boston
Posts: 153
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!

Last edited by radfahrer; September 13th, 2021 at 05:41 PM.
  Reply With Quote
Old September 14th, 2021, 07:53 AM   #5
celichi
Lifetime Supporting Member
Canada

celichi is offline
 
celichi's Avatar
 
Join Date: Apr 2008
Location: Dundas
Posts: 260
Quote:
Originally Posted by williamlove View Post
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.
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!
  Reply With Quote
Old September 15th, 2021, 03:24 AM   #6
cardosocea
Member
United Kingdom

cardosocea is offline
 
Join Date: Nov 2016
Location: Fields of corn
Posts: 1,944
Quote:
Originally Posted by williamlove View Post
I've also heard Rockwell is abandoning the AOI approach to PlantPax and that seems favorable to my thesis.
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).
  Reply With Quote
Old September 15th, 2021, 08:03 AM   #7
pturmel
Member
United States

pturmel is offline
 
Join Date: Jul 2021
Location: Atlanta
Posts: 102
Quote:
Originally Posted by cardosocea View Post
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).

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.
  Reply With Quote
Old September 15th, 2021, 11:34 AM   #8
Jim3846
Member
United States

Jim3846 is offline
 
Join Date: Dec 2019
Location: Cincinnati OH
Posts: 214
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.
  Reply With Quote
Old September 15th, 2021, 12:09 PM   #9
celichi
Lifetime Supporting Member
Canada

celichi is offline
 
celichi's Avatar
 
Join Date: Apr 2008
Location: Dundas
Posts: 260
Quote:
Originally Posted by Jim3846 View Post
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.
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).
  Reply With Quote
Old September 15th, 2021, 03:42 PM   #10
cardosocea
Member
United Kingdom

cardosocea is offline
 
Join Date: Nov 2016
Location: Fields of corn
Posts: 1,944
Quote:
Originally Posted by pturmel View Post
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.
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...
  Reply With Quote
Old September 15th, 2021, 03:48 PM   #11
drbitboy
Lifetime Supporting Member
United States

drbitboy is offline
 
drbitboy's Avatar
 
Join Date: Dec 2019
Location: Rochester, NY
Posts: 3,400
Quote:
Originally Posted by cardosocea View Post
asking for a friend...

lol.
__________________
i) Take care of the bits, and the bytes will take care of themselves.
ii) There is no software problem that cannot be solved with another layer of indirection.
  Reply With Quote
Reply
Jump to Live PLC Question and Answer Forum

Bookmarks


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Topics
Thread Thread Starter Forum Replies Last Post
Modbus TCP AOI for ControlLogix question defcon.klaxon LIVE PLC Questions And Answers 10 December 4th, 2020 11:06 PM
ControlLogix: AOI Not Reading BOOL Bits in Data Structure? Colt Hero LIVE PLC Questions And Answers 2 April 6th, 2020 07:10 PM
Not able to understand this S7-code drspanda LIVE PLC Questions And Answers 8 November 13th, 2007 01:06 PM
Analog value processing in S7 and explanation need arocon LIVE PLC Questions And Answers 5 January 28th, 2007 02:38 AM
PID - Velocity control of a mass on a spring. Peter Nachtwey LIVE PLC Questions And Answers 19 July 22nd, 2004 11:28 AM


All times are GMT -4. The time now is 08:38 AM.


.