xnet timestamp

[Mathis_B]

Hi,

I'm currently implementing a dump of CAN data to a tdms file to one of my pieces of software. Xnet does contain an example of how to do this in a way that Diadem will natively understand the file and can analyse it with the help of the Bus log converter:

<examples>\nixnet\NI-XNET Frame Conversion and Logfile.llb\NI-XNET Frame&Log - Convert Frames (CAN to Raw).vi

One part of this example is the conversion of the time stamp to a U64:

<examples>\xnet\xnet.llb\_XNET Convert Time LV to U64.vi

My software is not using any of the xnet functionality which means that I don't want to be forced to install xnet on the target machines. The conversion of timestamps is done by a dll call which means that I have to re-create the conversion in LabVIEW to avoid having to install Xnet.

This itself is not an issue, the U64 is simply counting in steps of 100ns that works fine from 1/1/1904 until 31/12/1976 5:59:59:999

When going to 31/12/1976 6:00:00:000 you will notice that the dll will add a seemingly random offset of 9561628800E+7 to the result. I tested for higher value timestamps and there doesn't seem to be a change of this offset until the end of the year 3000 which seems to be the end of the timestamp range.

Question is now where does this sudden offset come from, what is special about 31/12/1976 6:00:00:000?

Any clues greatly appreciated

Rg Mathis

[Bob_Schor]

Well, part of the answer is that a LabVIEW TimeStamp is not a U64 -- it is a 128-bit quantity that can be represented by an array of 2 U64s.  You can get a lower-precision (but good enough for practical purposes) Dbl value by wiring the TimeStamp to a "To Double Precision Float" function, which gives you the number of seconds since Day 0 in 1903/4.  Note that if you subtract two timestamps (like 5:59:99.999 am, 31 Dec 1976 from a millisecond later, you will get 0.001, a millisecond.

What you are observing is a "fluke" of doing the wrong operation on the wrong representation.  Try TypeCasting your two TimeStamps to an array of U64 -- you'll see that the high number (which is, I think, seconds) differs by one, while the low is either 0 (for the 6 AM value) or 18428297329635842063, which I suspect is related to the floating representation of "0.999".

Bob Schor

[Mathis_B]

---

@Bob_Schor wrote:

[...] Try TypeCasting your two TimeStamps to an array of U64 [...]

---

You can do that?????

Thanks a lot, that was very helpful

for the interested reader:

http://www.ni.com/tutorial/7900/en/

I slowly start to understand what is going on and I think it's a complete **bleep**-up! The documentation of the xnet vi which uses the xnet dll states that it converts the timestamp to a U64 which is counting in 100ns steps since 01/01/1601. If you give the dll a timestamp between 01/01/1904 & 31/12/1976 5:59:59:999 the result will be a number which is counting in steps of 100ns since 01/01/1904.

From 31/12/1976 6am onwards the dll adds an offset which makes the number count in 100ns steps dating back to 01/01/1601

If you give it a timestamp between 01/01/1601 & 01/01/1904 the result will simply be zero.

I'll raise that with customer support.

[HLB]

@Bob_Schor,

If you type cast the time stamp to an array of (2) I64s and then type cast the 2nd element of that array to U64 you will get positive and negative seconds from 1904 for the first I64 element and ratio of positive parts of seconds to 2^64 for the 2nd element.  My system will add positive time zone seconds but not the 3600 daylight savings time seconds to a Time Stamp Constant output set to 00:00:00.0 1/1/1904 (I get 21,600 seconds or 6 hours for my UTC-6 central time zone with daylight savings active for the 1st I64 element).