ControlLogix : My Enhancement Suggestion To Rockwell

First of all, my thanks to the following members who tolerated my recent bellyaching about the scaling of input values in the thread "ControlLogix (RSLogix5000 Scaling Mystery)" :

jkerekes, Ron Beaufort, nhatsen, scott.lawrence, dmargineau, proof, daba, ryangriggs, Dravik, robertmee, rdrast, ASF, OKiePC, and mellis. Thanks to you all.

Just amazing how much assistance you can get on a site like this - from people all over the world - at virtually any time of the day or night. The joys of the Internet, right?

=================

But after all that discussion about scaling and what to do with out-of-range values, the following enhancement came to mind:

Give the ability to qualify the out-of-range values as a percent of (engineering) scale. Call it "Calibration Percent". So, in my case, after specifying my 4-20mA raw, and 0-10,000 ppm engineering scales, I would also enter 1% in the "Calibration Percent" box, which would automatically either set a bit, or alternately trigger an event of some kind. This would be better than the bit which currently exists (which only tells part of the story).

Also, instead of having to create a second input tag to copy the "clipped" out-of-range input to, why not change the alias tag to be a *separate* tag (call it "Engineering" tag) that the I/O Card automatically copies the "clipped" value to.

So now, you actually have some "automation" in your automation code. All you have to do is configure it up-front. The card takes care of:

1.) Storing the raw I/O input into the ugly-named I/O tag (so you can still display it)

2.) "Clipping" the raw I/O input value per the engineering range and storing into the "engineering" tag for use in your logic.

3.) Determining via the "Calibration Percent" value whether the instrument is out of calibration or not

4.) Setting the "Out of Calibration" Bit (to be read in the program, or trigger an event).

============

To me, anything that any software developer is doing repeatedly, all the time, and pretty much the same way across the board, is a candidate to be automated via macro or hardware implementation. This solution would remove all that unnecessary logic in ladder programs.

What do you think?

I fear your "enhancement request" to RA will fall on deaf ears.

Why not just write your own AOI to do as you want. Very few people will want the complexity this adds to card configuration. Most people are quite happy to see "out-of-range" values.

The AOI would not be difficult to write, and you can add any features you would like it to have.

Your idea of an "Out-of-Calibration" flag doesn't really mean much. Just because the value sent to the controller is "off-scale" by some percentage doesn't necessarily mean the instrument needs calibrating. It could be, or it could be the analog card itself needs calibrating, or it could be a genuine measurement of a process variable.

All you can tell is that the whole system is outside of some range that you determine to be "normal".

I once worked on a system that kept a tank of water at 98 deg.C, an operator noticed one day that it was at 105 deg.C and was savvy enough to realise that the tank must be under pressure, as the water wasn't boiling. He called maintenance to check and they discovered that a sterile filter in the vent line had collapsed, causing the tank to pressurise.

Agree with Daba, create an AOI to process the data how you feel you need it processed.

Keep in mind that not all hardware IO modules will have the same configurable features. 1756 IO, 1769 IO, 1734 IO, 1794 IO...all have different configuration options some more advanced than others. An AOI allows you to mitigate this and add features you want or feel you need and be a bit more flexible with hardware options.

I agree with the AOI suggestion for clipping values if you don't want to see them.

Besides, values, when out of the scaled range, are useful for preventive/predictive maintenance.

LOL! I'm searching acronymn finders, then this site to find out what "AOI" stands for, and it turns out you mean "Add On Instructions".

Is that the proper way to do it, and why? I just created a routine that gets called every scan by MainRoutine. Is that wrong?

Also - I created an initialization routine that gets called once from MainRoutine at startup. But if I also wanted to call this routine *once* from one of the routines on a Periodic scan, would I have to use a one-shot, or is there another way?

SoftwareJanitor said:

Is that the proper way to do it, and why?

Click to expand...

Yes, because:

SoftwareJanitor said:

anything that any software developer is doing repeatedly, all the time, and pretty much the same way across the board, is a candidate

Click to expand...

AGill said:

Quote:
Originally Posted by SoftwareJanitor View Post
Is that the proper way to do it, and why?
Yes, because:

