Scaling analog input siemens

sparkotronic

Member
Join Date
Oct 2005
Location
edinburgh
Posts
37
Hi,

I'm looking for a bit of help with a machine modification that I'm about to try.

I am looking to control vacum pressure on a filling machine.
I idealy want to use a 4-20mA pressure transducer connected to a Siemens 314 PLC.
The current system has a TP170 HMI and I want to display the actual pressure on this.

The question is, how do I go about scaling the raw analog value so that it will display it in ib/in2 or bar.?
I will also need to be able to adjust the upper and lower limits via the TP170 so will the scalling cover this too?

Thanks in advance, Colin
 
Do you have TP170A or TP170B? With B-model it's possible to make scaling in HMI program. Also alarms and limits are easy to make with panel if you define lower and upper limits as tags.
 
Hey

I mostly scale like this:

L #INPUT // Analogue input 4-20mA = 0-27648
ITD
DTR
L 27648.0
/R // New range = 0-1
L #Pressure // Max Pressure Value (= @ 20mA) in Bar
*R
T DB10.DBD0 // Value to transfer on the Panel
 
Combo said:
I mostly scale like this:

L #INPUT // Analogue input 4-20mA = 0-27648
ITD
DTR
L 27648.0
/R // New range = 0-1
L #Pressure // Max Pressure Value (= @ 20mA) in Bar
*R
T DB10.DBD0 // Value to transfer on the Panel

I'd do the multiplication before the division
 
With INT or DINT you'ld get improved resolution by doing the multiplication first. Since you've converted to REALs, I wouldn't have thought it would make a lot of difference - I'm quite prepared to be taught better though, Peter! :)

By the way, depending on the values that you are working with, don't forget that you may be able to get (substantially) better resolution by working with DINTs instead of REALs, since your resolution with REALs is limited to six (or is it seven?) significant digits. The trade-off is that you have to pay close attention to the order in which you do the calculation so as to avoid over- or under-flow. You also need to check for these errors.
 
RMA, your quite corrent. My reason would be to maintain the habit rather than in this instance accuracy.

If you always do the multiplication first your unlikely to make that error.
 
Ok

Is the processing in the CPU also faster with DINT ? instead of REALS ? Just a question.

But I understand qbout the resolution and maintaining the habit.
 
I don't have the instruction manual to hand, but I'm pretty sure that INT and DINT operations will be faster than REALs. Whether it's a significant difference or not, I'm not sure - probably in the smaller CPUs, less likely in a 319 or 400 Series CPU.
 
It doesn't make much difference whether you mulitply or divide first when using reals. What does make a difference is whether you divide at all. The mantissa will retain 24 bit bits of precision no matter what order you choose.

Combo, if you are worried about speed then one should precalculate the scale factor by

Scale:=#pressure/27648.0;

Now during operation there will not be a divide. Divides take a lot of time relative to multiplies. Sometimes divides take 35 times longer than mulitples.

At least you should convert 1/27648.0 to 0.00003616898148 and muliply by that so you have two multiplies.

The faster CPU have floating point units. I would use them because you don't need to worry about overflowing 32 bit registers. In this case it may not make much difference.

I have a bunch of tricks that I have used on 16 bit integer micro controllers. These 'tricks' are common in the micro controller and DSP world but I have not seen them mentioned once here on this forum.

Here is an example:
Lets say we don't want to use floats because floating point math processor is emulated in software. Then it is faster to use integers. In this case lets assume #pressure=350 bar but to gain resolution we will use 3500 to gain resolution. Now calculate a scale factor as I showed above

Scale = 3500 / 27648 = 0

That doesn't work because the result is zero so multiply by 65536 or 2^16

Scale = 3500 * 65536 / 27648 = 8296

now when can take your analog readind and just mulitly by the scale but then you must divie by 65536. Fortunately the S7 has a shift left and shift right that allow shifting mulitple times. There may be an instruction that moves the low 16 bits to the high 16 bits.

bar := ( AnalogInput * Scale ) shr 16 // Bar x 10 or in tenths

One can shift right 16 times instead of dividing by 65536. One can also shift left 16 times instead of Multiplying. Shifting is much faster than dividing and may be a little faster than mulitplying.

This is called fractional math of Q16 math in the embedded world. You can see the scale is a fraction of 65535 or 1000H. Muliplying by fractions does not result in overflow and you don't need to do a divide by zero check. This is safer and faster.

If this confuses you then stick to the floating point math.
 
Combo said:
I mostly scale like this:

L #INPUT // Analogue input 4-20mA = 0-27648
ITD
DTR
L 27648.0
/R // New range = 0-1
L #Pressure // Max Pressure Value (= @ 20mA) in Bar
*R
T DB10.DBD0 // Value to transfer on the Panel

Hi Sorry to harp on about this subject, sommetimes I feel as if I'm thick as a plank!

Would the following code convert a 4-20mA input to 0-10?



L PIW 500 Vac probe input
ITD Integer to Double Integer
DTR Double Integer to Floating Point
L 1.000000e+001 Multiply by 10
*R
L 2.764800e+004 Divide by 27648
/R
RND Round to a Double Integer
T DB6.DBW4


This might sound stupid as well....but is the e+000 bit on a real number for the position of the decimal place?

Thanks again.
 
hmm

L PIW 500 Vac probe input
ITD Integer to Double Integer
DTR Double Integer to Floating Point // OK
L 1.000000e+001 Multiply by 10 // ??? why 10 x 10 ?
*R
L 2.764800e+004 Divide by 27648 // 100/ 27648 = 0,0036
/R
RND Round to a Double Integer // gives you zero in this case
T DB6.DBW4


This would be better:

L PIW 500 Vac probe input
ITD
DTR
L 27648.0
/R
L 10.0
*R
T DB6.DBD4 // gives u the input in 0 to 10V range (in real)

If u want integer, then I would do this before the transfer:

L 10.0
*R // range 0-100
RND
T DB6.DBW // know that u have the range 0-100 and that u can place a decimal point on the HMI now.



This might sound stupid as well....but is the e+000 bit on a real number for the position of the decimal place?
yes




sparkotronic said:
Hi Sorry to harp on about this subject, sommetimes I feel as if I'm thick as a plank!

Would the following code convert a 4-20mA input to 0-10?



L PIW 500 Vac probe input
ITD Integer to Double Integer
DTR Double Integer to Floating Point
L 1.000000e+001 Multiply by 10
*R
L 2.764800e+004 Divide by 27648
/R
RND Round to a Double Integer
T DB6.DBW4


This might sound stupid as well....but is the e+000 bit on a real number for the position of the decimal place?

Thanks again.
 

Similar Topics

Dear all Iam using three load cells connected in parallel to calibrate the weight of a product but in don't have a weighting module in my...
Replies
4
Views
3,460
Hello everyone, I have a plc 5 input card receiving an input from a conductivity Transmitter where 0ma=0 uhms and 20ma= 20,000 uhms The raw min...
Replies
8
Views
3,608
Hello everyone, I have a plc 5 input card receiving an input from a conductivity Transmitter where 0ma=0 uhms and 20ma= 20,000 uhms The raw min...
Replies
2
Views
1,827
Hello! I am new at PLC programming. I am using TM221CE16R PLC with TM3AI8 analog input module and SoMachine Basic v1.6. I am trying to scale...
Replies
8
Views
7,047
Hello, I have a Micrologix 1400 PLC and using RSLogix 500. Using a Multi Ranger Ultra Sonic Level Sensor and the input is moved to N7:11, then...
Replies
15
Views
3,859
Back
Top Bottom