AOI Development work flow

[cardosocea]

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.

[Saffa]

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.

[PreLC]

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.

[cardosocea]

Originally Posted by Saffa

whoops, 60 second fix and update across 100 motors. Thats the whole point, in my opinion.

Not for the people at Rockwell apparently...

Originally Posted by Saffa

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.

Originally Posted by PreLC

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!

[PreLC]

Originally Posted by cardosocea

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.

[cardosocea]

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.

[glennz]

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.

[alan_505]

Could you not create a subroutine for the test code, get that working properly and then put that subroutine code into the AOI.

[cardosocea]

Originally Posted by alan_505

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.