ControlLogix (RSLogix 5000) Scaling Mystery

I don't think I can post the app.

Click to expand...

that's unfortunate ... it's really hard for us to give you detailed information that way – but I understand your dilemma ... don't get yourself in any trouble ...

If the transmitter was scaled -40 to 120, then at 4 mA, I would want to see -40. And at 20 mA, I would want to see 120.

Click to expand...

OK – so far ...

But if the transmitter was out of range, I don't want to see those garbage numbers.

Click to expand...

now we need to talk ...

the ADVANTAGE to having those "garbage numbers" available might be to let you know that SOMETHING (broken wire, etc.) is WRONG with the system ...

incidentally – that's the MAIN reason why many (most?) instrumentation signals are set up to use FOUR to 20 mA – and not (usually) ZERO to 20 mA ... the value FOUR is often referred to as a "LIVE ZERO" ... so if the processor sees a value less than FOUR, it realizes (for example) that the tank is not just "empty" – and it can take action by (for example) closing a valve until someone can check and repair the system ...

and - many (most?) thermocouple transmitters are set up for "UPSCALE BURNOUT" – which means that if the thermocouple lead breaks, the transmitter will put out a much higher than 20 mA signal – (once again) alerting the PLC that SOMETHING is WRONG with the system - so that it could then turn OFF the heaters - rather than thinking that the furnace is really COLD and turning the heaters wide open ...

TIP: if you're worried about displaying the "garbage numbers" on an HMI (which might certainly confuse an operator) – you can have the HMI display something like a "FAULT" legend when the signal is out of range ...

Isn't there just a bit on the card I can test to see if the value is garbage?

Click to expand...

sure – just start reading on page 3-18 [Adobe page 68/184] of the 1769-IF8 User Manual linked below ... some of the bits you can choose from are:

General Status Bit
Low Alarm Flag Bit
High Alarm Flag Bit

http://literature.rockwellautomation.com/idc/groups/literature/documents/um/1769-um002_-en-p.pdf

Then I'll just put it on a Maintenance Display of some kind to tell a tech to check it out during his normal routine maintenance work.

Click to expand...

well – just make sure that a "problem" can wait long enough for that "routine" maintenance work to roll around ... you don't want to take a chance on a tank overflowing – or on a temperature running wild – or something else that would fall into the "bad column" on the big clipboard of life's experiences ...

good luck with it ...

Ok, did the 4-12-20 loop test and it produced the engineering values 4.28, 5004, and 10,005 ... so no 'dead-on', but at least 'in the ballpark'.

So I have to write over this garbage value repeatedly every scan to keep it from infiltrating the program?

Really wish there was a "Don't Show Me Garbage Values" checkbox on that I/O Card.

SoftwareJanitor said:

So I have to write over this garbage value repeatedly every scan to keep it from infiltrating the program?

Click to expand...

No, you don't overwrite it every scan. The value gets updated during scans, so that won't work. You need to copy the input to a different ProcessValue tag, but only copy it when it is not garbage. When it is garbage copy an appropriate value to the ProcessValue tag, or use the OutOfRange bits to trigger you HMI to display an out of range indication instead of the value.

However, you seem to be focus on changing a display that is showing a 'garbage', and seem to be missing a bigger issue. If the value is garbage you should be concerned about how the PLC controls (or goes out of control) with garbage for input data.

Ron Beaufort:

You would have alarm limits within your engineering range that would trigger an action alarm well before these out-of-range values happened. In other words, your "engineering range" is your operating range for your program. Values outside of this range are "garbage values" that only tell you if something is wrong or not (with the instrument). But you can get that information from a status bit. You don't need these garbage values coming into your program.

proof:

Oops - that's what I meant ... filter it coming into the secondary tag.

And no - I'm not missing the bigger issue. I set up an engineering range to map the 4-20 mA input to. That's my operating range for the program. I'm telling the I/O card that's all I want to see. But then it starts sending me these garbage values. If all this is going to tell me is "there's a problem with the transmitter", then I'll just display the status bits on the card on a Maintenance Display. I don't need these goofy values coming into my program just so I can write logic to filter them out. I don't want to see them at all.

And I will have alarm limits *within my engineering range* to handle alarm conditions where action needs to be taken. I don't need these ultra-extreme values junking up my logic. That's why I established the engineering range in the first place!

I mean - how many ways do you need to be told there is something wrong with the transmitter??

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

So I already have an I/O tag with the name of the instrument which is very neatly aliased to the I/O point. I have to now create *another* (duplicate) tag, and another routine (?), just to do all these checks and filter these garbage values for *all* my analog inputs ??

SoftwareJanitor said:

And no - I'm not missing the bigger issue. I set up an engineering range to map the 4-20 mA input to. That's my operating range for the program. I'm telling the I/O card that's all I want to see.

Click to expand...

IMHO the main issue here is the difference between what you expect from the range setting and how the module uses that setting. The engineering range is just for scaling the input signal, not for limiting it. That's the way the module is designed.

