Sample at 200KS/s

[tecno40]

I am working on writting a LabView program to collect and graph data samples at a rate of 200kS/s. My DAQ supports 250KS/s so I know this is possible, however when I run a loop in LabView to collect the samples it runs at a much slower rate, limiting my ability to collect data. I tried adding a timed loop, however the 1MHz option was disabled on my machine and the fastest loop I could find was one that has a period of 1ms (1,000Hz), which would not be fast enough to sample at the rate I need. Does anyone know how I could go about created a system to collect samples at a faster rate? Is there an option that I could be using other than a loop to collect samples?

[James.M]

Your device is able to do 250kHz using its own timer, you can't loop that fast to pull in the data. Configure your DAQmx clock to the speed you want and then acquire chunks of that data in your loop instead of just one datapoint at a time.. Your DAQmx task will store the data in a buffer and then let you pull from that buffer.

Please include a Snippet of your code, or attach your VIs, so that we can better assist you. We are here to help, but won't spend all day recreating your code from scratch.

Here's a greate resource to become familiar with DAQmx.

[Oligarlicky · Accepted solution]

You have to grab many points per cycle. Have you seen this example?

https://forums.ni.com/t5/NI-DAQmx-Examples/Voltage-Continuous-Input/td-p/3528891

[tecno40]

So I read over the examples you provided and I got a LabView program that is able to sample at 200,000kS/s, save the samples to a buffer and then process them in a loop at its leisure. The only issue I'm running into is occasionaly when I run my code it will show 0V being outputted when I'm reading a known signal of 40kHz. I know it's an issue with my code because I've tried multiple computers & DAQs and the sample provided works fine even when my code is reading 0v. I'm trying to figure out what's causing it, but it's got me stumped. I've attached my code below for reference (note that I set it to read 20,000kS/s for testing purposes).

[RavensFan]

You still haven't fixed your VI.  You are still only reading 1 sample at a time.

Until your fix your so that you are capable of reading 200kS/sec, then any results you are getting now are meaningless.

[James.M]

You're still only pulling 1 sample out at a time...

You also don't need to use a graph indicator. Just use a Chart and right the chunks of data directly.

[natasftw]

You've been told the problem several times by different people.  Let's try another route.

You're wanting to sample at 200kHz (keep in mind, the k there is the extra 3 0s.  You don't want 200,000kS/s)  You have a device that is designed to handle that rate.

You're working with a While Loop that will only read one sample at a time (instead of N samples). 

Think of a stop sign versus a traffic light.  If you have a line of cars, they can get through the intersection either way.  With the stop sign, they're limited in speed simply because you've added the overhead of the stop sign.  They must speed up and stop with each car in front of them.  While the cars can easily reach a higher speed, your design simply won't allow it.

If you replace the stop sign with a traffic light, a good chunk of these cars can flow through the intersection at once.  This mitigates the problem you were seeing with the stop sign.  If you had a long enough traffic light, you wouldn't see much of a delay.

With your code, you have that stop sign.  It doesn't matter how fast the device can acquire the data if you're only asking for one point in each iteration.  That means your maximum sampling rate is determine by the while loop and NOT the DAQ device.  The MHz clock is disabled because you can't use that on Windows.  Really, you shouldn't even be looking at the Timed Loop on Windows.  You're adding overhead to the While Loop without having any benefit from doing so.  You want to remain with the While Loop.  You just want to modify the DAQmx VI to be acquiring N samples instead of 1 so that it can build up a buffer of points.  Each time the loop iterates it will pull all of the elements out.  This rate is ~100-150Hz.  I suspect that's the "much slower" rate you've seen so far.

[Hooovahh]

Good analogy.  How about this though.  Reading single point is like the light changing to red after each car.  Reading multiple samples at once is like having a trailer with N cars on it go through the light all at once.

[James.M]

And if you put a random number input to the Samples To Read, it's like a roundabout.

Sometimes samples have to loop around again before getting out.

[tecno40]

Ok, I revised the VI to take in X samples per loop where X=samples per second/desired loops per second. My originally understanding was that if I buffered the data, the DAQ would hold it until my slow 1 sample per loop collector could get the data. Is the issue with this methodology that eventually the buffer will fill up and dump the data? Also could someone take a quick look at the new VI to ensure it actually is collecting 200KS/s? If it's not it could create some funky results for the rest of my program.