Clamping group of 32 analog ins-AB RSLogix5000

I'm trying to think of a logical way to clamp a group of 32 analog inputs so that if they ever go out of range, the program will clamp them at either the min or max value. This will be in RSLogix5000

For example, if the counts drop below the minimum of 3277 counts, the program will convert it back to 3277.

Likewise, if the counts ever exceed 16384, the program will convert it back to 16384.


I haven't had much exposure to AB, but in Modicon I would make a R->T #0032 words in length and have the enable rung tied directly to the power rail. Every scan of logic would increment the pointer. For every value moved to the table, I would then use a sub block to compare it to the minimum value and overwrite as needed. I would then do the same for the max. Lastly, I would use a T->R to inject that value into an empty 40xx register using the same method for increasing the pointer. This was a quick and effective way to clamp the entire project's analog ins.

I'd use an AOI to process each analog input, including functions like scaling, alarming and clamping.

What analog module? Are you using scaling built into the module (if it has it)? I personally hate AOI's as they tend to be difficult for the laymen troubleshooter to diagnose, so usually in my scaling routine for all real world I/O I just do a simple compare using LES 0 and GRT Max and Move 0 or Max into the value if outside the limit. It's then visible and easy for someone after me to see what's going on.

^ I agree.

Also think about if you really want to clamp them instead of setting an alarm to do something about them, such as if a sensor fails.

robertmee said:

What analog module? Are you using scaling built into the module (if it has it)? I personally hate AOI's as they tend to be difficult for the laymen troubleshooter to diagnose, so usually in my scaling routine for all real world I/O I just do a simple compare using LES 0 and GRT Max and Move 0 or Max into the value if outside the limit. It's then visible and easy for someone after me to see what's going on.

Click to expand...

I don't know the module that I'll be using just yet. However, what you describe is exactly what I'm after-Only I was trying to think of a way to do all of the program's analog inputs in one network's worth of programming.

I don't see you being able to do it in a single Rung of a Ladder... but you can create a subroutine which is called to copy the data from the Analog inputs and then scale it moving the resulting value into a tag array, or a User Defined Data Type with multiple variables?

There seems to be Lots of ways to skin this cat, pick whichever one will be easiest for you to understand. No wrong way if the end result is right.

Just put your analog inputs into new variables via aliasing or MOV functions or whatever. (Good practice to do this with physical I/O.)

Then like robertmee suggested, simply add a rung that says if 'new_variable_tag'> max, 'new_variable_tag' = max. Or for min threshold, if 'new_variable_tag'<min, 'new_variable_tag' = min.

If I couldn't do it in the module, I usually use the SCL function block as it has limiting built in as an option. Throw as many of those into a function block routine as needed.

ijustdunnoaname said:

I don't know the module that I'll be using just yet. However, what you describe is exactly what I'm after-Only I was trying to think of a way to do all of the program's analog inputs in one network's worth of programming.

Click to expand...

And while you may have saved on ladder memory (which is abundant), you won't save any processor time, and the troubleshooter that comes after you will hate you.

KISS....

I am with nhatsen ,any control device should use an AOI, it minimizes mistakes and simply calling an AOI for each provides all the functionality while only programming it 1 time (less the logic to call the AOI). The OP can simply have 32 rungs, 1 AOI for each analog. Done. And you can keep it in a library for future use.

I've also never understood "clamping" analog signals. How do you trouble shoot a failed sensor if it shows 3277 when in reality, it's an open wire situation which should cause an alarm? How do you know if you are getting an overrange current?? Generally speaking an AOI allows you to program additional functionality that you can always use and enhances the functionality of your programming and keeps the clutter of that "proven" logic out of the routine. As far as troubleshooting an AOI, logic is logic. Looking at logic in an AOI isn't any different thank looking at logic in a subroutine.

Clamping the analog signals was only a portion of the logic. I haven't yet gotten my feet wet in Allen Bradley, but in Modicon I would move the clamped values to an internal register for use elsewhere in the logic. At the same time, I would compare the raw input values and trigger an over range hi, or an under range low based on the state of the input.

From reading the AB manuals and from your suggestions, I think the AOI is going to best suite my needs. I feel like I'm going from a Pinto to a Cadillac moving from Modicon to Allen Bradley. I can see that the ability to create an AOI is going to make my job much easier going forward.

Paully's5.0 said:

I am with nhatsen ,any control device should use an AOI, it minimizes mistakes and simply calling an AOI for each provides all the functionality while only programming it 1 time (less the logic to call the AOI). The OP can simply have 32 rungs, 1 AOI for each analog. Done. And you can keep it in a library for future use.

I've also never understood "clamping" analog signals. How do you trouble shoot a failed sensor if it shows 3277 when in reality, it's an open wire situation which should cause an alarm? How do you know if you are getting an overrange current?? Generally speaking an AOI allows you to program additional functionality that you can always use and enhances the functionality of your programming and keeps the clutter of that "proven" logic out of the routine. As far as troubleshooting an AOI, logic is logic. Looking at logic in an AOI isn't any different thank looking at logic in a subroutine.

Click to expand...

Many plants are running older versions that didn't allow you to look at separate instances of an AOI's logic online, so troubleshooting was impossible. I wouldn't say logic is logic in that case. I've run into many cases where I've had to build diagnostics around someone's poorly written AOI to figure out what the heck was going on. I've run across one SCP AOI that's propagated across an entire industry that forgot to account for a value of 0, so you look at the minor faults on the processor and there's thirty gazillion divide by zero errors. So, yeah, I'm a bit biased against them.

ijustdunnoaname said:

Clamping the analog signals was only a portion of the logic. I haven't yet gotten my feet wet in Allen Bradley, but in Modicon I would move the clamped values to an internal register for use elsewhere in the logic. At the same time, I would compare the raw input values and trigger an over range hi, or an under range low based on the state of the input.

From reading the AB manuals and from your suggestions, I think the AOI is going to best suite my needs. I feel like I'm going from a Pinto to a Cadillac moving from Modicon to Allen Bradley. I can see that the ability to create an AOI is going to make my job much easier going forward.

Click to expand...

Keep in mind, A lot of the 1756- Analog modules will do scaling and the over/under range right in the module config itself. You may not need to program any of that.