nhatsen:

Apparently. To me, the IO Card should do it all for you: input the value into the raw I/O tag, copy it to your specified alias tag (but limited by your engineering range), then set an out-of-range indicator if applicable. Then your code would be nice and clean, and you'd be able to *see* the raw out-of-range value if you wanted or needed to.

But anyway ... looking back at my Post #17, the loop test showed the values were off by about 4 ppm (engineering units) when the test current of 4mA, 12mA, and 20 mA was applied at the instrument. Does this mean the instrument needs to be calibrated, or do I need to enter -4 into the offset field on the I/O card?

And as for the -26.xxx value(s) when the instrument is not reading CO input ... I know (now) that I have to filter this stuff out, but is this an indication that the instrument already needs to be calibrated? Shouldn't it be sitting there right around 4 mA when the system is not running?

SoftwareJanitor said:

nhatsen:

Apparently. To me, the IO Card should do it all for you: input the value into the raw I/O tag, copy it to your specified alias tag (but limited by your engineering range), then set an out-of-range indicator if applicable. Then your code would be nice and clean, and you'd be able to *see* the raw out-of-range value if you wanted or needed to.

Click to expand...

How would you *see* the out-of-range values if the I/O module clipped them like you want them to..? The only access to the scaled values is via the module's "I" tag, which is the same tag you will use to drive your logic.

So, no, the module will not clip or limit the values it puts into the produced data.

If you want, or need, to not use values outside of your range, then simply limit check them before using them in your averaging code. The result of your limit checks could also drive HMI messages or alarms that an instrument is producing "bad" values.

You could apply the "limit checking" by setting channel "Process Alarms" on the module itself, and use the Alarm Status Bits in the input data.... but this has the disadvantage that the alarm set-points are less "visible" than if you simply have GRT, LES, instructions in your code.....

Your code would still be "nice and clean", with the added advantage that you are dealing with what you consider to be "bad" readings, not the module.

SoftwareJanitor said:

nhatsen:

Apparently. To me, the IO Card should do it all for you: input the value into the raw I/O tag, copy it to your specified alias tag (but limited by your engineering range), then set an out-of-range indicator if applicable. Then your code would be nice and clean, and you'd be able to *see* the raw out-of-range value if you wanted or needed to.

Click to expand...

This is not how Alias tags work - an Alias tag contains no data, it is simply a tag in the database that tells the processor where the tag is that contains data.

Whenever you "look at" an Alias tag, either in your code, or on the programming software, you will see the value in the base tag, in your case the actual module's channel data, that is the only place that data will exist.

daba:

This PLC stuff is all new to me and so I'm just trying to get used to their iodiosyncrasies.

I was proposing an alternate implementation in the PLC hardware whereby your I/O tag AND alias tag would be two *separate* tags that the I/O Card would automatically load for you. And it would also use the engineering range to limit the value it put in the "alias" tag. This would save you from having to copy/paste all that nuisance limiting logic for all your analog INs. And you could still reference the raw garbage value in the I/O tag if you wanted to, or just read the out-of-range error bit on the card to indicate when maintenance is needed.

But since this feature doesn't exist, I'll be adding routine: "FilterGarbageValues"

The AD Click PLCs have an option to "Enable Range Limiter", which limits the A/D card output values to values within the engineering range. But, with this option enabled, you have no way of knowing if the input goes out of range.

I've seen some "transducer fail" logic which is based solely on whether the input value is within a specific range. Anything out-of-range generates a failure flag. So your code could simply compare the value to the min/max engineering value limits, and if less or greater, copy the limited value over the sampled value before processing the value in any sort of historization or sending to another unit.

ryangriggs:

Maybe I'll recommend the AD Click PLCs next time (LOL!). I'm sure there is a bit on those cards you can read to tell you if the value is out of range (without the actual garbage value coming into your program where you then have to set up all these instructions to filter them out).

But I have another question now, so I'll start another thread (you guys can't wait, right?)

In applications where I don't want to deal w/ out of range values, I'll just leave the card scaling to raw counts and use a SCL FB w/ limiting turned on.

They're not garbage values. They are scaled values which happen to be out of range. They are not incorrect.

Seems a whole lot of something over nothing...The module scaling has always been just that....scaling. It's not limiting. 95% of the Automation world understand this, so the condescending term of calling values out of range as "garbage" is getting ridiculously old. If you want to limit the value for an HMI or other reason, it's one single compare instruction and CLR or MOV 0. I do it for levels all the time where a negative number is impractical.

The IO module should have status bits for over/underrange for each channel.

And do NOT expect any analog module / transmitter to be 100% accurate. That is what calibration is all about, and why calibration needs to be repeated on some scheduled basis.

I scale the module to represent the physical value, in ma or V, 4.0-20.0 if current and real, 4000 to 20000 if current and integer for example, and then actually scale to the engineering units in the program. This allows for easy calibration from an HMI, without having to send module reconfigure instructions in the program.