Changing Logic within a running AOI on ControlLogix

There was a bit of discussion on this in another thread (@Maintenance Man - Going from 500 to 5000). Instead of continuing to hijack the thread, I've started a new one

Is there a way (that I have apparently missed) to change ladder logic in an executing AOI, in a running ControlLogix 7x?

There was some discussion of a partial import for an AOI. On that topic I remember that you can import a NEW AOI with a NEW name, then change every reference to the old AOI in your PLC to call the new AOI. But that creates a new instance of the data structure so you need to hand-copy (visual photocopy) from the old structure - timer presets, retentive timers, motor current scaling, minimum off timers, maximum starts per hour, etc - to the new structure

I'd be glad to be out-of-date or just plain WRONG on this one!

You can't edit logic in a running AOI but you can get access to the local tags for each instance of the AOI. Right-mouse button click on the instruction instance and select "Open instruction logic". That will give you access to the logic for that specific instance - you can change local tag values. So a local tag could be used to enable/disable different sections of logic.

As far as timer and counter presets used in AOIs, I usually put a rung in that examines the preset value and if zero, populates the presets with a default value.

No other way of doing it aside from what you've already described.

Even in V31 which I currently have a beta for.

Thanks @jstolaruk and @Rob...

I was hoping that things had changed. It would make the AOI so much more useful!

We have a couple of AOIs that we implemented for testing purposes. We have tried enabling/disabling section of the code with parameters passed in, or externally set.

The code, whether SFC or ladder or Structured text - works well. Having your own local data structure is great. We have some global tag arrays that are accessed that are a bit of a problem but that could be changed ... if there was a way to implement fixes online. So far, we have concluded that AOIs are simply not flexible enough to deploy.

Repost from the 500 - 5000 thread, for context

I have 'typical' motor and valve subroutines spread across 10 ControlLogix. The structures are all the same. The code is all the same. When I find some fringe condition that breaks my logic, I move to my offline system, make the changes required, test it, then copy the code to the affected ControlLogix and log the change. A simple checklist keeps track of where it has been deployed and where I still need to deploy it. It usually takes a couple of days to get it onto all of the ControlLogix in between other tasks. The 'typical' simple motor subroutine controls 450 motors across those 10 ControlLogix. A larger, 'General' motor subroutine, controls the other 300 motors on site.

I guess I could copy the AOI to a new name, and change several (450) AOI calls to accomplish the same thing with AOI. AOIs import much nicer. But I run a continuous process. There is usually 1 day a year (sometimes 2) that I can shut down all of the ControlLogix at the same time and change the AOI without changing the name. And I need that 1 day to do other stuff, like patching network switches, maintaining standby power, etc.

Editing AOI online is definitely on my wish list

You could switch to Siemens but I've witnessed many problems with people making changes to function blocks without understanding the impact of the change wherever the FB is used.

I think this is one of the main reasons they lock the editing.

Imagine a plant with a 100+ of the same AOI running. Valve control for instance.

One accidental online mistake could cause real havoc.

Rob... said:

I think this is one of the main reasons they lock the editing.

Imagine a plant with a 100+ of the same AOI running. Valve control for instance.

One accidental online mistake could cause real havoc.

Click to expand...

You mean one online mistake .. like a typo when adding an extra parameter to a JSR call .. easy to do (ask me how I know) ... that faults one of the PLCs and brings the continuous process to a crash stop? 4 - 8 hours of cleanup, a few hundred tonnes of product flushed down the drain (at $200+ per tonne) as you dump pumps and tanks to avoid having the solids settle out. No one gets hurt when we dump the mill, but a production crew (15 operations people) have a lot of extra work .. and they get GRUMPY. It's bad enough when one of their own made the mistake. When an OFFICE guy makes the mistake .. and worse - an ENGINEER - it's best not to go there!

I get around JSR typos and general stuff like that by
- doing JSR adds and edits on a test PLC
- doing simple tests on the JSR call to ensure that all is well
- forcing inputs and analogs to ensure that the right status, alarms and outputs are generated
- copy/pasting the new or edited code with the JSR call into whatever PLC actually needed the change.

If the subroutine needs internal changes, I am quite a bit more paranoid than that ... but it still needs to get done in a timely manner. 'Today' for the problem case and 'This Week' for the rest of the PLCs appears to be acceptable. Changing the name of 450 AOI instances, copying data from each old structure to each new structure, in addition to actually fixing the programming problem .... I just don't have time for that.

