Curious if anyone on the board has used the "add-on instructions" feature in RS Logix. If so, what was the application and would you recommend this feature.
I have used it for numerous things. It is fantastic when combined with UDT's.
I have created standard motor code, standard valve code with them. I have created "machine" parts for things that are common and used many times.
By exporting the code to XML (V17) you can then manupulate and reimport, so that you can use say excel to lay out your project with 50 motors and 100 valves etc. and then "bulk build" the UDT's and import them into your logic and quickly generate the logic.
You can hide the underlying logic or have it be view only or fully available. You can generate the internal code in ladder or function, or structured text or sfc , you can use the udt in ladder or function with no special changes.
Very good and a very good time saver. As I said I built a "standard" motor and valves and all of its properties in a UDT and then the logic in an AOI. This can be done for any piece of "equipment".
Control Systems Engineer
CAP, CCST, NICET
If you have ever used JSR with parameters then these are better and you are able to view that instance of the add-on. You do need to be practical with the add-on though, you could put all your code into add-ons and have one add-on per plant. The last couple I used were to do volume calculations on some horizontal cylinders, with the code inside the add-on being ST and using FBD to call the add-on. Using the add-on in FBD looks nicer than ladder as it will show signals/values going into and out of the instruction, whereas it is visually the same as a JSR with parameters in ladder.
Other examples would be to use it for a motor or valve control, some or creating a generic control function that is used several times over. Like a conveyor control system, that has product data and the like for each conveyor. Give it a go where you are able to test it, it should be fairly simple to get the grasp of.
Hi, Add-on's are a create way to build stand alone functions. I have used them to make valve/motor control blocks, alarm handlers etc. This is similar to the Siemens FB's, I would reccomend that you use these to make standard code blocks as these are easier to maintain re-use and re-deploy in other projects.
Has Rockwell made it easy to have a common library, or do you have to import/export your User defined instructions to other projects?
The Mitsubishi/Beijer IEC Developer software allows you to link your project to a library (Which in our case is stored on a file server) and if the library changes the software lets you know when you open the project and asks you if you want to upgrade your local copy of the library. I like this because you choose when you want to test the library updates, but at least the program tells you someone changed the library.
Having not used RSLogix after the user defined instructions were introduced I am curious if there are any gotchas about them.
From what I understand you do have to import export them (to XML) when you import and UDT's etc. are created.
Having said that, it is my understanding that LogixView which is an engineering library function handles this functionality (source code library management).
I have access to V4 when working at Rockwell but never really dug into it (new). I do have the manual printed and was just stanrting to read it and got sidetracked. My interest was becasue a couple of my Interns are doing a senior design project using VB to "auto generate" code and graphics (much like logixview) so that you layout your project in Excel and open their program and it generates the code and graphics to an XML file that you then import and then "automate" the standard blocks IE when does the motor start etc.......
So short answer, I think you have to import but there is a tool to act as a source code library and revision tracker...........not sure of it's status. There are a lot of things coming out of their process group that will make it much more DCS ish (I hate that statement.
Control Systems Engineer
Once you try them, you will love them. It is great being able to create your own blocks of code that are fully debugged and able to be reused.
I have used them for all kinds of things like analog scaling, alarms, small sequences, etc.
I recall hearing that some large end users banning the use off add-on instructions in their electrical specs. Maybe they feel that they are difficult to maintain?
They ban AOIs for three reasons:
1) It's new, and therefore bad!
2) You can't alter an AOI while the processor is running.
3) Somebody did something stupid with an AOI since they were new to the concept, and now we suffer for it.
Incidentally, at least one large end-user I did work for banned AOIs... and the engineers on the floor used them anyway.
Sage Automation, Inc.
That sounds typical of what I have heard of certain companies (usually big ones with incompetent management). It annoys me somewhat that people with a non programming background are out there monkeying with equipment and the company would rather dumn down the machine/process rather than train and educate their people. It just invites spaghetti code and further problems not to encapsulate as much as possible into re-usable blocks. I think these rules probably come from the same management that sits around in a meeting and yells at people to reduce downtime and then refuses to provide resources for upgrading equipment.
Meanwhile people that are poorly trained and overstressed have to pick up the slack when the stack of poorly placed cards collapse into a nightmare that could have been avoided.
(Sorry for the rant...)
While the A-B Logix Add-On instruction capability does have some interesting potential uses and could indeed potentially be a time saver something that no one mentioned is the cost.
Add-On instructions require a significant amount of memory in the
controller to implement. Add-on instructions also require a significant amount of processing power to evaluate and solve.
Both issues should be considered and the benefits versus costs evaluated before significant use.
My $0.02 worth
Do you have any performance numbers to state for scan time or memory usage?
For instance, if you were to use 100 instantiations of the same add-on instruction to your project (lets say the add on module did something simple like a few boolean operations) would your scan time increase by 1ms, or more? Would it consume 50% of available memory just in itself?
I have a hard time believing that the add-on instructions aren't much more than a pretty typesafe version of their subroutine calls (I'm not saying this is bad...). If there is significant performance or memory limitations this would suggest that this is not the case.
I would do this experiment but I don't have a PLC and RSLogix to try it on at this time.
I'm a little confused, but I am used to it....
Does the AOI take up any less memory than the 25 bits, 8 timers, 4 integers, 3 counters etc, and 100 lines of code that it is comprised of?
In other words my understanding is that by creating a UDT (User Defined Datatype) consisting of the above mentioned parts (better memory usage) and using it in an AOI consisting of the same 100 rungs (or other), the difference is minimal ? Or is it a significant difference ?
Control Systems Engineer
> Add-On instructions require a significant amount of memory in the
controller to implement. Add-on instructions also require a significant amount of processing power to evaluate and solve. <
I agree that one should always weigh the trade-offs of anything. I DON'T agree that AOIs take up significant memory or processing power. In fact, the processing power is EXACTLY the same as if you hand-coded the logic multiple times. It does take up slightly more memory than hand-coding, but I wouldn't say it's "significant." You're talking about a few hundred bytes, per unique AOI, and less than that for each AOI call.
In fact, if you can use one AOI tag multiple times, it can take up LESS memory than hand-coding! Example: we have a function called AbsMax that takes two real and returns a positive real equal to the input value with the larger magnitude. There's no reason to have more than one tag instance for this AOI, since it has no state and you never care about examining the code while it's running.
With 750KB in the CompactLogix and 2MB in the ControlLogix (minimums) you can use a LOT of AOIs before it starts really eating into your memory.
Sage Automation, Inc.
I never really looked closely at this issue, but I never noticed it took more memory to have 100 instances of an add on instruction versus 100 instances of the same code.We have guys that have used add on insructions 1000s of times in programs and I never heard any complaining about memory issues.
So I did a test. I created a new blank project.
1769-l32e. 48,648 used
Created a simple 1 rung PLC program. 48,920 used.
Created the same program as an add on instruction, but no instances of it. 50,448 used.
Added one instance of it. 51,244 used.
Added a second instance. 51,776 used.
So it does appear there is indeed a substantial memory overhead issue with using them.
OTOH, Clx has a lot of memory available. And additional processors are cheap, while debugging,testing, and programming time are expensive.
WAGO has WAGO defined "Add-On Instructions" for use within RS-Logix and with the WAGO I/O SYSTEM. We recommend it for the ability to easily implement our high function I/O modules such as DC motor control, vibration monitoring, stepper motor control, etc. They are extremely handy when a user wants to do all the programming in RS-Logix but wants to use the flexibility of the WAGO I/O SYSTEM.
More info at www.wago.us/add-on
I was wondering how long before we saw this. A new market may be forming to supply custom AOI's to RSLogix users. I wonder if these are supplied as source, or if they can be shipped in a compiled form?
AOI's are not meant to be replacements for subroutines. Subroutines are for that level of organization (You can use them that way, but not the intent). Their main purpose is to encapsulate code so that you can use it over and over. More like "objects" than subroutines that you call over and over. For instance create a "motor" AOI and UDT. Now create "instances" of it (each instance is or can be its own living "motor" seperate from the others. But when you come along and change the AOI master. it ripples to all of it's children (bad example).
Example, the current PID block in a PLC-5 is really a locked AOI created by Rockwell, so is a timer or counter instruction from a 1980's PLC-5. You cannot see the code written inside of it. This just allows you to create "Add On Instructions" (AOI) so that you can roll your own special functions.
You also can make it read only or no-viewable or password protected. I realize there are ways to do parts of this but not as clean.
A better test would be to write an instance of motor code in a subroutine and then a single rung AOI doing the same thing. I think that the more you have the less the losses. I will ask someone I know inside the process group at Rockwell.
In the middle of a shut or I would test it myself. But just like hard drive space, memory is cheap, buy a bigger controller. My understanding is that there is a bigger one yet coming and rumors that all the documentation and comments will be in the controller.
My 2 cents worth (worth 1 cent with inflation and bailouts)
Control Systems Engineer
I've had a chance to review some ControlLogix code recently that used a lot of Add-Ons. Most were poorly written and not fully tested. The excuse was that "We didn't have enough time." Some of the code was far too complex for an Add-On instruction. Another problem was that there were too many unnecessary Inputs and Outputs. Many were used to enter and display constants that would best be a not visible Inputs. Also many Add-On instances setup as an array had Input parameters that were linked to single dimension arrays. There was no use of the Execute Prescan routine and EnableInFalse Routine. They passed the S:FS (First Scan) as an Input. There were parameters that were used to select options, when there should have been two Add-Ons.
Some of the problem stemmed from the programmers being familiar with PLC-5 programming and not taking time to learn the proper use of the RS5000 style memory. They wanted to try the cool new Add-On Instruction.
Rotten fish in a clean wrapper doesn't make it smell better.
It only took me a half a day to show them how to program a ControlLogix properly and about a day and a half to restructure their program and do the necessary testing. Their next project that was estimated to take six weeks was ready for testing in less than a week. It was the smoothest checkout they ever had. It goes to show that if they took the time to do it right, they would have enough time.
Some rules for Add-On Instructions:
Keep It Simple and Straightforward
For Discrete Logic use only Ladder Logic
For Math use Structured Text
Only pass what you absolutely need
Hard code constants
Any parameter that does not change often (Limits, etc.) should be a non-visible Input.
When needed, use Visible Inputs and Outputs to link to other Tags (similar idea to an Alias) or use an Alias Tags to link to the Add-On UDT element.
The following applies to all programming.
Show the code to someone else and have them review it.
Test, test some more, and test again
Document, document and document
If you can add anything to this please do so. Thanks
Great list; thanks for posting it. I agree with nearly all of it, but I do have a strong negative feeling on one item:
>Hard code constants
I agree that constants should not be INPUTS. However, they can be local tags with a default value. There's no way to do a true constant in Logix (or any other PLC that I've ever heard of), but this is pretty close. We like to prepend "cnst" to the name to make it clearer. By making it a local tag, you get a named constant instead of a "magic number," and you can change the value in one place to change all rungs in that AOI. You know, in case the value of Pi ever changes. :-) (That's a semi-obscure reference.)
If you want to get REALLY clever about it, you could move a value into the local tag with a rung of logic, either in the main logic or in the pre-scan routine. But I haven't found that to be necessary.
Sage Automation, Inc.
When I work at RA we implemented the AOI function before AOIs were available by use of dozens of logic files. We had a single file for each type of motor, solenoid, etc. which would fit the intent of an AOI very well. This was used in a Bio-tech application where validation was a significant part of the development time. By having a single instance of each type of I/O or device, we got to about 80% complete with 20% of the effort (there it is, the old 80/20 rule again!).
Aplying the AOI intelligently still is a must but it can and does save much effort.