On-demand analog task to timeouts?

[mje]

I have an analog input task that I periodically read on-demand-- that is no buffering or timing. A task is created with DAQmx Create Channel (AI-Voltage-Basic).vi, when I need data, it is read using DAQmx Read (Analog 1D DBL NChan 1Samp).vi. Simple. I do the read with a zero timeout. To me this means since there's no timing/buffering happening the read operation should just do whatever it needs to read the data and return.

 

After a seemingly arbitrary amount of time though, I get a timeout error (-200474) from the read operation. This is not a "how do I fix this issue" post: I know it's really just a matter of putting a reasonable positive timeout on the operation. I'm more concerned with what causes the issue and if the returned error is appropriate.

 

So it seems that timeouts can happen even when not using buffered modes. The device is not being used for anything else, so it is not like it is busy with more demanding operations.

 

If you set timeout to 0, the VI tries once to read the requested samples and returns an error if it is unable to.

 

I get this, and to me it makes perfect sense in buffered operations. If I'm operating at a fixed acquisition frequency and I try to read before the next acquisition, sure a timeout can happen. But when operating on-demand is the timeout error expected behavior?

 

If something is preventing the device from being able to read that data when requested I would expect error information to be returned regarding the problem, not a timeout error. This isn't a buffered operation, I'd like to know why you couldn't read the data when I asked! Maybe I'm just unlucky and every so often I try to read the value just as the internal registers are being updated on the device, who knows.

 

I guess for tasks like this I need to think of a timeout as to a limit on execution time, not a limit on waiting for available data. Just seems weird to me. This is the first time I've done unbuffered acquisition since...well since I first started playing with LabVIEW over a decade ago. Maybe I just need to reframe my thought process.

[hooovahh]

Just wanted to post to let you know you are not alone.  I have seen this and was confused so I ended up taking a finite amount of data (100 points or so) then averaged them.

[Tim_S]

Hrm... My initial thought is that the resource may not be available at the moment that the read occurs. The zero timeout wouldn't permit the read to retry when the resource becomes available.

[todd]

Is it one of the devices that has a SAR ADC, so more than one sample is needed?

[mje]

I'm not sure of the nature of the ADC that lies under the hood, I'm working of a USB-6341.

 

I agree with Tim_S that it's likely the resource just isn't available when I happen to make the call. There has to be something going on under the hood because this error creeps up seemingly after random periods of time: could be after a few thousand reads, could be after a few hundred thousand. Part of me though expected this layer of hardware interaction to be transparent. Nothing is explicitly interacting with the hardware, so the fact that it's unavailable likely means there's just some issue with my request happening at exactly the wrong time according to some internal clock the ADC is likely running at. "Likely" because there's not a lot of information to debug this with. This is all eerily familiar to when I have to break out low level SPI communication with ADC chips...

 

The return of an error makes sense when you think about it: on time critical loops jitter could be introduced. If a zero timeout is wired the VI better well honor it, even if "waiting" would be just one iteration of some internal clock equating to a few nanoseconds for a register to become available.

 

Still though, it seems...weird. All of my LabVIEW experience has taught me to think of AIO timeouts in terms of data availability with respect to buffered acquisition, not hardware availability due to some hidden stuff going on under the hood.