Inaccurate write to file timestamps

[pj1390]

Hi all,

I wanted to become familiar with writing data and associated timestamps to a file to verify the rate at which samples are being read into my system. As a little test I wrote up a simple VI that iterates 5 times and creates 5 sinusoidal sample points. Each point has its timestamp captured and converted to seconds and fractional seconds. After the for loop finishes iterating it writes the sample data (row by row) for all 5 samples with their associated timestamps.

I imposed a 1ms wait delay for each iteration and was hoping to see consistency between the time stamps of consecutive samples but at times they are very off or even the same as the timestamp previous which doesn't make sense to me. I have tried with larger times to wait and it seems to be more accurate between samples but this result puzzles me.

Example:

31.209159       0
 
31.209159      84
 
31.209159      91
 
31.224784      14
 
31.224784     -76

I chose not to use the Write to Measurement File VI because I was having the same problems and figured this would have better results.

Hoping someone can clear this up or show me where I am going wrong. I have attached the VI below.

Thank you.

[RavensFan]

The time function uses the Windows system clock which is notoriously inaccurate.  It has a resolution of only about 16 msec which is why you see multiple values with the same timestamp, then about a 16 msec jump when it does finally change.

PS:  The concatenate function is expandable so you can concatenate multiple items with one node, rather "stringing" along a bunch of concatenate functions.  Pun intended.

[pj1390]

Is there anyway to accurately write data to a file in the millisecond range? Is the clock really that off though? Not sure why LabVIEW would offer the option of milliseconds wait times if the error was so large. 

Thanks for the concatenation tip!

[Dennis_Knutson · Accepted solution]

If you use a hardware timed device such as NO DAQ device, then you get accurate timestamps. Anything else is a limitation of the Windows OS. You could always switch to LabVIEW RT if you need more accurate waits.

[pj1390]

Found this in case it helps someone as well: http://digital.ni.com/public.nsf/allkb/859DA6BB71B8A84F86256B3A0071141C?OpenDocument

Thanks again to you both!

[RavensFan]

As Dennis said, doing data acquisition with a hardware based timing of the acquisition will give you accurate timestamps.

If you were doing something that isn't based on DAQ, you could use the output of the Wait function which gives you a value of the millisecond timer withing the PC, that is the hardware clock and is based on when the PC was last rebooted.  (The function that you were using to get system time is essentially an OS clock, and Windows just doesn't update that frequently or reliably.)

Take the system time and the output of the Tick Count function at the very beginning of your VI.  Take the output of the Wait function and subtract from it the value from the Tick Count function.  Divide by a thousand, then add that to a System time you grab at the very beginning of your VI, you should have a consistent system time from loop iteration to loop iteration.  The only errors then will be how accurate the system time was when you first grabbed it at the beginning of the VI.

[pj1390]

That's a neat idea. I will try that out as well!

Thank you!