Quote:
Originally Posted by SoftwareJanitor View Post
anything that any software developer is doing repeatedly, all the time, and pretty much the same way across the board, is a candidate

Click to expand...

Hit the nail on the head, AGill.

I (and probably many others) have an AOI that every single analog input gets mapped into. Regardless of what analog input module I'm using, I immediately have individually configurable high alarm, low alarm, high-high alarm, low-low alarm, sensor failure alarm, hysterisis times for all alarms, scaling and filtering. All accessible from within the program at runtime, without having to go configuring the hardware and hoping this particular card has the feature I want. One tag, one rung, and all my work is done. How's that for "automation"?

Why spend lots of time, money and effort implementing something at the hardware level that the user can do in an infinitely more flexible manner at the software level? If AOI's didn't exist, well, maybe. But AOI's exist.

ASF:

Sounds good to me! So an Add-On-Instruction is some kind of templatized code? Like an object? I'll have to look that up.

Thanks for the tip! Eventually I'll get there.

An Add-On Instruction is basically a user-defined instruction. There are hundreds of instructions included in Logix, from the humble XIC right up to things like FLL and complex math. But if none of them do what you want, you can build your own instruction. You define the input parameters, output parameters and internal parameters, write the code, and then use it as many times as you want.

Start here: http://literature.rockwellautomation.com/idc/groups/literature/documents/pm/1756-pm010_-en-p.pdf

For a quick overview:

A simple motor control AOI might have the following:

Overload (input)
Isolator (input)
EStop (input)
RunReq (input)
Run (output)
Fault (output)

Let's call our AOI "MOTOR_AOI"
You'd write all you code inside the AOI exactly as you'd code a motor anywhere else. Then, let's say you have a motor called "Motor1". You create a tag called "Motor1" of type MOTOR_AOI. Hey presto, you now have a single tag (Motor1) which when expanded out, shows you:

Motor1.Overload
Motor1.Isolator
Motor1.EStop
Motor1.RunReq
Motor1.Run
Motor1.Fault

You drop the instruction on a rung somewhere in your code, map all the inputs and outputs to the relevant places, write one line of code which turns on your Motor1.RunReq (when does this particular motor go?), and hey presto, motor control!

Now, repeat for motors 2 through n. It's a whole lot quicker than copy and pasting and finding and replacing for every motor, and makes for much neater looking code.

You can set which of your parameters are visible from the instruction faceplate. For your analog scaling AOI, you'd of course want your "engineering_high", "engineering_low", "scaled_high" and "scaled_low" parameters visible - because then you can just type them in right there in the AOI faceplate, instead of having to map them with MOV instructions.

An Add-On Instruction is a user-created instruction. You use it just like a built-in instruction. In essence an AOI is just a piece of program code that you create that can be "called" any time you need it. Each instance call will have its own tag, which is a mini-database of the AOI's parameters.

Advantages :-

Cannot be modified Online.
You can view code execution for each "instance" the AOI is used.
Can be protected.
Version Control.
Re-usable via Export/Import using .xml files.

Disadvantages :-

{deliberately left blank}

daba said:

Disadvantages :-

{deliberately left blank}

Click to expand...

Well said

ASF - we must stop meeting like this, lol

SoftwareJanitor - as an example, someone on another thread wanted to globally reset timers. There is a TONR (Timer-On with Reset) instruction, but it is not available in Ladder. (Some people do not have the other languages available to them).

I wrote the AOI in ladder (so it can be viewed with their software). It took about 10-15 minutes, and once imported can be used just like a built-in instruction.

I had to call it TON_R, it wouldn't let me call it TONR because that's the name of the non-ladder instructions.

AGill said:

Yes, because:

Click to expand...

I bow to thee... Well played

SoftwareJanitor - I had some time on my hands so put this AOI together. It's a start for you to play with.

It "cleans" or "clips" the analog data to a specified percentage above and below the Engineering scale range.

What it doesn't do, but can be modified to do, is deal with "reverse scaling" where Max < Min....

I've included a picture to show you the instruction working, one of the analog channels is above the criteria, the other is within scale range.