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 November 23rd, 2022, 03:37 AM   #1
cardosocea
Member
United Kingdom

cardosocea is offline
 
Join Date: Nov 2016
Location: Fields of corn
Posts: 2,177
AOI Development work flow

Hello,

I have a couple of projects where it makes sense to get an AOI developed, but am really struggling with having to download over and over to the PLC.

I know I can make another version, but that entails exporting, modifying in an offline project, importing back into the online project with a different name.
However, I'm wondering what's everyone's workflow or if you just accept that AOI's are damn near useless because of this.

Not trying to start a war, I've made it clear before that Rockwell is not on my preference list when it comes to automation platforms, but needs must and I'm more interested in learning the steps you take to do it.
  Reply With Quote
Old November 23rd, 2022, 05:03 AM   #2
Saffa
Member
New Zealand

Saffa is offline
 
Join Date: Feb 2012
Location: Bay of Plenty
Posts: 1,406
As predominantly a Schneider Control Expert user, the fact that you can edit their AOI equivalent (DFB) online, has saved me countless hours when a client changes their mind, or you find a bug. I've found minor issues in DFBs I wrote years prior (motor status tag for HMI animation didn't show as expected with an unusual combination of interlock, fault and auto status bits)... whoops, 60 second fix and update across 100 motors. Thats the whole point, in my opinion.

I guess the only recourse for you, other than the rename approach, is to spend more time on the initial development, and then run thorough simultations offline from the real world process where downloads aren't an issue.

I've started doing more and more software FAT with clients, and allow time to write simulation logic as well. It was initially a PITA but I've found that site commissioning takes much less time now. I do only work with a small number of different processes so it may just be experience, rather than technique.

Not a really useful answer for you, sorry. Will be watching this thread with interest though.
  Reply With Quote
Old November 23rd, 2022, 05:14 AM   #3
PreLC
Member
United States

PreLC is offline
 
PreLC's Avatar
 
Join Date: Apr 2019
Location: Mars
Posts: 468
If it's possible, you should put the AOI version in the name of the AOI itself. You can do online imports for new AOI and update the code later. Not very clean, but at least a workaround.

Another cleaner way is to not use AOIs, but rather SBRs to individual routines. This gives full functionality in my opinion, and is extremely underutilized.
__________________
Ask not what your PLC can do for you, ask what you can do for your PLC.
  Reply With Quote
Old November 23rd, 2022, 05:54 AM   #4
cardosocea
Member
United Kingdom

cardosocea is offline
 
Join Date: Nov 2016
Location: Fields of corn
Posts: 2,177
Quote:
Originally Posted by Saffa View Post
whoops, 60 second fix and update across 100 motors. Thats the whole point, in my opinion.
Not for the people at Rockwell apparently...

Quote:
Originally Posted by Saffa View Post
I guess the only recourse for you, other than the rename approach, is to spend more time on the initial development, and then run thorough simultations offline from the real world process where downloads aren't an issue.
This is the initial development... and even though I have an L306ER on my desk to work on this AOI alone, it's still a massive ball ache to download every little thing. I'm also playing with the Alarm manager properties within the AOI itself which is one of the reasons I'm doing it this way with the AOI.


Quote:
Originally Posted by PreLC View Post
Another cleaner way is to not use AOIs, but rather SBRs to individual routines. This gives full functionality in my opinion, and is extremely underutilized.
SBR's for repeated logic are, quite simply, disgusting. That's the reason they're overutilized in my opinion (since they should never be used at all).

Thanks for the feedback!
  Reply With Quote
Old November 23rd, 2022, 06:36 AM   #5
PreLC
Member
United States

PreLC is offline
 
PreLC's Avatar
 
Join Date: Apr 2019
Location: Mars
Posts: 468
Quote:
Originally Posted by cardosocea View Post

SBR's for repeated logic are, quite simply, disgusting. That's the reason they're overutilized in my opinion (since they should never be used at all).

