Confusing behavior with DAQmx read (USB 6001)

[mike4]

I'm having trouble figuring out how to perform continuous analog input using DAQmx.   I am using a USB 6001 with Windows LabVIEW 2015.

I would like to read a single analog input channel continuously at 1 kHz.  I configure the channel for continuous reading with a sufficiently large buffer, then start the DAQmx task before entering the read loop.  During each iteration, I first do some other I/O, then I try to read all the analog samples that have been buffered since the last read.  The other I/O takes a variable amount of time, but never long enought to overflow the DAQmx channel buffer.

The problem I'm encountering is that, the first time I try to read the analog input buffer, I get an empty data set  -- no matter how long it's been since I started the task.  Then, the next time I try to read the data, I get the data that should have been returned the first time!  There are no errors, but the data is always one cycle out of date.

For example, let's say that after starting the task, I wait 5 seconds before attempting to read the the buffer.  I read zero points.  If I then try to read again after 1 second, I will get approx. 5000 points.  Then the third read will be approx. 1000 points, no matter how long I wait before performing it.  

The attached VI exemplifies this beavior.  Here, the read attempts are timed by pressing a front panel button.  It is easy to see the problem by looking at the approximate number of samples returned per millisecond of read interval, which should be ~1.

I've tried changing many DAQmx channel/read/timing/etc settings, and also several ideas from these forums, but am still stuck.  I'm sure (or at least hope) that someone will point out an obvious error with my approach.  The only thing I've found that affects this behavior is that, if I regularly poll the AvailSampPerChan property between reads, the data lag goes away for the second and subsequent reads.  The first read is still missing some (but not all) of the data -- and it only works if I am almost constantly polling the AvailSampPerChan property.  For example, polling it once, right before the read, doesn't help.  

Is there a flow-driven way to consistently read "fresh" analog input data with DAQmx?

[crossrulz]

I just cleaned up your diagram some, removed duplicate parts, removed the setting of the buffer size (really should not do this with a Continuous acquisition).  With a simulated USB-6212 (I already had it set up), it seems to work just fine.

[mike4]

Thanks for the suggestions.  I tried your cleaned up code with the hardware, but unfortunately I wasn't able to resolve the situation.  

The only way I was ever able to use this DAQ was if I set up a separate thread to constantly poll the "available samples per channel" field, e.g. every 5 ms, for the entire duration of the acquisition session.  Even then, there were bizarre and intermittent issues with data latency.  These would strike a few times per hour, so the system never quite worked right.

The permanent solution turned out to be getting a LabJack.  

I would be interested to know if this issue is common to the USB-6001, or if I just had a defective unit (or driver install).

[Kevin_Price]

One problem I see is that you're dependent on a user hitting the 'Read data' button fast enough that the DAQ buffer won't overflow in the meantime.

Your call to the DAQmx Read function does not specify a # of samples.  The default will be -1 which means "read all available samples".  Seems fine at first, but run your program while polling for # available samples and without clicking 'Read data'.  The value grows up to the buffer size, then resets to 0 when you start overwriting data in the buffer.  And subsequent calls to DAQmx Read return an error.

I'm not sure this is causing your immediate symptoms, but is something to understand for the future.

Your app looks like a case for an approach I've often used.  Sometimes I want a DAQ task to run continuously and overwrite its buffer, but at unpredictable moments I want to retrieve some of the most recently acquired data.  You can set this up with a DAQmx Read property node and by wiring a specific # samples to DAQmx Read.  Here's a link to a snippet I posted some years back to illustrate.

-Kevin P