LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

Double to string conversion corruption

I am attempting to convert from a double (ie. 6101.000000000000000) to a string using sprintf(myString, "%8.3f MHz", myDouble)

 

I end up getting in the output string "6100.:00 MHz"

 

Any ideas?

 

I am running from a DLL from LabVIEW.  It seems to work fine when I compile my CVI executable....

0 Kudos
Message 1 of 7
(5,363 Views)

Have you tried calling your CVI DLL from a CVI executable?  What were the results?

 

Have you tried debugging your CVI DLL as it's called by LabView?  Check the following articles for info on setting it up.

http://digital.ni.com/public.nsf/allkb/6901DBC7E7A83668862565FA00735CEC

http://zone.ni.com/devzone/cda/tut/p/id/4070

http://zone.ni.com/reference/en-XX/help/370051K-01/cvi/prjbldmenudebdlls/

 

Where does the double come from (e.g. 6101)?  Is it possible that the value is changing and at times 6100.000 is the correct return value?

 

Is "6100.:00" in your message a typo and should be 6100.000? 

0 Kudos
Message 2 of 7
(5,339 Views)

Well first off, the 6100.:00 is not a typo, that is the corruption that is occuring.  Sorry I was a bit vague in my initial problem description.  I am reading from a comma separated list in a text file and copying the numbers into an array of doubles.  From there I use the values as I please as double, but I also reprint the values to a status window and another text file using sprintf and %8.3f conversion.  This is when the corruption occurs, values such as 2101, 3101, 4101, 5101, 6101, etc, when converted from double to a string using sprintf, appear as "2100.:00" and etc.

 

I have used the debugger to debug the DLL through the LabView VI that calls the DLL.  When the comma separated list is parsed into the array of doubles everything is just fine, and when I use values from the array of double, they are still the numbers I expect them to be.  The problem only occurs when I need to write out the number into a string.  I have made an example program which exhibits the problem on the system in question, but when I copy it to a different system, the problem does not occur.

 

This is the list of numbers as they appear in the text file... 

           "1001,1101,2101,3101,4101,5101,6101,"

 

Below is a printf directly after parsing the text file into the array of double, and again after reassigning the value from the array to a temporary variable

(this example is using %10.4f for the conversion in printf)

 

colon_in_number.JPG

Message Edited by Kevin Mckinley on 08-26-2009 09:23 AM
0 Kudos
Message 3 of 7
(5,337 Views)

So the problem happens on one system but not on another?

 

Do they have the same versions of Windows and CVI runtime?

 

Did you rebuild the project on the working machine, or just copy the exe/dll?

 

Could it be some weird regional setting for numeric representation?  In Control Panel, go to Regional and Language options, Standards and formats, and make sure you're using an expected standard format.

0 Kudos
Message 4 of 7
(5,323 Views)

Kevin,

 

I was able to reproduce this behavior in the latest versions of CVI and LabVIEW and have filed it as a bug under Corrective Action Request #184343.  The only work around I can conceive of is to search the string that is returned from the dll for the colon and replace it with 0.  There is a vi called Search and Replace that can help accomplish this for you.  Thank you for providing helpful feedback to improve this product in the future!

 

Cheers,

 

Message Edited by Gist on 08-26-2009 12:48 PM
0 Kudos
Message 5 of 7
(5,315 Views)

Interesting...  What version of CVI and LabVIEW did you test on?

 

The system the exhibits the problem is CVI 8.5.1 and I do not get the problem when I compile and run with CVI 8.5.0 on a different machine.  I also attempted to recreate the problem with identicle code in LabVIEW 8.5.0, but the results were as expected (no corruption).

 

Thanks for investigating.

 

 

0 Kudos
Message 6 of 7
(5,300 Views)

I reproduced this behavior using CVI 9.0.1 and LabVIEW 2009.  Thank you for pointing out that in previous versions this behavior does not always exist.  That can also serve as an alternative work around.

0 Kudos
Message 7 of 7
(5,288 Views)