Loops and system timestamp not synchronized

[Snamprogetti]

Running Labview 8.6.1 on Windows 2000, loops and system timestamp (Windows clock) seem to use different time bases; one second in a loop is not exactly as long as a second in system time. If i run a simple VI as in picture, with a 1-second loop which just prints the system time, the printed timestamp goes faster by about 1ms every 4-5 seconds. The same happens using a Timed loop or a While with a Wait until next ms multiple.

Why is that? Can i set a loop to match the system time?

[Norbert_B]

The timestamp inside the loop "runs faster than the loop"?

If so, this is rather expected for a non-realtime operating system.

The reason:

The OS has to schedule different tasks which are prioritized. The time keeping task is rather high in priority, but not maximum.

The Timed Loop can only run in the priority of the LabVIEW process (which should be "normal"). So if LV is waiting for the time to pass (1s in your case), the thread within LV goes sleeping.

If the second has passed, the thread wakes up and continues to work. Because of the scheduling, the wake up could be late. Therefore it seems that the time stamp runs faster than the loop iteration.

The Timed structures have some nice features to detect such delay and you can then react in an appropriate way  to this.

hope this helps,

Norbert 

[Snamprogetti]

Actually it shouldn't wait 1 second, but wait for the next second. Late iterations are normal, but i don't expect the delay to accumulate and diverge over time. I'm using "Mantain original phase" in the Timed loop. As the "Configuring timed loops" help page says:

if you set a Timed Loop with a period of 100 ms and an offset of 30 ms, you expect the first loop iteration to execute 30 ms after the first timing source starts running and in multiples of 100 ms after that—at 130 ms, 230 ms, 330 ms, and so on. However, the first execution of the Timed Loop might occur after 240 ms have elapsed. Because other Timed Loops or hardware devices might already be running at the schedule you specified, you can align the late Timed Loop with the already running global schedule, which means the Timed Loop can align itself as quickly as possible with the schedule you specified. In this case, the next Timed Loop iteration would run at 330 ms and continue to run in multiples of 100—at 430 ms, 530 ms, and so on.

What other nice features do you mean?

[Ben]

---

Snamprogetti wrote:

Running Labview 8.6.1 on Windows 2000, loops and system timestamp (Windows clock) seem to use different time bases; one second in a loop is not exactly as long as a second in system time. If i run a simple VI as in picture, with a 1-second loop which just prints the system time, the printed timestamp goes faster by about 1ms every 4-5 seconds. The same happens using a Timed loop or a While with a Wait until next ms multiple.

Why is that? Can i set a loop to match the system time?

---

That may be normal. The last time I looked, the system time is derived from the power supply AC applied power (mains). In the summer these typically run fast and slowwer in the winter.

Ben

[johnsold]

In the eastern U. S. interconnected power grid the accumulated time is held to within a small fraction of a second when averaged over days.  Over a year the accumulated error is less than parts in 10^12 or better.  The instantaneous frequency can deviate from the nominal 60 Hz by less than 0.1 Hz.

The system basically uses an integral controller referenced to a NIST atomic clock to force the steady state error to zero.

Lynn 

[Ben]

---

johnsold wrote:

In the eastern U. S. interconnected power grid the accumulated time is held to within a small fraction of a second when averaged over days.  Over a year the accumulated error is less than parts in 10^12 or better.  The instantaneous frequency can deviate from the nominal 60 Hz by less than 0.1 Hz.

The system basically uses an integral controller referenced to a NIST atomic clock to force the steady state error to zero.

Lynn 

---

So is that a very technical way of saying "Ben, you are full of Sh#% !"*

I have not measured the frquency of my AC service in the last three decades or so. I do remember seeing it faster in the summer and slower in the winter. Has it really changed? Silly me thinking that the wide freq input spec I read on wall-warts was there just to handle this variation of freq.

And to think it has gotten smarter "without a brain".

Ben

* I am just trying to catch up what I seem to have missed. The above is all in good humor. No offense intended or taken.

Message Edited by Ben on 08-03-2009 12:56 PM

[johnsold]

Ben,

I would never say that about you.  You are much too willing to learn!

In 1970 the frequency control for the eastern grid was at the Ohio Power Company (now part of American Electric Power) facility in Canton, OH.  They had two clocks, each with about 15-18 digits: One showed accumulated seconds and fractions of a second from the NIST timebase signal and the other was derived from the power grid.  I think there may have been an error display also.   I worked for them, although not in that section, for a short time.

Lynn 

[Snamprogetti]

In Italy i never heard about getting time from the 50Hz power grid... As far as i know, at startup the OS gets time form a real time clock with CMOS battery on the motherboard. Then it uses the CPU clock to calculate elapsed time form start. I thought the CPU clock would be the timebase for both the system time and applications timing, but maybe it isn't