Global Start Time in timed loop is not correctly converted to a timestamp

[Kenneth]

The "Global Start Time" and "Global End Time" values in a Timed Loop can be useful to timestamp data.  While a timed loop on Win XP is not deterministic, these left-node values provide a more precise timestamp that the "Get Time (seconds)" primitive.

To convert from the U64 format and nanosecond timebase, I called the convert to Timestamp primitive.  However, the resulting timestamps were invalid. By scaling the value to seconds, the timestamp was more readable, but still wrong.  It appears that the global start time's timebase is not the same as a Timestamp datatype in LabVIEW.

Does anyone know of a VI.LIB call to convert the nanosecond resolution timebase into the LabVIEW timestamp? 

[Kameralina]

Hello Kenneth,

May I ask you how you know that the value is wrong?  Are you comparing elapsed time or absolute time?  Ideally you should be subtracting the Global Start Time from the Global End Time to get the time lapse between the two before you convert to nanoseconds if you are trying to compare the value to elapsed time.  With elapsed time, you will not have to worry about the t=0 reference point in time.

Can you please post up an image of your code so that I can see how the convert to Timestamp primitive was called?

Also, please let me know whether you are using the "Get Time (seconds)" or the "Get Date/Time In Seconds", since I cannot find the first.  Perhaps it is in a different version of LabVIEW so please include your LabVIEW version.

[Kenneth]

I used the "Get Date/Time in seconds" primitive.  Also I am using the absolute timestamp value of the "Global Start Time".  I did not find any examples in LabVIEW 8.5.1 that referenced that left data node.

Attached are images of the panel and diagram.

[Kameralina]

Hello again Kenneth,

Thanks for the update.  Could you also try the "Get Tick Count" vi ?  It should return a value in ms, and I would be interested to know if this is giving you something more similar to your nanosecond timestamp than the "Get Date/Time in Seconds".

I will have to double check what the nanosecond timestamp from the timed loop is synchronized with, and I will let you know if I come up with something useful.

In the meantime, could you explain a little about your application and why you are looking for such timestamp precision on an XP machine?

[Kenneth]

Thanks for looking into this problem.   

As for the application, I am benchmarking part of an overall test application's communication performance.  The application communicates with aTCP-based instrument.  A preliminary project goal was to return 5 measurements at a group rate of 100Hz.  Each measurement requires the application to exchange a message with the TCP-based instrument.  The message includes a parameter request and a value response.  This structure results in a rate of 2 ms per message. 

I am using a Timed-loop structure to measure the effective application's communication rate.  I started with the "Event Response.vi" example to utilize a hardware trigger from the instrument.  I would like to know how accurately those events are being generated.  The problem was to find an accurate timestamp for millisecond-range messages for that loop structure. The "Get Date/Time in Seconds" returns the same value for multiple events when I tried events faster than 100 Hz. 

While the "Global start time" provides the necessary resolution, it is using a different basis than the LV Timestamp functions. I expected that it would use the same basis as the help for that left-data node described it as a timestamp.  

I tried the primitive, "Get Tick Count" to compare values. Preliminary results are attached.  The result is close to the Global Start Time, but differs slightly.

That comparison answers my question.  The timebase for "Global Start Time" resets when the  PC reboots.  However the documentation for the Timed Loop data node is misleading by describing the Global Start Time value as a timestamp.

[Kameralina]

Hello Kenneth,

Thank you for your reply.

I noticed that you are using a Windows XP system for this.  The nanosecond engine doesn't exist on Windows XP so the values beyond a millisecond are irrelevant.  If you run the timed loop on a Real-Time target instead, then the values would match up as desired.

On an XP system, the values are roughly tied to the tick count (see attachment).
 

I did not see any attachment to your last message, but I assume that when you say the values are similar, possibly the microsecond value gave you something more.

Hope this helps!