Change digits of precision on a measured value.

[graastein]

Hello

I measure a signal with a DAQ card, this signal is troubled with noise. Not much, but enough to make trouble.

Example:

I get this value into LabVIEW: 5.45012. How can I change this into this : 5.4 in the Block Diagram? A block that drops the least significant decimals.

This is easy when I'm displaying the value; just edit it in Format and Precision in the indicator.

Is there a block that does the same thing?

Sorry for my poor English.

[mross]

Hello

I measure a signal with a DAQ card, this signal is troubled with noise. Not much, but enough to make trouble.

Example:

I get this value into LabVIEW: 5.45012. How can I change this into this : 5.4 in the Block Diagram? A block that drops the least significant decimals.

This is easy when I'm displaying the value; just edit it in Format and Precision in the indicator.

Is there a block that does the same thing?

Sorry for my poor English.

You should learn about the help that is provided with labview.

If you go to Help/Vi, Function, and How to help

you get a search engine. Enter "rounding" and click List Topics.

There you will discover that rounding is a normal function with several options contained in the Numeric Tools of the Block Diagram (BD) tool pallette. If you place your screen cursor over any of the function icons you see that each has a useful name such as "round to -infinity."

If you multiply by 1000, round the way you find most appropriate or convert to integer form, and then divide by 1000 you will get a number truncated to 3 decimal points.

Or you could convert the number to a string, formating as desired, and then convert back to a number. These are normal function found in the BD tools pallette.

I have no idea why you do not find the usual methods appropriate such as converting to single precision. Normally most people just use single or double precision and adjust the indicators to show what is necessary - as you noted. Nothing much is gained computationally by truncating a double or single precision number...the computer still has to treat it like double or single precision no matter how many zeros are trailing.

Mike

[graastein]

If you multiply by 1000, round the way you find most appropriate or convert to integer form, and then divide by 1000 you will get a number truncated to 3 decimal points.

Thanks for the tip :thumbup: Worked great

[mross]

Thanks for the tip :thumbup: Worked great

You should try the string method too. It is more of a useful "package;" more ability to truncate with the offset function and you can feed a "prototype" into the default terminal.

It is worth knowing about.

Mike

[oskarbosch]

Using the string method does not seem very efficient, since handling strings is not fast.

Another approach could be to find out the range (highest power of 10) of the number, and round relative to that number.

Something like:

m = log10 (number)

p = trunc(m) //so round m to -infinity

r = number * 10^(3-p) //where 3 stands for the digits of accuracy

newnumber = 10^(p-3) * rounding( r )

Sorry for the weird notation, but seemed easier to explain this way than a LV diagram.

Oskar

[mross]

Using the string method does not seem very efficient, since handling strings is not fast.

Another approach could be to find out the range (highest power of 10) of the number, and round relative to that number.

Something like:

m = log10 (number)

p = trunc(m) //so round m to -infinity

r = number * 10^(3-p) //where 3 stands for the digits of accuracy

newnumber = 10^(p-3) * rounding( r )

Sorry for the weird notation, but seemed easier to explain this way than a LV diagram.

Oskar

Not to be argumentative, and you are correct about strings working slower, but getting to know the string conversion business is very useful. It seems like cheating, but the string conversion method offers more ways to tweak the numbers and the method is less obscure. As in how wide do you want the result to be? Rather than multiplying, or whatever, truncating, and de-whatevering. Speed is rarely going to be a problem when doing silly thinks like displaying or exporting with a particualr digits of precision. As I mentioned earlier, typically we would just do the operation as single or double precision, at speed, then change the display whenever that is needed - without ever reducing the number in its actual precision. Reducing the sig figs does nothing to reduce computation ,if the representation is not changed.

[Phillip Brooks]

I agree with Michael. The string functions can be your friend.

There are various reasons to round; the most typical is presentation.

In presentation, your requirements may change over time. I worked for a fellow that constantly wanted to change reports, often just to answer preferences of a single customer. Why did he do it? because he was the boss and he could. I had steady work, but it was mind numbing sometimes.

Anyway, you can combine the INI functions and string formatting functions to:

• Read formatting strings from key-value pairs
  
• Use these strings to format your results
  

Someone says, "Hey, LabVIEW guru, we need to change the data in your program to report SI units. Also, the quoted uncertainty isn't possible based on the number of digits presented, change it to 6 digits."

You edit the INI file and change "%.4f" to "%_6p"; browse the LAVA Lounge for an hour , goto lunch, then return with a sigh and say, "It's done... :thumbup: "

(If you compile your applications, this technique would not require rebuilding and reinstalling either!)

[didierj]

Just stumbled over such an annoying thing :thumbdown: :

In the code I use the primitive "in range and coerce" to check if "deviation" (modified meas-value) is in between "lo tol" and "hi tol" (including limits).

When doing so, LV reports that the value is out of range. But the user, who usually sees 3-4 significant digits (in the fp-indicator) thinks the value is in range.