Timed Loop, Global Start Time, and TimeStamps

[Bob_Schor]

When using the Timed Loop, there is a "Global Start Time" available that "returns a time stamp for the start of the current frame in nanoseconds".  Is this related to the "TimeStamp" available from the Time palette, which returns the number of seconds since 1 Jan 1904?

I wrote a little VI to explore the behavior of these two time values, hoping that they could be easily inter-converted.  When I ran this VI on my PC (LabVIEW 8.6, Windows XP SP3), the two clocks differed by about 3 billion seconds (about 105.5 years).  This seemed somewhat arbitrary, but maybe NI decided to "start the Timed Loop clock" at 1 Jan 2000?

Tried to find out if there is a known "origin" for the Timed Loop clock.  There is no documentation that I could find on this matter.  There is one posting on this Discussion Forum about this, but no resolution to the question.

Just for fun, I ran exactly the same code on a PXI Real-Time (PXI 8106) system.  To my great surprise, the clocks were identical!  So, on the PXI, the time you get from "Global Start Time" represents exactly the same time (but scaled) as the time you get from the Get Date/Time in Seconds VI on the time palette.  Indeed, if you take the Global Start Time, divide it by 1000000000 (to convert nanoseconds to seconds), then use the To Timestamp VI and wire this to an indicator, you'll see the current date and time (assuming your PXI's clock is set correctly).

I see no reason why the Timed Loop implementation on a PC cannot have the same behavior, namely setting the origin of the Global Start Time "clock" to 1 Jan 1904, identical to the TimeStamp origin.  This would allow developers who might want to use the "time" contained in Global Start Time to write code, and know that it would behave identically (ignoring, for the moment, the imprecision of the PC's clock compared to that of an RT system) on both the PC "development platform" and the target Real-Time platform.

I've spoken to a helpful NI engineer about this situation, and have asked that this be brought to the attention of the Appropriate Parties.  With luck, a fix will be forthcoming (assuming it hasn't already been fixed in LabVIEW 2009).

I've attached a picture of the VI that compares Global Start Time and the TimeStamp value. 

[Bob_Schor]

After I posted this, I realized there was one more "Time" clock, namely the Time node on the Event structure.  How is this clock (which I will call ET, for Event Time) related to the Global Start Time (or GST) and the TimeStamp (TS)?

ET represents time in milliseconds, using a U32.  The largest value that can be represented is roughly 4 billion, but there are more than 30 billion milliseconds per year.  Hence this "clock" cannot directly keep the same time as the GST or TS.

However, on the PC, if you multiply the ET value by a million (thereby converting the time to nanoseconds) and compare this value to GST, you'll see they are basically the same.  Thus, on the PC, ET and GST are "in sync", but not in sync with TS.

On a real-time PXI system, we already established that TS and GST are "in sync" -- what about ET?  Curiously, this does not seem to be synchronized with anything.

A Word to the Wise -- when I originally added the Event structure, I synchronized it with the Timed Loop using a Value(Signalling) property node, which worked fine on the PC, but failed to fire on the PXI.  I'd forgotten that you can't use this trick on real-time systems, as they have no Front Panel objects, hence the implementation using Dynamic Events. 

[Jon_S.]

Hello Bob,

The Global Start Time uses a dll that calls a high precision clock on a Real-Time target.  As you have correctly identified, this returns nanoseconds since Jan 1st, 1904.  This functionality is not compatible on Windows.  After some experimenting, it looks like the Global Start Time will return a value that is very comparable to the Tick Count (ms).  You just have to ignore the less precise numbers. 

I'm not at my work computer now but I'll try to post a picture to clarify this later.