LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Unable to replicate frations of seconds when reading a timestamp from a binary file

Solved!
Go to solution

I use LabVIEW to collect packets of data organized in the following fashion:

 

cluster containing:

single precision floating point number - dt

timestamp - initial time

2D array of singles - data

 

Once all data is collected the array of clusters (above) is flattened to a string, and written to a text file.

 

I am attempting to read this binary data into another program being developed in C#. I have no issues reading everything execpt the timestamp. It is my understanding that LabVIEW stores timestamps as 2 8-byte unsigned intergers. The first interger represents the whole number of seconds since Jan 1, 1904 12:00 AM, and the second represents the fractional portion of the elapsed seconds. However, when I read this information in and convert from binary to decimal the whole number seconds are correct, but the fractional portion is not the same as displayed by LabVIEW.

 

Example:

 

Hex stored in binary file representing the timestamp: 00000000CC48115A23CDE80000000000

Time displayed in LabVIEW: 8:51:38.139 8/8/2012

Timestamp converted to an EXTENDED floating point number in labview: 3427275098.139861

Binary timestamp converted to a DECIMAL floating point number in C#: 3427275098.2579973248250806272

Binary timestamp converted to a DATETIME object in C#: 8:51:38.257 8/8/2012

 

Does anyone know why there is a difference? What causes the difference?

0 Kudos
Message 1 of 12
(3,629 Views)

@CJTilley wrote:

Once all data is collected the array of clusters (above) is flattened to a string, and written to a text file.

 

I am attempting to read this binary data

 

binary file?

How did a text file become a binary file?

What am I missing here?

0 Kudos
Message 2 of 12
(3,613 Views)

Poor choice of words by me, I apologize.

 

It is a text file representing binary data.

0 Kudos
Message 3 of 12
(3,610 Views)

So, you are using Variant to Flattened String function to flatten your cluster to a string which is then written to a text file?

 

When I take a Time Stamp Contant set to 8:51:38.139 8/8/2012 and Variant to Flattened String, I get  0000 0000 CC48 115A 2395 8106 24DD 2F1B

0 Kudos
Message 4 of 12
(3,603 Views)

No, I do not use Variant to Flattened String, I use Flatten to String...although they return the same thing so this shouldnt be an issue

0 Kudos
Message 5 of 12
(3,592 Views)

Well, that Flattened to String with the time stamp constant you gave us doesn't match what you claim is in your text file.

 

0 Kudos
Message 6 of 12
(3,585 Views)

After some more investigating...

 

 

I assume you are using a TimeStamp constant with the values I put in my OP to get the flattened string. It appears that if you use a timestamp constant, as opposed to using the Get Date/Time In Seconds VI, two different flattned strings get created. This is probably a little confusing, so let me explain with an example:

 

I created a VI (VI-1) that uses Get Date/Time in Seconds to get the current time. This timestamp is then flattened to a string using Flatten to String and written to a text file.

 

I have a seperate VI (VI-2) that uses a timestamp constant with the time that was captured in the original VI. This timestamp constant is then flattened to a string and written to a file.

 

Time Captured during VI-1's execution: 10:19:30.671 8/8/2012

Hex in VI-1's text file: 0000 0000 CC48 258D 566F 5000 0000 0000

Hex in VI-2's text file: 0000 0000 CC48 258D 5645 A1CA C083 126E

 

I'm even more confused then I originally was...

0 Kudos
Message 7 of 12
(3,582 Views)

Very interesting.

 

 

When I use your original timestamp of 8:51:38.139 8/8/2012 to flatten to a text string I come up with 0000 0000 CC48 115A 2395 8106 24DD 2F1B

and when I take that binary hex string and unflatten, I get back the original timestamp.

And, if I use your binary hext string that was in your text file, 0000 0000 CC48 115A 23CD E800 0000 0000 , I also get back the original timestamp.

 

I have only used the Time Stamp constant to record as-is to a text file.

 

I agree with you this is very confusing and unexpected.

 

 

 

 

 

0 Kudos
Message 8 of 12
(3,576 Views)

@nyc_(is_out_of_here) wrote:

Very interesting.

 

 

When I use your original timestamp of 8:51:38.139 8/8/2012 to flatten to a text string I come up with 0000 0000 CC48 115A 2395 8106 24DD 2F1B

and when I take that binary hex string and unflatten, I get back the original timestamp.

And, if I use your binary hext string that was in your text file, 0000 0000 CC48 115A 23CD E800 0000 0000 , I also get back the original timestamp.

 

I have only used the Time Stamp constant to record as-is to a text file.

 

I agree with you this is very confusing and unexpected.

 

 

 

 


 So you are saying, regardless of which hex string you use, you get the same timestamp back?

 

0 Kudos
Message 9 of 12
(3,573 Views)
Solution
Accepted by topic author CJTilley

http://www.ni.com/white-paper/7900/en

 

The least significant 64 bits should be interpreted as a 64-bit unsigned integer. It represents the number of 2-64 seconds after the whole seconds specified in the most significant 64-bits. Each tick of this integer represents 0.05421010862427522170... attoseconds.

 

 

If you multiply the fractional part of your value (2579973248250806272) by 2-64 then I think you will have the proper timestamp in C.

 


Now is the right time to use %^<%Y-%m-%dT%H:%M:%S%3uZ>T
If you don't hate time zones, you're not a real programmer.

"You are what you don't automate"
Inplaceness is synonymous with insidiousness

Message 10 of 12
(3,569 Views)