Improved Round Function

[warren_scott]

I have a bunch of times that I need to round a numeric variable in TestStand

example: Locals.A = round(Locals.B)

However, it's actually more complicated than that because I need to round it at the Nth position after the decimal point (for example).   This means my expression becomes something like Locals.A = pow(10,-Locals.Digits) * round (Locals.A * pow(10,Locals.Digits) )   (for Locals.Digits == 3, this means that Locals=A becomes 0.123 when Locals.B is 0.1234)

This is a lot more code than I really want to write.  If I am doing the same thing in MS Excel, I just say $B5 = round($B4,$A$1) or something like that.  Notice how the digits of precision to round to is built into the round function.  I'd love if TestStand round function could be expanded the same way

Round(Number, [option], [Digits])

[dotNet_to_LabW]

Is this round function implemented or it's just a wish?

One has to write mode lines of code than necessary.

For e.g. if I have 2 numbers say x1 = 20.15 and x2 = 20.25

I have both the numbers declared to be as real with number of fractional digits as 2.

Now when I convert their operation to string by: Str(x1 - x2) the TestStand returns me 0.10233434564 (so something with more fractional digits)

Need help regarding this issue.

Regards

RB

[dug9000]

It sounds like you are setting numeric format to 2 fractional digits. This is purely for display purposes, it does not change or round the actual value stored in the variable (even if it did, a numeric operation could still end up giving you a result with more fractional digits). You can use a numeric format with Str though which I think will get you the behavior you want. For example:

Str(x1 - x2, "%.2f")

Hope this helps,

-Doug

[warren_scott]

I'm not certain about RB / dotNet_to_LabW 's use case, but for mine it is NOT a display issue -- it has everything to do with adjusting measurement uncertainty calculations  to specified significant digits / digits of resolution.

Kinda like the issue that technically 6*6 != 36 : 6*6 == 40 and 6.0*6.0 == 36.  We need to manage this information in the numeric represntation of the values.  Reason being is that if we do formula calculations of limits, and do 6*6, teststand just calls the limit 36, and then measured values <36 will pass and values > 36 will fail.  But the value we will display to the user is a test limit of 40 (because that is the proper number based on significant digits).  Now measure a value of 37, and put 37 on the customer documentation as the measured value (it is sometimes appropriate to report measured values with one more significant digit than the test limits).  When TestStand did the numeric comparison, it called it failing because 37>36.  But when the customer looks a the report, they see 37 is less than 40, so it should pass.  so it looks really weird, and confusing to the customer.  That's why we really need to be able to easily round to specified digits of resolution and/or significant digits -- so we can control exactly what is happening here better.

[dug9000]

I was responding to RB, not your idea. Sorry for the confusion.

[Bluegraf]

In the options of rouund() option 4 is "round to nearest integer". The behaviour for x.5 is to round towards the next even integer.

I'm missing mathematical rounding which rounds down x.49999(to be continued)-values and rounds up x.5-values.

[MimiKLM]

Bluegraf,

I had long and non conclusive dispute over this subject here in LV forum.

I've raised this in the TS forum as well: 

I miss this function as well.