02-13-2009 10:37 AM
LabVIEW would not throw off your system clock. One interesting test to monitor your system clock would be to try out the attached VI. I found this awesome program on the NI Community (check it out, its a great new way for code sharing on ni.com). Though we don't usually do this, I've taken the time to save this program back to LV 5 (check out lastest and greatest LabVIEW upgradesHERE). The original program on the NI Community with a descrition of the VI will run for the later versions of LabVIEW. Running this program will compare your system clock (that LV is using the get/time date function to retrieve) with an atomic clock online. I would keep this program running for an hour, and see how many seconds your clock is off at the end. This will hopefully let you know if it really is the clock in your computer at fault.
aNItaB
Applications Engineer
National Instruments
02-13-2009 11:01 AM
02-13-2009 11:44 AM
Yes- you will need internet access. The problem is not with LabVIEW- the problem is with Windows OS's that are not based on NT. Thes OS's have poor clock services and you should not depend on the system clock for a measurement (it is not tracable to any standard second PERIOD!) Either of the solutions we have proposed will work to establish an approximate error of your system clock (making it a de-facto transfer standard.) A better method is to use external test equipment to establish your time. A GPS reciever works well for this since it compares the TOS pulse from several synchronized clocks and each path distance is known.
02-13-2009 11:49 AM
02-13-2009 11:54 AM
This is not a software solution, but you could also try using a NI PCI-1588. Even without an internet connection it will provide a stable on-board clock that you can use for timestamping measurements or generating synchronized clocks. It's jitter is in the nanosecond range and they are cheaper than most GPS receivers.
-Josh
02-13-2009 12:00 PM
02-13-2009 12:24 PM
BME Genius
From your earlier posts I assume that your basic purpose it to accurately control a Voltage over Time. So you need tracability to both the SI Volt and the SI second. Your PCI-6071E analog output is calibtated to the Volt. Your PC clock is not calibrated to the Second and no software running exclusivly on your PC can get you there.
You've made a small (but common) design error that is readilly corrected. Do not control your app from the uncalabrated system timer. Your 6071 has two counter-timers that are calibrated. you don't need to worry about the system clock at all. Just set up one timer to pulse at a convienient rate (1 HZ) and set the other to totalize and execute your updates when you get the right elapsed time.
02-13-2009 01:07 PM
I'd agree to use hardware if possible for the correlation to a standard timebase. Out of curiosity is there a reason you were doing correlation in software? Is there something in SW that you need to synchronize/timestamp? There are other options for that you can probably explore...
Adam
02-13-2009 01:18 PM
02-13-2009 05:18 PM
BME genuis wrote:
Nothing other than being lazy and relying on time that is already there.
It isn't time-its a Mircosoft fantasy. It only causes headaches when Time is a component of the measurement. I found out the hard way when calculating the drift (error) of a "real-time" clock. Oh - and watch out for them pesky leap seconds- Windows doesn't know they happen, or when. EX calculate the # of seconds between 12 Dec 2008 23:59:00 and 1 Jan 2009 00:00:00. there were 61 observed-
but I digress- seconds of civil time just do not correleate to SI Seconds. SI Seconds measure time. Civil seconds are an astronomical observation and are not constant. They average JUST A HAIR OVER 1 SI second today. In 1904 they averaged EXACTLY 1 SI second and the SI second was defined by this observation however, the earth is slowing and we need leap seconds in the calander to keep civil time in line with real positioning of the earth.