LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Timeout due to less amount of buffer size

Solved!
Go to solution

I'm trying to continuously acquire  in simulation mode. My sample rate is 400k . So based on sampling rate my buffer size will be allocated as 100k.then I'm trying to read 400k samples through read.vi. I'm expecting a timeout error. But it doesn't happen. I like to know the reason. By default Timeout in read.vi is 10 second.

 

Here actually the buffer size is 100k (host pc RAM buffer) only and my read.vi is expecting 400k samples. So I thought I won't able to get 400k samples. Whether timeout or buffer overflow error will happen like that I thought. But it doesn't so, without any error I got 400k samples per second. I like to know what is happening in between host pc buffer and daqmx read vi. 

0 Kudos
Message 1 of 11
(2,795 Views)
Solution
Accepted by topic author Manik981211

The buffer is just there to store data between reads. If your buffer is 100k elements and you ask for 400k, DAQmx Read will keep pulling samples out of the buffer until it gets to 400k. In the meantime, the actual DAQmx hardware is adding samples to the buffer at a rate of 400,000 per second. If you ask for 400k elements, that's 1 second worth of data, so DAQmx will wait for up to 10 seconds and give you the 400k samples. Since you generate 400k a second, it'll return in 1 second max.

 

Basically, the underlying transfer fills the buffer up at your sample rate, and DAQmx Read pulls data out of the buffer. DAQmx Read returns when it gets the requested data or sees an error.

 

I'm not sure why you think you'd see a timeout. If you start the task and let it fill the buffer without reading it, then you'll get a buffer overflow error. If you read the task with too small of a timeout (<1 second) then you'll get a timeout error.

 

(By the way, check out this link for a few considerations regarding timing etc for simulated devices: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019Nw0SAE&l=en-US)

Message 2 of 11
(2,785 Views)

Kudos!  I didn't know this.   I didn't know a call to DAQmx Read could return more samples than the size of the buffer.  It makes sense that it's *feasible*, I just didn't know it would actually work.  I don't think I've ever tried it (at least not on purpose).

 

I'm not around hardware now to test -- do you happen to know if the same is true for outputs?  Can it work to call DAQmx Write with more samples than the buffer size as long as your timeout is big enough?

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
Message 3 of 11
(2,755 Views)

I like to know whether the daqmx read has any memory allocation to store the pulled up data until it reaches the requested data. 

0 Kudos
Message 4 of 11
(2,736 Views)

Apparently (as this phenomenon is new to me too), the allocation for 400k samples is happening in the LabVIEW application space, *distinct* from the 100k sample buffer that DAQmx would have allocated for the task.

 

So you call DAQmx Read and ask for 400k samples from its 100k buffer?  What can it do?  Well, actually, it turns out to be pretty smart about things and says, "400k you want?  Then 400k you *get*.  I'll just keep waiting on the driver and device to keep pushing data into the 100k task buffer.  Meanwhile I'll keep pulling chunks out and putting them into your 400k Read array, which also keeps freeing up space in the task buffer so the device can keep pushing data into it. 

    By servicing the task buffer behind the scenes this way, the Read function prevents a fatal buffer overflow error.

 

I have a nagging feeling that none of this stuff was done automatically back in the days of traditional DAQ when I did my initial learning, and maybe that's why I never bothered to even *try* to do it under (the much improved) DAQmx.

 

Getting back to your specific question: there will always need for a separate memory space for the array of data that DAQmx Read returns to your app.  It will always be distinct from the task buffer memory space that's owned and controlled by DAQmx.  But it likely will only be allocated 1 time and then re-used for subsequent calls to DAQmx Read.  Generally, you don't need to be worried about memory allocation overhead when you run a continuous acquisition that loops over calls to DAQmx Read.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 5 of 11
(2,713 Views)

Thanks for your reply. 

0 Kudos
Message 6 of 11
(2,709 Views)

The fact that Kevin didn't know that is making me second guess myself, hah! I'm fairly confident I read an article about the double buffer thing and I'm pretty sure it does work that way, but in searching for the article I can't find it (thanks NI for constantly rearranging your website) and I don't have DAQ hardware on hand to test it. I manually configure continuous IO buffers so rarely that I can't think of a time when I needed to pull more samples out of DAQmx Read than the size of the buffer, so I realize I could have been mistaken. It clearly works for OP, but he's using a simulated device which doesn't follow all of the timing and buffer size rules exactly the same as real hardware.

 

Kevin, did you actually try this to verify I'm not just talking out of my rear end?

 

(All that said, I *can* verify that I basically never need to worry about buffer sizing unless I'm doing a very long acquisition before I can call Read.)

0 Kudos
Message 7 of 11
(2,646 Views)

Attached is an old presentation I found on NI's site awhile back. It does not answer the question here, but has some nice information, not sure if it is still valid, about buffers on DAQmx.

For example,

On a Compact DAQ chassis, an 8K FIFO is shared by all input and output devices, and is divvied up on a first come, first served basis

  • 2K for first two tasks
  • 1K for next three tasks
  • 0.5K for next two tasks


Commit DAQmx tasks in decreasing order of bandwidth requirement. For e.g. commit 8KS/s AI task before 1KS/s AI task.

 

 

0 Kudos
Message 8 of 11
(2,617 Views)

I had just a few minutes to give it a quick try with a slightly modified shipping example.   Sure enough, it works!   A call to DAQmx Read can successfully retrieve more samples than the buffer size of a continuous task's buffer!

 

(I deviated from the original 400 kHz sampling b/c the X-series 6321 device installed here maxes out at 250 kHz).

 

Output tasks didn't allow the opposite.  I got a DAQmx error for trying to call DAQmx Write with more samples than the buffer size.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
Message 9 of 11
(2,603 Views)

when I'm doing  daq write, if my sampling rate is 250k and number of samples is 250k then try to set buffer size as 100 even 10 but i'm not getting any error. I like to know the reason. Explain me what is happening.(simulation mode).I don't have hardware right now to check so that I'm doing 

 

thanks in advance

0 Kudos
Message 10 of 11
(2,582 Views)