Rslogix 5000 add on instructions

Does anyone have any usefull add on instructions they would be willing to share. I have built a few for interlocked motor starts and proximity switch type zero speed switches.

Look at AB PlantPax.

We have taken them, striped off the un-necessary components that we do not utilize in our control strategy, updated to support the ones that we do, and validated them.

Unfortunately, I am not able to share what we have done, but conceptually, that is where we started.

Now, we have gone a bit further. For example, FBD has a totalizer function. We wanted to use it, because it is native. So we put it in an AOI - thus is is exposed to Ladder Logic - which is the only programming we allow (don't get into why, it just is).

Hope this helps.

I've been looking at PlantPax too for some projects. What is your experience with it?

It's a good concept. Especially if you use it like they (RA) designed/intended it for.

Like I said prior ... it doesn't fit our standards. So, we don't use it out of the box ... we take the core strategy and modify for our standards.

But all in all ... I love AOI's - IF implemented properly.

I have seen installs where an entire production line was programmed in an AOI. That's not the intent, nor was it implemented properly.

The only thing I don't like about AOI is that they can't be modified online. That can be a real problem on systems that run 24/7.

jkerekes said:

The only thing I don't like about AOI is that they can't be modified online. That can be a real problem on systems that run 24/7.

Click to expand...

and that is the reason they are called "Add-On Instructions"

It is intended that, by the time they are actually in-use, they will have been tested for total functionality and usage.

You will never have the opportunity to change the coding behind the "native" instruction set, so why should you feel the need to change the coding behind instructions you have created? That implies the AOI's were flawed in the first place....

If an AOI needs changes in the field, then it was badly designed and/or implemented.

You can, of course, create a new one, and change all the existing "calls" to the original to call the new one, but that can be tedious if there are many usages of the AOI.

Treat AOI's with respect, develop them with a full understanding of their usage, deploy them only when they are fully tested and debugged, and I can't see a situation where you'd need to modify them on a running system.

Couldn't disagree more. I do understand their purpose, but as hard as we might try, there will always be a situation that will demand a change. Either new functionality or purpose. Always happens. If you can do online changes to the rest of the code while it's still executing, there must be a way to do this with AOI too.

I will have to agree with Daba on this one. I like AOIs alot, and the reason I like them is that the functionality is tested and is sound. I save time in development and testing knowing that an AOI inherently "works".

I agree AOIs will change/evolve, but that evolution should be developed/tested/validated on non-production equipment. I am pretty sure you can import AOIs into running systems, so if you need to make a change you can do so, obviously you would need to call it AOI_V_1, AOI_V_2 and replace those instances but you can put them in, and when production is down remove the old version.

I'm not really disagreeing with your points, but it would be nice to do this stuff online. There are some systems that I would on that I would have used AOI IF I only had the option to replace it online if something was amiss. The system couldn't be stopped, it would cause a major interruption to do so. Instead I needed to use "old-fashioned" methods with ST and indexed programming.

If you disagree with the philosophy of not editing online, use subroutines.

You can find some information in Rockwell Libray or here:
http://www.automationengineering.co.uk/2011/08/10/how-to-create-add-on-instructions-in-rslogix-5000