09-21-2017 02:18 PM
I'm trying to understand the function of the parameters "rate" and "samples to read", when continuously acquiring data. I've made a simple VI where I'm continuously acquiring data from a simulated device (NI-9237) for a set amount of time (2 seconds). Initially I thought that the number of elements in the array would be equal to the rate * seconds that the VI is running. So if my sample rate is 2000 hz for 2 seconds I should have 4000 elements. Instead I'm seeing that the number of elements is equal to the value I set as the "number of samples". Can someone explain what I'm doing wrong? My end goal is I want to be able to acquire a pre-determined amount elements, thanks.
09-21-2017 02:46 PM
Try testing what you want to do in MAX, where you can immediately (without writing any code) see what happens.
The usual scheme when acquiring data is to have hardware that you say "Take N Samples from M Channels at a rate of X Samples/second". For the purpose of discussion, let's say 2000 Samples from 1 Channel at the rate of 2000 Samples/second. If you choose Finite, then when you start the (single) conversion, the device will "think" for 1 second, and then deliver you 2000 samples in an array (or a Waveform). If you choose Continuous, when you start the conversion, it will again "think", deliver 2000 samples, then go back to "thinking" (actually, "acquiring") and be prepared to deliver another 2000 samples a second later.
If you want to take 4000 samples in 2 seconds, you have a choice -- you can acquire (once) all 4000 samples by specifying 4000 as Samples and 2000 as Sampling Rate, wait the 2 seconds, and voilà, your data. Or you could acquire 100 samples at 2KHz, put this in a loop that runs 40 times, and every 50 msec you'd get another 100 samples (you might want to view the data as it is coming in, rather than wait until you have everything in hand).
Or consider the situation where you want to sample for an hour. You probably don't want to collect data in one huge array for an hour, then write one enormous file to disk, but rather continously "acquire some data, save, acquire more data, save" in such a way as to not "miss" any data. LabVIEW, with its Data Flow model of operation, makes this very easy to do.
Bob Schor
09-21-2017 03:08 PM
Ahh well that makes sense. So the reason the # of elements = number of samples in the VI is because I'm generating X number of samples every loop iteration. Is this correct?
And is it correct to say that data is being generated in arrays of size = number of samples, so If I'd like to view data as it is coming in, I have to combine all the arrays as shown? Or is there a simpler way?
09-22-2017 04:47 PM
Are you trying to learn LabVIEW on your own? I notice that you have Express VIs (including the Dreaded DAQ Assistant) which are fine for doing the simplest tasks without understanding what your are doing (such as NI Sales people giving Intro to LabVIEW talks to undergraduate students -- grrrrr), but tend to hide the "important details".
I assume you have LabVIEW. Look at the Examples (Help, Examples). Find Hardware. Look for Analog Input, Continuous sampling.
Here's the basic idea -- when you sample Continuously, you depend on the Hardware to "clock" your code. If you are sampling at 1KHz, the hardware will deliver N samples every N/1000 seconds (1000 samples in 1000/1000 seconds, 10 samples in 10/1000 = 0.01 second). If you want to see your data evolving, plot it using a Chart (which shows the latest but scrolls to possibly show earlier, as well).
The Principle of Data Flow (a central Principle of LabVIEW) means you can do several things as the same time, such as acquiring samples, showing some or all of the data as it comes in, and stream it to disks, all in separate, asynchronous loops (so you can be sure they aren't interfering with each other). Note that you can choose to display something other than "every point" -- for example, if you are sampling at 1KHz, if you took 100 points at a time, and plotted the average, you would see a slowly-evolving (chart) plot of a "smoothed" aspect of your data, viewing 10 points a second scrolling across your Chart.
Bob Schor