Jump to content

On-demand analog task to timeouts?


mje

Recommended Posts

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.

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.