Understanding Continuous Analog Input Buffer considerations with a USB 6225

[rpflughoeft]

I'm confused on handling continuous analog input in a vb.net environment. 

I run some of the vb.net samples BUT I'm not understanding why I'm not getting errors.

I've got to sample at 2000hz. I've got to read 40 channels. Since the spec (as I read it) calls out a buffer of 4095, I would expect the buffer to start overwriting after about 5.1ms. BUT when I use the continuous analog input examples that use a call back function function, it 'seems' that it doesn't generate an overflow even if I tell it the buffer is significantly > than 4095.  I 'suspect' that there is an overflow/overwrite but it just isn't creating an error.

That being said, since I'm trying to analyze about 10 seconds worth of data, I believe I have to have a different function/thread that fires about every 1-2 ms and reads from the USB 6225 and accumulates the data in another buffer. That seems straight forward enough but all the examples I find use the callback which (as I understand it) will generate a call back to my code once the buffer on the 6225 if full. This is of course problematic if I can't respond in time to turn off the waveform read, get the data, turn on the waveform read before I loose any crucial information.

So what this boils down to is

1) why am I not getting errors on the sample code when I gather more than 4095 samples

2) are there examples in vb.net (or c#.net) that show continuous analog input that don't rely on the callback function when a buffer is fulled.

For bonus points, when I try to modify the example so the the reader does not use a callback, it says to set it to input argument to null. I can't get my vb.net application to accept 'null' as and argument.

[rpflughoeft]

OK, here's my best guess what I'm supposed to do.

Set up a continuous read of all 40 channels at a rate of 2000hz. Set the #of samples at  approx 2000 to 3000. This should fire the callback routine when I've filled MOST of the samples worth of memory out of the 4095 sample FIFO. The call back routine will transfer the data out of the 6225 into a buffer in the PC. This way, even if there is a few milliseconds delay before the callback routine runs, the extra samples will be collected in the FIFO and I will pick them up on the next read.

Does this sound correct?

[Kevin_Price]

I can only offer a few general thoughts since I haven't used vb.net nor the USB version of the M-series boards.

I believe the buffer size of 4095 that you mentioned must refer to the 6225's on-board buffer.  A very key point to bear in mind is that your task is usually NOT limited by the on-board buffer.  The DAQmx driver will also create and service a much larger buffer in system RAM.  Behind the scenes, it will handle the transfer of data from the board to your system RAM, and when you perform a Read from your task the data will come from RAM.

So the reason you aren't getting errors is that DAQmx has done you some favors automagically, and is using the much more plentiful system RAM to buffer data until you can read it.  Essentially, it's doing the job you thought you would have to do manually.

Sorry, I can't point you to specific examples of syntax but can let you know that you should be able to get there from here, and it's liable to be simpler than you were expecting.

-Kevin P

[rpflughoeft]

I suspect you speak the truth.  

I can continue to wrestle with the vb syntax. Do you have a link to something that shows the relationship between the on board memory, the RAM buffer built/maintained by DAQmx and the RAM buffer that I need to transfer data into for my processing?

[Brandon_G.]

Hi rpflughoeft,

Check out this link here on NI Signal Streaming Technology.  There is a lot of good information in this Dev Zone that explain the architecture on how data from your DAQ is transferred to your PC RAM.

Cheers!

Brandon G.

[rpflughoeft]

Thanks Brandon.I'll check this out in the AM!