Simple question regarding analog inputs
- Thread starter djshorty
- Start date
93lt1
Member
I would call: "converting the signal into something that is useful" - scaling
I'm not sure how the term 'linearized' was used, but I would bet that it means that the analog input is not linear, but the controller (or whatever it's an input to) treats it as linear.
For a simple instance (not real world):
I have a 10 inch analog transducer. It produces an analog voltage signal of 0-10VDC. If the transducer is fully retracted I should see 0V at the analog input. If the transducer is at full extension, I should see 10V. Using only these two points to predict actual position of the transducer throughout it's entire travel using the analog signal, I would be linearizing the analog input. Using this scale, if I measure the transducer's actual position when the input is at 5V, and the position is not at 5 inches, the controller would still think the transducer was at 5 inches.
I'm not sure how the term 'linearized' was used, but I would bet that it means that the analog input is not linear, but the controller (or whatever it's an input to) treats it as linear.
For a simple instance (not real world):
I have a 10 inch analog transducer. It produces an analog voltage signal of 0-10VDC. If the transducer is fully retracted I should see 0V at the analog input. If the transducer is at full extension, I should see 10V. Using only these two points to predict actual position of the transducer throughout it's entire travel using the analog signal, I would be linearizing the analog input. Using this scale, if I measure the transducer's actual position when the input is at 5V, and the position is not at 5 inches, the controller would still think the transducer was at 5 inches.
Last edited:
Eric Nelson
Lifetime Supporting Member + Moderator
93lt1 said:
I would think that's the purpose of linearization. Converting a non-linear signal into a linear one. 'Scaling' assumes a linear signal.
Let's say you had a 10" transducer that went from 0 to 9V in the first 1" of travel, and the remaining 1V in the last 9" of travel. Very NON-linear, right? But if you let the controller know about this, the possibility exists that it could 'linearize' the signal, giving you something approaching accurate information.
If you give the controller a few 'way points' (the more the better)...
0.0V = 0.0"
1.0V = 0.1"
2.0V = 0.2"
3.0V = 0.3"
4.0V = 0.4"
5.0V = 0.6"
6.0V = 0.7"
7.0V = 0.8"
8.0V = 0.9"
9.0V = 1.0"
9.1V = 2"
9.2V = 3"
9.3V = 4"
9.4V = 5"
9.5V = 6"
9.6V = 7"
9.7V = 8"
9.8V = 9"
10V = 10.0"
...it should be able to approximate the curve and provide useful data.
I've never used (or needed) something like this, but I'm sure they must exist...
beerchug
-Eric
Eric Nelson
Lifetime Supporting Member + Moderator
Very few PLCs have a linearistaion function. Omron do - one variant of the APR function. Basically, a table is mapped relating ma input to level/pressure or whatever. The function is then enabled, referring to the table, and the value is linearised. Bloody marvellous for tanks that are laying on their sides with curved ends.
beerchug
beerchug
Steve Etter
Lifetime Supporting Member + Moderator
Actually, there are PLCs (well, at least one that I know of for sure) who have "linearization" functions that do nothing more than allow you to set the scale for a given analog signal.
So, to answer the original question in this light: Yes, you are "converting" the "raw" signal (RU) to useful "engineering" units (EU) that the PLC understands. Continuing with the idea of a truely linear signal, one accomplishes this by assigning an appropriate values for the scaling.
Assume you have a 0-10 VDC input signal coming from a feedback device. Your engineering units are in bits and range from 0 to 4096.
The formula for this in the PLC is Input = Scale + Offset.
Scale: Low RU value = Low EU value; High RU value = High EU value
(Example: 0 VDC = 820 bits; 10 VDC = 4096 bits)
Therefore, when your feedback is 0 VDC: Input = 0
If your feedback is 5 VDC (or 1/2 full scale): Input = (4096 / 2) = 2048
The key is to assign the proper engineering units to the input. On some PLCs this is done in the physical configuration of the PLC and in others it is done in the PLC logic.
I agree that the term "linearization" ought to be reserved for times when the signal path is not a straight line, but alas, not everyone seems to agree.
Steve
So, to answer the original question in this light: Yes, you are "converting" the "raw" signal (RU) to useful "engineering" units (EU) that the PLC understands. Continuing with the idea of a truely linear signal, one accomplishes this by assigning an appropriate values for the scaling.
Assume you have a 0-10 VDC input signal coming from a feedback device. Your engineering units are in bits and range from 0 to 4096.
The formula for this in the PLC is Input = Scale + Offset.
Scale: Low RU value = Low EU value; High RU value = High EU value
(Example: 0 VDC = 820 bits; 10 VDC = 4096 bits)
Therefore, when your feedback is 0 VDC: Input = 0
If your feedback is 5 VDC (or 1/2 full scale): Input = (4096 / 2) = 2048
The key is to assign the proper engineering units to the input. On some PLCs this is done in the physical configuration of the PLC and in others it is done in the PLC logic.
I agree that the term "linearization" ought to be reserved for times when the signal path is not a straight line, but alas, not everyone seems to agree.
Steve
linerization
djshorty
Hello,
Scaling and linearization are as noted above 2 different things. It looks like scaling has been covered so I will address linearization.
The most common non-linear transducers are thermocouples and RTD's. The input modules designed to accept them have circuitry designed to amplify and linearize them. That is why you can't use a common input module for them. That is also why, the mod. will either be transducer specific or programmable. All of the T/C and RTD variations have different output curves requiring different linearization.
There will be times when you will have a linear transducer responding to a non-linear condition. As in BobB's example with tanks.
The easiest way to deal with them is to put a linearizing signal conditioner between your transducer and input and teach or program it to give you meaningful output. This will allow you to use a standard input module.
Hope this helps
djshorty
Hello,
Scaling and linearization are as noted above 2 different things. It looks like scaling has been covered so I will address linearization.
The most common non-linear transducers are thermocouples and RTD's. The input modules designed to accept them have circuitry designed to amplify and linearize them. That is why you can't use a common input module for them. That is also why, the mod. will either be transducer specific or programmable. All of the T/C and RTD variations have different output curves requiring different linearization.
There will be times when you will have a linear transducer responding to a non-linear condition. As in BobB's example with tanks.
The easiest way to deal with them is to put a linearizing signal conditioner between your transducer and input and teach or program it to give you meaningful output. This will allow you to use a standard input module.
Hope this helps
The linearisation function in the Omron PLC is NOT for thermocouples etc. Definately use a proper transducer or thermocouple card for those. The function takes the information in the table, prepared by yourself, and calculates the linearised output. My example of a fuel tank laying on it's side with curved ends is a perfect example. The rate of increase and decrease of fuel in litres, at varying heights, varies with the curve of the tank ends. This function calculates through the curve, dependant on the data you enter into the table. Dud data, dud result.
beerchug
beerchug
Eric Nelson
Lifetime Supporting Member + Moderator
djshorty said:
Useful? Perhaps a better term would be "meaningful"...
Well, you don't HAVE to, but in general, yes...
beerchug
-Eric
Ron Beaufort
Lifetime Supporting Member
... probably more than you wanted to know ...
Greetings, djshorty,
first of all, Eric (and everyone else) has it completely right ... so don’t let me confuse you ...
but when you said:
you indicated that (and please forgive me if I’m wrong) perhaps you’re trying to make this a little more difficult than it needs to be ...
let’s use temperature as a specific example ...
let’s say that your temperature signal arrives at the PLC as an input that ranges between the values of 3277 and 16384 ... let’s further suppose that the temperature transmitter that gives you this signal has a range of 0 to 500 degrees F ...
in this case, when the value 3277 comes in, you would MORE THAN LIKELY want to convert this raw input number into a “meaningful” (Eric’s word) value of 0 degrees F ... then display this new number ... or use it to control a process ...
and also, when the value 16384 comes in, you would MORE THAN LIKELY want to convert this raw input number into a “meaningful” value of 500 degrees F ... then display this new number ... or use it to control a process ...
now this “conversion” process is usually called “scaling” ... NOT “linearization” ... and scaling is a VERY common programming procedure ... something that you’ll see used quite often ...
on the other hand, “linearization” is not all that common ... in fact, it’s hardly ever used ... (and I’m already anticipating the arguments about that statement) ...
that’s because MOST analog signals ... in MOST applications ... are going to be so close to linear that you’re NOT going to have to worry about the small amount of error between (a) what the actual temperature is ... and (b) what the temperature sensor is reporting ...
in the RARE cases that you need to be as precise as possible THROUGHOUT the ENTIRE range of the sensor’s output, then by all means linearize the signal using the ideas that have already been brought up in this thread ...
now looking at Figure A below, we see that the actual temperature (red trace) is shown as a straight line ... and in a perfect world, the signal from the sensor (black trace) would track right on top of the actual temperature ... specifically, the two lines would be perfectly superimposed ... but unfortunately the sensor in this figure is NOT “linear” ... and so the black trace is curved ... and sadly it’s only exactly and precisely accurate at two specific points ... these are the “calibration” points at 0 and 500 degrees ...
[attachment]
keep in mind that the sensor signals in the figures above are GREATLY exaggerated to show the details involved ... a real sensor’s line would be much more nearly straight ... in fact, if you were to run into a real sensor which gave a signal THIS far out of linear, you’d junk it immediately and replace it with something better ...
now on to linearization ...
the process of “linearizing” the signal would involve programming a series of steps to mathematically generate a NEW signal (based on the raw sensor’s input signal) which would more accurately track the actual temperature ... in other words, you’d take the raw curved line in ... and calculate a new straighter line to use for controlling or monitoring the process ... the other responders have already covered the ideas behind that procedure, so I’m not going to rehash it ...
but there is one other possibility that hasn’t been covered yet ... take a look at Figure B and consider this:
suppose that the only range in which we’ll EVER be concerned with the accuracy of our temperature signal is within the range of (let’s say) 100 to 300 degrees ... if that’s the case, why are we forcing ourselves to “calibrate” the temperature sensor at the extreme ends of its scale? ... in other words, why make it “perfect” at 0 degrees ... and “perfect” at 500 degrees? ... as long as we’re NEVER going to be interested in accuracy at those extreme temperatures anyway, who cares how accurate the instrument would be IF AND WHEN we ever got there? ... and yet this is exactly how many (most?) instrumentation technicians will calibrate their instruments ...
so let’s consider this instead ... let’s readjust the little screws and “calibrate” the temperature sensor to be “perfect” at 100 degrees ... and “perfect” at 300 degrees ... that’s what’s shown in Figure B ... notice that the shape of the sensor’s raw signal (the black trace) hasn’t been changed at all ... but now we’ve just shifted it over a little bit to bring it closer to the actual temperature JUST IN THE RANGE THAT WE CARE ABOUT ...
now this is NOT the way most people do it ... and I know that I’d be asking for a lot of harsh debate if I actually recommended it ... so I won’t ... all I’m doing is throwing it out there for what it’s worth as something to be considered ...
words of advice: you’ll definitely want to learn how to “scale” the PLC’s raw analog input signals ... that’s something you’re absolutely sure to need ... but save the “linearizing” ideas in your little notebook of “things that I might need someday” ... for example when one of BobB’s “curved end - horizontal tanks” show up ... then get on with your life ... most analog signals are already quite linear enough for most applications ... you’ll have plenty of other things to worry about without looking for trouble up that particular tree ...
finally, notice how many posts Eric has made so far (1029 as of this writing) ... I’d say that he’s been around the block more than once or twice ... and look what he said about linearizing in an earlier post:
let that wise statement be an indication of just how much effort you should put into mastering this “linearization” problem ... then party on ...
PS: for those who might care, personally I’d actually shift the calibration shown in Figure B even a little bit further over to the left ... just to sort of “split the difference” of the usable range between 100 and 300 degrees ... but regardless, the next “instrumentation” guy to come along behind me would undoubtedly go right back to calibrating at 0 and 500 degrees and mess everything up ...
Greetings, djshorty,
first of all, Eric (and everyone else) has it completely right ... so don’t let me confuse you ...
but when you said:
you indicated that (and please forgive me if I’m wrong) perhaps you’re trying to make this a little more difficult than it needs to be ...
let’s use temperature as a specific example ...
let’s say that your temperature signal arrives at the PLC as an input that ranges between the values of 3277 and 16384 ... let’s further suppose that the temperature transmitter that gives you this signal has a range of 0 to 500 degrees F ...
in this case, when the value 3277 comes in, you would MORE THAN LIKELY want to convert this raw input number into a “meaningful” (Eric’s word) value of 0 degrees F ... then display this new number ... or use it to control a process ...
and also, when the value 16384 comes in, you would MORE THAN LIKELY want to convert this raw input number into a “meaningful” value of 500 degrees F ... then display this new number ... or use it to control a process ...
now this “conversion” process is usually called “scaling” ... NOT “linearization” ... and scaling is a VERY common programming procedure ... something that you’ll see used quite often ...
on the other hand, “linearization” is not all that common ... in fact, it’s hardly ever used ... (and I’m already anticipating the arguments about that statement) ...
that’s because MOST analog signals ... in MOST applications ... are going to be so close to linear that you’re NOT going to have to worry about the small amount of error between (a) what the actual temperature is ... and (b) what the temperature sensor is reporting ...
in the RARE cases that you need to be as precise as possible THROUGHOUT the ENTIRE range of the sensor’s output, then by all means linearize the signal using the ideas that have already been brought up in this thread ...
now looking at Figure A below, we see that the actual temperature (red trace) is shown as a straight line ... and in a perfect world, the signal from the sensor (black trace) would track right on top of the actual temperature ... specifically, the two lines would be perfectly superimposed ... but unfortunately the sensor in this figure is NOT “linear” ... and so the black trace is curved ... and sadly it’s only exactly and precisely accurate at two specific points ... these are the “calibration” points at 0 and 500 degrees ...
[attachment]
keep in mind that the sensor signals in the figures above are GREATLY exaggerated to show the details involved ... a real sensor’s line would be much more nearly straight ... in fact, if you were to run into a real sensor which gave a signal THIS far out of linear, you’d junk it immediately and replace it with something better ...
now on to linearization ...
the process of “linearizing” the signal would involve programming a series of steps to mathematically generate a NEW signal (based on the raw sensor’s input signal) which would more accurately track the actual temperature ... in other words, you’d take the raw curved line in ... and calculate a new straighter line to use for controlling or monitoring the process ... the other responders have already covered the ideas behind that procedure, so I’m not going to rehash it ...
but there is one other possibility that hasn’t been covered yet ... take a look at Figure B and consider this:
suppose that the only range in which we’ll EVER be concerned with the accuracy of our temperature signal is within the range of (let’s say) 100 to 300 degrees ... if that’s the case, why are we forcing ourselves to “calibrate” the temperature sensor at the extreme ends of its scale? ... in other words, why make it “perfect” at 0 degrees ... and “perfect” at 500 degrees? ... as long as we’re NEVER going to be interested in accuracy at those extreme temperatures anyway, who cares how accurate the instrument would be IF AND WHEN we ever got there? ... and yet this is exactly how many (most?) instrumentation technicians will calibrate their instruments ...
so let’s consider this instead ... let’s readjust the little screws and “calibrate” the temperature sensor to be “perfect” at 100 degrees ... and “perfect” at 300 degrees ... that’s what’s shown in Figure B ... notice that the shape of the sensor’s raw signal (the black trace) hasn’t been changed at all ... but now we’ve just shifted it over a little bit to bring it closer to the actual temperature JUST IN THE RANGE THAT WE CARE ABOUT ...
now this is NOT the way most people do it ... and I know that I’d be asking for a lot of harsh debate if I actually recommended it ... so I won’t ... all I’m doing is throwing it out there for what it’s worth as something to be considered ...
words of advice: you’ll definitely want to learn how to “scale” the PLC’s raw analog input signals ... that’s something you’re absolutely sure to need ... but save the “linearizing” ideas in your little notebook of “things that I might need someday” ... for example when one of BobB’s “curved end - horizontal tanks” show up ... then get on with your life ... most analog signals are already quite linear enough for most applications ... you’ll have plenty of other things to worry about without looking for trouble up that particular tree ...
finally, notice how many posts Eric has made so far (1029 as of this writing) ... I’d say that he’s been around the block more than once or twice ... and look what he said about linearizing in an earlier post:
let that wise statement be an indication of just how much effort you should put into mastering this “linearization” problem ... then party on ...
PS: for those who might care, personally I’d actually shift the calibration shown in Figure B even a little bit further over to the left ... just to sort of “split the difference” of the usable range between 100 and 300 degrees ... but regardless, the next “instrumentation” guy to come along behind me would undoubtedly go right back to calibrating at 0 and 500 degrees and mess everything up ...
kalle
Member
Sorry for wakeing up this old thread again, but since it is almost christmas again, it's time for giving and shareing... (with no disrespect to other religions, cultures, personal believes etc,etc).
I saw BobB in the "Iec 1131" thread talked about Omron instruction APR again (no offence) and remembered this old thread
If the PLC don't have it, then make it!
Attached is a function I wrote for Telemecanique some years ago, as a DFB (Derived Function Block). Saved as binary DFB. DFB can be used by TSX/PCX/PMX57 PLCs I think.
The function is similar to APR regarding converting/linearization, but I believe that with APR the endpoint in the table IS endpoints, but here the curve continous below lowest point in the table and vica verca for the highest point.
The table can consist of 2 to ..n points. More can be read in the "Descriptive form" in the DFB for those who have PL7 software.
Note also that the attached version of the function is made for WORD parameters. Both the table, input X-value and output Y-value are of type word.
Last remark, remeber to make an instance/instances of the DFB if using it in the PLC code!
Regarding linearization functions
It's use is not only for linearizate an analog input like volum, temperature, water hight etc.
Other examples are:
- With cranes: Max load versus bom radius
- Joy sticks curves: zero point, area of no gain, different gains etc
- Speed curves: Cheap Axis control, encoder input and analog output to an inverter.
I am sure there are others. Use the imagination
I saw BobB in the "Iec 1131" thread talked about Omron instruction APR again (no offence) and remembered this old thread
BobB said:
If the PLC don't have it, then make it!
Attached is a function I wrote for Telemecanique some years ago, as a DFB (Derived Function Block). Saved as binary DFB. DFB can be used by TSX/PCX/PMX57 PLCs I think.
The function is similar to APR regarding converting/linearization, but I believe that with APR the endpoint in the table IS endpoints, but here the curve continous below lowest point in the table and vica verca for the highest point.
The table can consist of 2 to ..n points. More can be read in the "Descriptive form" in the DFB for those who have PL7 software.
Note also that the attached version of the function is made for WORD parameters. Both the table, input X-value and output Y-value are of type word.
Last remark, remeber to make an instance/instances of the DFB if using it in the PLC code!
Regarding linearization functions
It's use is not only for linearizate an analog input like volum, temperature, water hight etc.
Other examples are:
- With cranes: Max load versus bom radius
- Joy sticks curves: zero point, area of no gain, different gains etc
- Speed curves: Cheap Axis control, encoder input and analog output to an inverter.
I am sure there are others. Use the imagination
Similar Topics
we need to control a fiber optic polishing machine , the sequence of events is this .
1. hit start switch timer 1 runs for XX period of time and...
Hi, I'm pretty new at this whole PLC thing. If you have a branch in the input section of a rung what does that mean? Is the branch true if every...
Hello again..trying something on an existing poorly written program and just wanted to double check something
system is an A-B MicroLogix 1200
In...
Hi all,
Writng a FB in ST on Beckhoff TC for a pulser which turns on and off on a cycle, is paused by turning bControlInput to FALSE, but resumes...
Hi all,
I have a simple question that I have overcomplicated and gotten stuck on. I have a variable, we can call it "light" that I need to stay...