I clearly recall when Rockwell asked the question 'Why would someone want to add a new rack to a ControlNet while it is running?' The question was answered convincingly enough that you can now do that. Same with SFC edits. I had hope editing AOIs would have taken less time, but I guess I will not have to deal with it. Just converting everything from JSR to AOI would be a project in itself now. And the boom is done for our industry. So it will be JSRs for years to come now

With the newer versions of Logix Designer, you can effectively use a subroutine in much the same way as an AOI - you can give it input and output parameters, and pass them in and out when you call it. Then you can make online edits.

Personally, I prefer AOI's and the inability to edit them online seems like a good thing. Admittedly very few of my customers run a continuous process that can't be interrupted regularly - even with the busiest of manufacturers I'm generally able to get in and do a download during a CIP, or a product changeover, or an RDO. If I literally had one opportunity per year to do downloads, perhaps I'd find the non-online-editability of an AOI more tedious, but I feel that the risks outweigh the benefits.

If you have a large process, one mistake in an AOI being changed online could take out your whole facility for a long time - sounds like the OP has experienced similar. If you have only a small process, where the impact is a lot less severe, well, chances are you'll have more chances to do a download anyway.

ASF said:

With the newer versions of Logix Designer, you can effectively use a subroutine in much the same way as an AOI - you can give it input and output parameters, and pass them in and out when you call it. Then you can make online edits

Click to expand...

I am presently using a status rung to show JSR inputs, outputs, status, alarms, etc. Another rung to show communication with IO and Devicenet, an interlock rung to determine if a motor should be allowed to run, the JSR call with the input and output parameters, and a copy from the JSR output to the real-world output. So 5 rungs.

But the only call to a subroutine from ladder logic that I know of is a JSR.

That's what I am using, but it is problematic to enter a new motor, since you can mess up how many parameters you pass in and fault the PLC. And you need to declare the tags as the correct UDT type.

I use more of a template method, where I take a typical set of code - normally 5 rungs - and copy it to an offline project, do a search and replace on the tags to get the motor number correct, do some testing in a test PLC, then paste the tested logic, as a block, into the running PLC.

If there a more bullet-proof way to do that, I am interested!

As for editing the subroutine, I also use a test PLC for that and test the changes before putting them into the running PLC ... again as a copy/paste

I thought I was being quite paranoid ... but it sounds like I am slightly less paranoid about making online changes than some of you are ...

ASF said:

With the newer versions of Logix Designer, you can effectively use a subroutine in much the same way as an AOI - you can give it input and output parameters, and pass them in and out when you call it. Then you can make online edits...

Click to expand...

This reminded me of something similar I had mentioned in the past...

http://www.plctalk.net/qanda/showthread.php?t=94414

Regards,
George

thingstodo said:

...it is problematic to enter a new motor, since you can mess up how many parameters you pass in and fault the PLC...

Click to expand...

And that, in my mind, is why online editing of AOI's is not, and should not be, possible.

George says it much more eloquently in the thread he linked above, down in post #13 (unusual for George to be more eloquent than me, I know)

Geospark said:

This reminded me of something similar I had mentioned in the past...

http://www.plctalk.net/qanda/showthread.php?t=94414

Regards,
George

Click to expand...

I apparently did something wrong during my search for AOI in the forums, since I did not find the link in the first place.

Thanks for the link. Interesting reading.

I must say that I am quite surprised that the forum has at least a few people that are measurably more paranoid than I am.

The tech note 50182 is a good comparison.

The geek in me says that it is a good implementation of a pure object. But the pragmatist in me keeps nagging that it is just SO CLOSE to being useful .. not ACTUALLY useful.

I guess I'm just too old for this sort of thing. I'm sure that if a thorough investigation was done, there is some work-around that would allow me to do almost all of what I'd need.

I can understand why they don't want to have to deal with the structure of the AIO data changing in while running but there isn't any great reason why the code can't be changed.

jstolaruk said:

You could switch to Siemens but I've witnessed many problems with people making changes to function blocks without understanding the impact of the change wherever the FB is used.

Click to expand...

I think that stems from the fact that Rockwell didn't quite take up the concept of functions as well as Siemens does. I can understand how it would be confusing to use Siemens FB's or even FC's for someone coming from an AB world.