Thanks for the feedback!
PLC Programming is indeed a beast of its own type. In a modern programming environment, a function(SBR equivalent) is acceptable, but a class(AOI-ish equivalent) is preferred.
Yet, in the PLC realm, we make functions(SBR), only so that we can double click them from the controller organizer and not have any value in using them in multiple locations. I think this roots in the optics of the code rather than the content(Still important, as we optically debug PLC logic)

I think they just serve a purpose - production doesn't need to stop with usages like this.
__________________
Ask not what your PLC can do for you, ask what you can do for your PLC.
  Reply With Quote
Old November 23rd, 2022, 09:28 AM   #6
cardosocea
Member
United Kingdom

cardosocea is offline
 
Join Date: Nov 2016
Location: Fields of corn
Posts: 2,177
the main dislike is that the SBR doesn't have a memory space of its own and enforce silly things like variable types. Nothing stops you throwing a bool into a REAL parameter between the JSR call and the Subroutine itself. And then, if you need variables that are internal to that "function", they're not internal as such, they'll be at the minimum program scoped which is quite a lot more than a function.

And like you say, there's the debugging element which requires a bit of forethought to throw in any errors into a variable/UDT to allow whoever to understand what happened.

I guess I've let myself think that it can't be as bad as I thought it could, but sure enough Rockwell never disappoints.

One thing I'm fairly pleased though is the alarm manager and the @AlarmSet structure it pulls in. Very interesting stuff.
  Reply With Quote
Old November 23rd, 2022, 11:25 AM   #7
glennz
Member
United States

glennz is offline
 
Join Date: Jul 2015
Location: MKE
Posts: 23
I had a higher-level Rockwell guy tell me years ago, around f/w rev 16 or so, that on-line editing of AOIs was "in the works, coming soon", etc., etc., etc. I have given up hope that it will appear anytime within my remaining working years.

Fortunately for me, the industry I work in has long lead times between concept, go-ahead approval and commissioning. We are able to test and validate AOIs on the bench well before production begins. Indeed, today I need to write one that won't be needed until late 2023 or 2024. For anything spur of the moment we'll write a subroutine.

So that, unfortunately for the OP and us in the Rockwell world, is the workflow: make it perfect on the bench before needed for production.
  Reply With Quote
Old November 23rd, 2022, 11:59 AM   #8
alan_505
Lifetime Supporting Member
Australia

alan_505 is offline
 
Join Date: Feb 2007
Location: Melbourne,Victoria,Australia
Posts: 822
Could you not create a subroutine for the test code, get that working properly and then put that subroutine code into the AOI.
  Reply With Quote
Old November 24th, 2022, 03:39 AM   #9
cardosocea
Member
United Kingdom

cardosocea is offline
 
Join Date: Nov 2016
Location: Fields of corn
Posts: 2,177
Quote:
Originally Posted by alan_505 View Post
Could you not create a subroutine for the test code, get that working properly and then put that subroutine code into the AOI.
Yes, that's the way it'll have to be... but it's a waste of effort and potential for errors too since you have In, Out, InOut, and local variables to then sort out when creating the AOI which will be something that wasn't tested and can still impact the end result.

It's a workaround... like with everything in Rockwell world it seems. Maybe they should change their name to Rockworkaround, or Allen Workaround.
  Reply With Quote
Reply
Jump to Live PLC Question and Answer Forum


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
Studio 5000 Program Parameter Connections theColonel26 LIVE PLC Questions And Answers 7 October 25th, 2019 10:55 AM
Setting up a MSG in an AOI pierrer LIVE PLC Questions And Answers 7 November 22nd, 2018 05:37 PM
2 PID loops for one control variable rta53 LIVE PLC Questions And Answers 47 January 21st, 2018 12:56 AM
Out of my depth - Feed forward, Cascade? TheWaterboy LIVE PLC Questions And Answers 22 August 31st, 2016 02:23 AM
Boiler Fuel Feed Simulation for Bunker C sjknight LIVE PLC Questions And Answers 1 November 20th, 2005 06:42 PM


All times are GMT -4. The time now is 02:12 AM.


.