LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

"Decimal String To Number.vi" bug in LabVIEW 2009 SP1

Solved!
Go to solution

The "Decimal String To Number.vi" seems to be converting the input data into type int32 internally even when the input data type to the vi is extended floating point (no coersion dot).  This is causing me grief.  See attached vi

 

Is this bug still present in LabVIEW 2010?

 

Thanks,

Richard Ballantyne

 

0 Kudos
Message 1 of 11
(7,407 Views)
Solution
Accepted by RichardBallantyne

There is no bug. You are using the wrong function (read the help) if you want a floating point output. Use Fract/Exp String to Number.

Message 2 of 11
(7,397 Views)

@Dennis Knutson wrote:

There is no bug. You are using the wrong function (read the help) if you want a floating point output. Use Fract/Exp String to Number.


I thought that too at first.

 

But the string is nothing but a series of integer digits.  The string has no fractional portion to it.

 

You actually could reduce the VI that demonstrates this down to this:

 

Message 3 of 11
(7,385 Views)

In my opinion this is both a bug and an inappropriate use of the Decimal String to Number Function.  If you insist on using it, you can always wire an I64 or U64 constant to the default value and coerce the output to EXT.  I won't ask why.

0 Kudos
Message 4 of 11
(7,370 Views)

In my particular case, I didn't care about the fractional component.  Since the Decimal String To Number.vi was already on my block diagram for something else, it was easier for me to just copy/paste it than to go lookup and select the Fractional String To Number.vi.  Since the Decimal String To Number.vi didn't complain (no coersion dot) when I wired in an Extended data type, I had no reason to believe that it wouldn't work.

 

So I still think this is a bug.  For now I'm just going to use the Fractional String To Number vi instead.

0 Kudos
Message 5 of 11
(7,365 Views)

Richard,

 

You marked Dennis' reply as the solution.  Are you saying you agree with him that it is not a bug and that you are using the wrong function?

 

I agree with Darin that the example you posted would be an inappropriate use of the decimal string to number function.  But I also do believe you may have found a bug and that the Decimal String to number function is not working correctly and the example you posted demonstrates that.

 

Actually, I think the example I posted demonstrates it a little more clearly as it eliminates all the calculations going on at the front end, and also compares the decimal string function to the fractional string function, and for a string that contains no fractional portion (numbers after the decimal point) they should have the same result, yet they don't.

 

EDIT: Race condition, you seemed to have already answered my questions while I was in the middle of typing them.Smiley Happy

Message 6 of 11
(7,360 Views)

Did not notice the problem with the '-' before and I agree that the use of EXT is wrong but this is a new bug. If it is not supposed to work with EXT and only integers, we should not be allowed to wire an EXT to the default data type input.

0 Kudos
Message 7 of 11
(7,350 Views)
I agree it's a bug. All floating point representatuons should be fully allowed for the decimal string to number conversions, because they are fully capable of handling integer values. It is the rsponsibility of the function to use a sufficient amount of bits for each datatype to prevent problems such as this.
Message 8 of 11
(7,335 Views)

FYI - This was reported to R&D (CAR # 248609) for further investigation.

Message 9 of 11
(7,086 Views)

This is not a bug, you use the default on i32 reresentation, if you use i64 constant inthe default in (decimal string to number) you can resolv this problem.

0 Kudos
Message 10 of 11
(3,569 Views)