System time randomly reset (-8 hours). Elapsed Timer reset to a large negative number. How to prevent?

[jcarr00]

I am using 3 elapsed timer VIs in parallel loops to help with controlling a test rig acquiring some data. I use them in a while loop as timeouts, just in case expected data isn't received within a certain time period. I noticed today that my test rig got caught in a loop as when the elapsed timer reset, it reset to a number less than -28,000, and was incrementing this number like it would if it started at zero. It should reset to zero, and that's what it usually does, so I am unsure what produced this error.

I then realized that the system time on the PC was incorrect. It had changed to the current time minus 8 hours and the elapsed timer value reset to ~ minus 8 hours at this point. I'm not sure what caused this. I check the system time a few times in my main VI and add date-timestamps to error logs and data acquisition etc. The change in system time appears to have given the elapsed timer a non-zero reset value.

I was wondering if anyone had some ideas as to why the system time reset? I had a quick look online and see that it is possible to do this from LabVIEW (here's an example) but I don't have anything like this in my code. I would like to implement a way of detecting this as well. Hopefully it is a once off but I would like my VI to be more robust to it (or at least my elapsed timers)

Rather than adding all the code used in my data acquisition, I have attached two VIs. One shows how I reset an elapsed timer and the other shows how I both print timestamps and check if the system time is greater than a set time (I use this as a finish time for the testing). These are the only times I am using the system time

Thank you

[rolfk]

Do you need a timer that is synchronized with the real time? I usually build timers around the LabVIEW tickcount that is returned by both the Tickcount (ms) and Wait (ms) functions. The value is an unsigned 32-bit integer that represents milliseconds since an arbitrary reference time, usually the moment the computer was started. It's absolute value has totally no meaning, but the relative difference between two such values is a good value for the elapsed time.

As an unsigned integer it automatically does the right thing when you subtract two such tickcount values from each other even if it rolled over. There are a few possible drawbacks for using this:

1) You can compare them with each other to find out which one happened earlier than the other, their absolute value has no meaning.

2) You can't measure intervals that are longer than the roll over interval for this value, which is 4.2*10^9 milliseconds = 49.7 days.

3) The timertick is maintained by a software component in the OS based on a hardware timer that runs of from the quartz oscillator that also drives the CPU and other clocked hardware circuits. Its absolute accuracy isn't very critical, and accurate quartz oscillators cost money, so this clock can have small variations and differences in respective to real world time. However this is in the range of several 100 ppms at most, which your normal clock will in fact have too unless it is synchronized regularly with an internet time server.

As to your original problem: Is your computer configured to synchronize to some internet time server? Did someone mess with the regional or timezone settings in your computer in that time?