LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmx Read All Available Samples (NChan, NSamp)

Solved!
Go to solution

I want to setup a DAQmx voltage task, sampling continuously with multiple channels.  I would like to setup the read loop DAQmx read function to read all available samples.  I will setup the read function for NChan, NSamp.  My question:  Will the function return waveforms with data up to the last complete channel scan?  Or will it return absolutely whatever is there, even if the channel list was partially sampled?  If it is the latter, I expect my waveforms to be different lengths (by one sample).  I would prefer the former - that it gives me data up to the last complete channel scan.  Then the remaining data would be available for the first complete channel scan in the next data set I read.  I couldn't glean this info from the documentation I found on the read all available samples property.

 

FYI, The DAQmx task will be on a PXI-1050 combo chassis, with a 6251 card controlling the SCXI multiplexed sampling of an SCXI-1102B.

 

Thanks!

Message 1 of 8
(2,071 Views)

I recommend not reading All Available Channels, but rather reading the specific number of channels you configured when you set up your Task.

 

For example, suppose you said "I want to read from AI0 to AI4, reading 1000 samples using Continuous Sampling at 1KHz".  You set up your DAQ device for N Channels N Samples.  The DAQmx Read has an input where you can specify how many samples (e.g. 1000) or leave unwired, in which case it default to -1, or "All the data that is present".

 

So you start the Task and immediately do a Read.  When do you get data?  If you left # Samples unwired, you'd immediately get some data, but you probably wouldn't get 1000 points.  If you said "Read 1000 points", you wouldn't get any data until 1000 points were collected (which takes 1 second), then you'd get all 1000 points.

 

Personally, I prefer the latter.  Note that the DAQ Read now becomes "self-clocking" -- it will loop one a second, giving you exactly 1000 samples each loop.  Since actually getting the data from the DAQ Read to a Wire probably takes a few microseconds, this means that you have 999+ milliseconds to "do interesting things" inside the loop before you need to be ready to read more data.

 

Bob Schor

Message 2 of 8
(2,068 Views)

Bob, I agree with everything you stated.  Let me add another nugget of info that explains why I would want to leave the number of samples unwired (-1) for this task and just get whatever is there:

 

I will have another task reading on a PXI-6123 card in my same DAQ read loop.  I want to read data from that task exactly the way you recommend, and let that read task drive the read loop rate.  The slower SCXI stuff - just get whatever is there and go crunch it.  I don't want to have to precisely manage the buffers, sample rates, and read sizes to perfectly match between the tasks.  I'd like to allow the user some range of specification for the SCXI stuff independent of the PXI stuff.  As I see it, one of the two tasks needs to read whatever is there (and move on) to keep the buffers in check.

 

Therefore, my question still stands as far as how the Read function handles returning NChan NSamp waveforms when you get all available samples.  Does it give you a partially complete channel scan, or up to the last complete scan?

 

Thanks!

0 Kudos
Message 3 of 8
(2,041 Views)

So if I said "You get all of the channels" or "You may get "split" channels", would you believe me?  Why not write some test code and see for yourself?  (If I had to guess, I'd wager my usual dime that you'll get all channels ...).

 

Bob Schor

0 Kudos
Message 4 of 8
(2,032 Views)

That's what I'm counting on.  Will report back after I round everything up.

0 Kudos
Message 5 of 8
(2,021 Views)

I will just state that I have never observed having a "partial scan" from a read.

 

But I would add to another reason to actually state how many samples to read: you won't have a bunch of memory allocations due to arrays/waveforms changing size.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 6 of 8
(1,994 Views)

I'd bet more than Bob's dime (heck, as long as I'm betting Bob's money, let's go big and call it a hundred bucks) that you will get the same # samples for all the channels, right up to and including the most recent complete scan by the multiplexer.

 

The other advice you're getting about requesting a specific # samples is 100% right in about 75% of circumstances.  As I see it, you're squarely in the other 25% and your reasons for requesting "all available" sound entirely valid for *your* circumstance.

 

A slight variation I've often used is to configure via DAQmx Read property node to read the most recent samples.  I usually pair this with another property that allows the buffer to be overwritten without generating an error.   These things serve a similar function of pulling recent data from the task without waiting while also allowing you to deal in a fixed size packet that might make other processing more efficient.  (Just be aware that the data packets may overlap or may have gaps in between.  You'd need an app that's agnostic to such things before using such a method.)

 

 

-Kevin P

0 Kudos
Message 7 of 8
(1,978 Views)
Solution
Accepted by topic author CDase

After running some code, I can confirm that with each read, I am getting the same number of samples for each channel in the task.  Of course the number of samples varies slightly from read to read, but all channels have same number of samples.

0 Kudos
Message 8 of 8
(1,912 Views)