clock drift on a 8820 PXI controller

[chilly_charly]

I'm using a  PXI 8820 controller running Windows 7. After a reset of the clock, the controller time is increasingly shifting : 2 mins after 24 hours, 6 mins after 2 days, 12 mins after 3 days, and so on. After one week the clock is one hour late. This situation is unacceptable, since the time stamps of the measurements done by my LabVIEW application are false, and can't be associated with events recorded by other computers.

Surprizingly, timed loops in LabVIEW are still perfectly accurate : a 60000 ms loop takes effectively 1 min, while the controler clock displays proudly 59 seconds (after a 2 days run)... 

I wrote a small vi which calculate simply the time difference between two successive readings of the controler clock, using the get Date/Time in seconds function of LabVIEW, in a 1000 ms timed loop. The attached picture shows that while most loops run on average 1 sec, sometimes (here 1 time per min) a second is lacking, as if the clock was remaining blocked. The frequency of these events increases progressively, which explains the drift acceleration.

The problem seems to be PXI 8820 related, and clearly it is not a LabVIEW problem, since the clock is shifting even when no LabVIEW application is running. The PXI is not old (3 months of continuous use).

Any idea to help me locate the problem ?

And to all my old frieds here on this great forum... yes... I'm lucky enough to be still alive and well 

[wiebe@CARYA]

Can you post the VI?

Is windows time synchronisation on?

In general when you want to syncronise multiple targets, SNTP is a good idea (Meinberg NTP Software works as a local STNP server). The difference between the timed loop and the time is that the first could be based on processor cycles, while the second reads out the PC's clock. So if the processor is 2% off, the timed loop will still be running exactly 60000 ms, while the clock could have been changed by windows (or a user).

It is weird that the shift is increasing, so each day is one minute shorter then the previous. It almost seems like some correction is correcting the wrong way... If so, it must be windows.