no data returned on buffer overflow - bug in DAQmxRead?

[noaliaswhatsoever]

alternative title: annoying behaviour of DAQmx Read Analog 1D Waveform Nchan Nsamp (possible bug)

I have recently been forced to upgrade several of my setup-control programs from stably working NIDAQ legacy to the new DAQmx.

One of the more annoying errors I receive is the DAQmx -200279

(

DAQmx Read (Analog 1D Wfm NChan NSamp).vi<append>
<B>Property: </B>RelativeTo
<B>Corresponding Value: </B>Current Read Position

<B>Property: </B>Offset
<B>Corresponding Value: </B>0

<B>Task Name: </B>_unnamedTask<4>

)

which seems to be an overflow. I have selected the "overwrite unread samples" option for this task. When the overflow condition is triggered, the Read vi no longer is able to return all current datapoints (number of points per channel set to -1), however it will return data if said input is wired with less than the buffer size. This behaviour is inconsistent, and I consider it a serious bug, as I can never empty the buffer completely in case  of an overflow event.

Has anyone and idea how to coax Labview into returning all available data (or, alternatively completely empty the buffer) in case of a buffer overflow, in a way that does not require multiple readouts?

Much obliged,

GAB

[Kevin_Price]

Yeah, agreed, kind of annoying.  I found a solution for my app which may work for you.   However, I wasn't trying to read an entire buffer so I'm not sure.

I found that if I set 'Relative To' = 'Most Recent Sample', and 'Offset' = (-)# of samples I want, I could retrieve the most recent samples without getting the overflow error.  Perhaps you could use this method to read the entire buffer?

As I recall, the overflow condition didn't reset itself.  Once the first overflow flag got tripped, it remained tripped for the duration of the task.

Sorry, gotta go now, only time for a few quick thoughts...

-Kevin P.