Followers 0

# Losing Decimal Places after MUL

## 9 posts in this topic

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. The process is shown as SBK1 then SBK2 and Scaling Blocks (SBK) logic are shown in SBK_Logic, all attached. Scaling block code is just 2 rungs: MUL(Raw_Input,System_Gain,Scaled_Output); ADD(Scaled_Output,System_Offset,Scaled_Output); Thanks, BG Edited by bgtorque

##### Share on other sites
Maybe because you are multiplying by a number w/ only 3 decimal places? I.e. your gain term is 0.025 which has 3 decimal places. Have you tried rewriting the gain term as 0.025000?

##### Share on other sites
Thanks Andrew, I thought that myself, but this did not make any difference, as soon as I entered it and hit 'Enter' it dropped the mulitplier to the 3 D.P and the output.

##### Share on other sites
Try looking at the output value in the tag listing. See if it has any more decimal places shown there. It may just be an artifact of the instruction layout.

##### Share on other sites
Thanks, I did try this but no.

##### Share on other sites
Check the data type of the "Raw_Input" term in the scaling block; it looks like it is an integer. Since your analog raw value is also an integer, that works fine for analog scaling. But in your percentage scaling it is converting your floating point input term to an integer before doing the math: 53 * 0.025 = 1.325

##### Share on other sites
Just as an update, I solved this issue by using a CPT (Compute) with an expression that does the full gain and offset calculation in one go, e.g {(Raw*Gain)+Offset}

##### Share on other sites
It does look like JRoss was correct as well.

##### Share on other sites
JRoss is usually, and uncannily, right!! Great to have your question and forum answers for the world to see and learn.