PDA

View Full Version : Scaling analog input siemens


sparkotronic
January 18th, 2007, 01:24 PM
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

Miika
January 18th, 2007, 03:03 PM
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.

sparkotronic
January 19th, 2007, 02:21 AM
thanks for that!
I'll give it a try on Monday.

Colin

Combo
January 22nd, 2007, 01:04 AM
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

pouch
January 22nd, 2007, 01:59 AM
Have you tried using Scale, FC 105.

Regards

pouch

Combo
January 22nd, 2007, 02:29 AM
FC105 is good,

but I never use that one.

PeterW
January 22nd, 2007, 02:42 AM
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

Combo
January 22nd, 2007, 03:05 AM
I'd do the multiplication before the division

Hey Peter, how are You,

Why would you do the multiplication before the division ?

RMA
January 22nd, 2007, 05:06 AM
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.

PeterW
January 22nd, 2007, 05:24 AM
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.

Combo
January 22nd, 2007, 06:55 AM
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.

RMA
January 23rd, 2007, 06:17 AM
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.

Peter Nachtwey
January 23rd, 2007, 10:23 AM
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.

sparkotronic
June 11th, 2007, 04:04 PM
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.

Combo
June 12th, 2007, 02:12 AM
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




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.

Combo
June 12th, 2007, 02:17 AM
correction on my comment:

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 // geves us 0-276480
*R
L 2.764800e+004 Divide by 27648 // 276480/ 27648 = 10
/R
RND Round to a Double Integer
T DB6.DBW4

Your code is good. Sowry...

Everyone has his own way of coding, but in my case I think it's easier to first convert the range to 0-1. So starting with divider by 27648

Combo
June 12th, 2007, 02:19 AM
and notice that you only have numbers like 0 1 2 3 4 5 6 7 8 9 and 10 now. So it's sometimes better to use the range 10 times greater so that u have a better value to calculate with, and decimal places can be shifted on an HMI

krk
June 12th, 2007, 02:45 AM
You don't need to multiply by 10, just modify your scaling factor...


L PIW 500
ITD
DTR
L 2.764800e+003
/R
RND
T DB6.DBW4

manmeetvirdi
June 12th, 2007, 03:36 AM
FC105 is good,

but I never use that one.
Hi there
Any Special reason for that??
Or is just matter of like/dislike?

Combo
June 12th, 2007, 06:38 AM
Any reason why I should use it ?

A scale is short in code, so I don't mind writing something like that. I usually scale and calculate in the same network, FC105 is just something I don't really need.


Hi there
Any Special reason for that??
Or is just matter of like/dislike?

PeterMalt
June 12th, 2007, 03:27 PM
Ok my first message here, as posted on the dutch PLC forum
mostly we use this one for coverting and scaling. We are not using decimals in plc. If we want higher accuracy we multiply max and min scale setting bij 10 or 100 1-11 Bar is presented as 10-110.
Reasen for this is speed in calculating and comparingsons later in programs.




L #InpValue
ITD
DTR
L 2.764800e+004 // Max number of digits SIEMENS Wago change to 32764
/R
T #tmpInpValue //temp variable
L #Maxunits //Max scale value
L #MinUnits //Min scale value
-D
DTR
L #tmpInpValue
*R
L #MinUnits
DTR
+R
T #tmpInpValue
RND // Real to Integer
T #OutUnits //output value

sparkotronic
June 13th, 2007, 04:20 PM
Thanks Combo,

Probe is now working and the scale works a treat.

If only FC105 was as simple!

Regards, Colin