problems with T0 in double buffered aquisition

[Numbster]

We are performing a hardware-timed, double-buffered analog input acquisition using a plugin board and SCXI hardware. Nominally, we measure at 2 Hz, reading 2 samples once per second. Acquisitions run for several days or weeks. We accumulate the SCXI data into a buffer for display on graphs. We also need to synchronize with other measurements that are software driven (not hardware timed) for writing to data files.

We are having problems with the timing, specifically T0 in the waveform we read. If we use a simulated device for (software) testing purposes, we have observed the T0 to run as much as 30+ minutes AHEAD of the windows clock!!

Additionally, we are seeing data repeats in the data file. We are using the SCXI data as the “master clock”, since most of the other data sources are software timed. This should be expected to generate data repeats on the other sources, especially since they all run slower than the SCXI acquisition. But, we are also seeing repeats in the SCXI data (file). We are trying to determine if it is a simple bug in our software, or a misunderstanding of the nature of the timing of SCXI control and the T0/delta T in the waveform.

Is this caused by the hardware clock and Windows being out of sync, or is T0 generated by Windows when the data is read from the buffer and causing problems? How is T0 generated for hardware-timed acquisitions after the first AI Read?

[Chad_A · Accepted solution]

Hi Numbster,

The t0 populated in the waveform that you get back from DAQmx Read is entirely software-timed.

As for how the t0 is generated, that will depend on what device family you're using to digitize your SCXI system:

For ESeries/MSeries/SSeries/USB/All Simulated Devices, t0 is latched after the first read completes. That t0 will be the system time when DAQmx Read.vi completes minus (totalSamplesAcquired-1)/SampleRate (seconds). If you start a finite task that and then don't call DAQmx read until 5 days after the task is done acquiring all its data, then t0 will be off by about 5 days (in the future). This behavior is described here: http://digital.ni.com/public.nsf/allkb/5D42CCB17A70A06686256DBA007C5EEA

For XSeries/SC Express, t0 is latched when DAQmx Start Task completes. This t0 will be pretty accurate as long as you don't have an external start/reference trigger. If you do have an external start/reference trigger, and you don't actually generate the trigger pulse until 5 days after you call DAQmx Start Task.vi, then the t0 will be off by about 5 days (in the past).

For all families, only the very first t0 calculation uses the sytem time.  Subsequent reads for the task just add the appropriate amount of time onto the initial t0.

And simulated devices can screw up the timestamp and, specifically, report that samples were acquired in the future. This can only happen in simulated devices.