Losing Decimal places after MUL

I have an analogue channel coming in which I run from a custom ‘Scaling Block’ that consists of first multiplying the raw counts by a gain value to get engineering units and then adding an offset value for calibration at zero. This works fine and has been used on many projects and analogue channels. In this particular instance I want to run my raw input through the scaling block, but I am scaling to give an output percentage. This output percentage is a real floating number and I can see at least 6 decimal places most of the time. I now want to run this percentage through another scaling block to convert to engineering units (torque in Nm in this instance) depending on how I have the driveline setup. As soon as I multiply by a gain term (0.025 in this instance) my final tag (REAL Floating Point) is only seeing 3 decimal places and stepping up/down in .025Nm steps. The offset in the final scaling block is zero since the channel was calibrated when in percentage output during the first scaling block. Where have my extra decimal places disappeared to? As usual, any help / advice is greatly appreciated.

Scaling block code is just 2 rungs:
MUL(Raw_Input,System_Gain,Scaled_Output);
ADD(Scaled_Output,System_Offset,Scaled_Output);

Thanks,

BG

bgtorque said:

As soon as I multiply by a gain term (0.025 in this instance) my final tag (REAL Floating Point) is only seeing 3 decimal places and stepping up/down in .025Nm steps.BG

Click to expand...

Where are you seeing this on an HMI or in your program software.

What is the data type of the Raw_Input tag in the scaling instruction?

Keith

Integer (+-10V input into a 1769-IF4I Analogue Input Module)

I'm just looking at the data inside RSLogx5000 at the minute, although it is going out to a PanelView Plus 600

What kind of step do you think you can possibly get when multiplying any integer by a fixed amount of 0.025?

THAT'S the leading question I was looking for!!

rdrast said:

What kind of step do you think you can possibly get when multiplying any integer by a fixed amount of 0.025?

Click to expand...

I perhaps didn't explain clearly. Its not the maths that I'm struggling with. I am multiplying a REAL Floating number by 0.025. It is the numbers trailing the 3 D.P that are being lost. E.G

1.234567*0.025=0.0308642 but my output would be 0.0309 and no trailing D.P, not even zero's. I have tried entering 0.025000 as my multiplier but this defaults to 0.025 as soon as i've hit 'enter'. Sorry that I didn't make this very clear.

Thanks,

I have had issues with multiplying/dividing by small decimal numbers in Logix5000. It's something about how it handles the math. In your particular case, I would change it to a divide block and divide your value by 40 instead of multiplying by 0.025.

On the other side, the floating point value actually works in powers of 2 and thus your results can be truncated or rounded depending on the degree of the decimal. I.E. 0.125 = 2^-3 whereas 0.1 = 2^-4 + 2^-5 + 2^-8 etc. and that far only gets you to 0.09765625 if that makes any sense.

So, your output is neither truncating to 3 decimal points (0.0309 is four) nor is it moving in steps of the gain factor (0.0309 is not a multiple of 0.025). About right?

While I will agree with gtg142r that I have had cases where a Logix processor may deliver a different number than my Windows calculator given the same inputs I have never had a case where a float would be specifically and consistently truncated to a given number of digits to the right of the decimal point.

Are the results repeatable? If you divide your input by 2 and multiply your scalar by 2 and run the scaling block do you get the same value out?

Keith

Where are you seeing these results?
In the PLC, or on the HMI?
(And you did in fact state that you were taking an integer input from your analog module, but I'll let that slide.)

If you are not seeing the decimal places on the HMI, then I'd bet you have your numeric format set up to only show 4 decimal places.

The results on a live processor are as expected here: