Why does analog read waveform produce repeat timestamp

[Claire_Reid]

While I am looking into this you might want to take a look at this KnowledgeBase article: Why Is the Waveform Timing Information Returned by NI-DAQmx Incorrect?

[Ben]

Thank you for steping in Claire.

Dan,

Reviewing the link form Claire has me wondering about another piece of evidence that may help us.

When the Time Stamp is repeated, are the values in the "Y" array the same?

Please keep us informed (since it will only take two shakes before I run into it myself),

Ben

[DBerry]

Thanks all for the info.  I have looked at the KB link and understand tat the t0 may not be accurate.  How then do I obtain an accurate starting time for an acquisiton that is triggered using the Start trigger function?  If I just pull t0 from the waveform, this may not be correct and I am trying to compare start times with another device that is triggered via the same extrnal trigger button.

I have checked the times and Y values and it seems that the Y values change, but the timestmaps remain the same for as many as 20 waveforms.  Interestingly, the waveforms with duplicate timestamps contain no Y value for the duplicate occurence, only for the first of that timestamp.

This kind of worries me that previous applications I have written that save data to files using the timestamp from teh waveform data may be inaccurate.  Is it preferred to use the output a Daqmx Timing porperty node (Sample Clock rate) to build the time array when sacving data?

Cheers

Dan

[Ben]

Hi Dan,

All I can do to help at this time is to share how I handle this.

I will generally keep my DAQ running instead of starting and stoping it. When I don't need the data I just urge the queues regularly. Usin this approach (since about LV 6.0 or whichever version fisrt introduced the Waveform data type) I have never run into an issue with "t0" being wrong.

In your case it appears you want to be able to change the sample rate.

Since the "t0"s are being reapeated and the Y array is empty you have a condition that can be checked prior to enqueing the data. When the bug gets fixed (Note: I am only guessing this is a bug ) the condition logic will never be triggered and the code should run as you have coded. NOTE: Add comments to explain that code construct since a future reader is going to some day utter "What the F&^% is this all about?!"

Like I said, my hands are tied in what I can do to help.

Please keep us updated since if it is a bug, others will be catching it sooner or latter.

Take care,

Ben

Message Edited by Ben on 11-20-2008 07:13 AM

[Claire_Reid]

Hi,

So i do not believe this is a bug,  it is just a limitation of non-RT systems.

Please take a look at What Kind of Accuracy Can I Expect for Software-Timed Applications in LabVIEW? and Why are the Time Resolutions for Get Time/Date In Seconds and Tick Count Different?

[DBerry]

Claire,

I am running on a WindowsXP machine with a Intel Xeon processor.  I understand that teh timestamping process is software controlled, but I am only acquiring at 100-500 Hz and according to teh link you sent I should be able to get 1ms accuracy.  Not only am I seeing duplicate timestamps, but I am also seeing timestamps between points of more than 20ms.

If I am to use the sample clock timing to establish my dt between points, is there any way to determine how accurate my inital timestamp is for the wavefrom (i.e. t0)?

[Claire_Reid]

I understand that you have reached some sort of resolution with an Applications Engineer on the phone. Could you please update us on what yall determined. Also, I was going back to the code you attached earlier and I did not see the waveform chart on the front panel. After doing a bit more research you might want to use a waveform graph instead.

[Claire_Reid]

Also, here is some information about the accuracy of t0.

DAQmx uses the windows timer to get the timestamp t0, and it tries to account for the exact time the first sample was returned. Lets say this is a finite read operation and all samples are read in one call to DAQmx Read. t0 is calculated as:

            t0 = current system time when Read was called - (number of samples already acquired from)* (sample rate)

The data to the right of the subtract operation is to guess when the acquisition started. This is ok in most cases but not perfect. For example, the t0 calculation shown above assumes that the AI acquisition is still running when the read is called. So for example, if someone starts a finite acquisition of a 10 sec duration, but does not call Read VI until one hour later, then his timestamp will be off by one hour.

Note: DAQmx only gets the system time once during an acquisition (finite or continuous). If Read is called multiple times, t0 for subsequent reads is calculated based on:

              t0new = t0(from first call) + (sample rate)*(sample offset)

[DBerry]

Claire,

I have come to a resolution with Peter over the phone, more of an understanding than a resolution.  I am now using the Samp;le Clock rate to build my time array when saving data rather thean the timestamp operation for all of the reasons which have been discussed.  Basically I was looking for 2 things out of this:

1.  An accurate way to obtain the time of teh very first point acquiried

I was determined that this could not be done since this USB 6009 device does not allow Digital line syncing

2. A way to keep my waveform chart from randomly clearing

I have solved this by not plotting points that have the same timestamp as the previous (or less than)

Thanks

Dan

[Claire_Reid]

Thanks for the update. I hope the information I posted about the accuracy of the t0 helps you as well. Happy Thanksgiving!