Time stamps not linear

Question

Hi,
I have a DAQ USB-6251 driven by labview.
The time stamps on the text file have backward and forward jumps in them.  See attached for picture.
They increase linearly for about 12000 samples, then jump backwards
about a 3 sec, linearly increase for about 1000, then jump forward
about 6 seconds.  This cycle then repeats ie increasing nice and
linearly for about 12000 samples, jumping back etc.
I suspect there is a buffer somewhere which fills up and then acts strangly when trying to reset.
Any explanations?  Any solutions?
Here's some further info about my setup:
Producer loop:
I generate a continuous analog output signal which I feed back into one of analog input pins which I also continuously acquire.
The generation and acquisition both have sample rates of 4096
samples/sec and 1024 samples are set to acquire/generate per loop.
The recorded input is enqueued.
Consumer loop:
Dequeues data and write to text file.
Regards,
Jamie
Using Labview version 8.0
Attachments:
time stamps not linear.jpg ‏17 KB

Answer 1

Ben,
Maybe this is a good chance for me to learn (be convinced of) something then.  I'd try this out for myself on hw, but I've got tests running now.
Let's suppose I have both an AI and an AO task, both set up to start off the same sample clock.  However, the AO outputs on the leading edge of a clock while the AI samples on the trailing edge of the clock.  Let's further stipulate that the clock is generated by an on-board counter at 5 kHz with 90% duty cycle.  So the AO update occurs 180 microseconds before the AI.  How do waveforms handle this offset in t0?  Will t0 simply be set to 0 because of the use of an "external" sampling clock?  Or will the two t0 values be equal and non-zero?  Or will they be sometimes equal and sometimes different, depending on the "phase" of the system clock -- either the 1 msec one or the 16 msec one used for system timestamps?
Now, concerning triggering:  Does t0 represent the time of the trigger?  Or of the first sample / output *after* the trigger?  Or is it the time you call DAQmx Start prior to receiving a trigger signal?
Other concern: even when not *strictly* necessary, I try to make a habit of making code that runs pretty efficiently, unless that puts an undue burden on development / maintenance effort.  My experience with processing large arrays vs. processing clusters containing large arrays has suggested that pure arrays are typically significantly more efficient to manage.  (I'm sure it depends on sizes and kinds of processing too.)  Aren't waveforms essentially cluster-like?
Well, enough of the blah, blah, blah.  I really *am* interested.  I know many of the analysis functions prefer (if not require) waveform inputs rather than raw arrays these days, so there are some clear code simplicity advantages to waveforms IF I can be convinced that I'm fully informed of the downsides and gotchas.  (Another example of worry: when integrating a waveform, how does the floating point roundoff accumulate from the 'dt' value?  Will results late in a long array contain more cumulative roundoff error?)
-Kevin P.