Slow While Loop with NI 9205

[HK45acp]

Hi all,

I'm having an issue getting a DAQ to run in a While loop faster than ~500 Hz.  I have an NI 9205 in an NI cDAQ 9185 chassis, running on a Windows 10 computer.

Using the NI MAX Test Panel, I can easily run it at a 100 kHz sample rate.  I confirmed this by sampling a known frequency sinewave and doing the math.  I don't know how the code is implemented in the Test Panel, but there's obviously not a hardware problem.

When I tried to run the DAQ in a VI, I can't get the loop to run much over 500 Hz, no matter what sample rate I enter.  The VI I used is the Voltage - Continuous Input Example (attached), set to get a single sample from a single channel.  I modified the While loop so that it calculates the "loop frequency" of the last iteration after clicking the Stop button.  (Circled in red in the attached jpg "Block Diagram-Right capture_LI.jgp".  The Waveform Chart/Graph was also pulled out of the loop.)  No matter what I do, I can't seem to get it much past 500 Hz.  Is reading the DAQ that slow?

Ultimately, I want to run 8 channels, 3 samples each (24 total) per loop, looping at 1 kHz.  This will be streamed to the hard drive (see Buffered Stream to Tab-Delimited Text File.vi example).  It needs to run up to 20 minutes.  Yep, lots of numbers!

What am I doing wrong?

Thanks!

[Kevin_Price]

I can't open your code as I'm only up to LV 2018 here.

There are generally 3 main things needed to maintain high sample rates, (and your rates aren't really into the realm of "high" just yet).  

1. Use a hardware clock to set sample timing.  Based on the name of the example vi you mentioned, I think you're already doing this.   It sounds like you want a sample rate of 3 kHz.

2. Read data from the task buffer in decent-sized *blocks*.  A common rule of thumb is to read about 100 msec worth of data from the task each iteration, leading to a read loop iteration rate of about 10 Hz.

    With a 3 kHz sample rate, you'd be reading 300 samples per loop instead of 1 or 3.

3. Use a Producer/Consumer pattern for any further work you do on the data, whether it's analysis, logging, graphing, etc.  This prevents your DAQ loop from getting bogged down which could lead to a buffer overflow error.

The original shipping example for continuous voltage input is a pretty decent starting point for these things.  (It doesn't implement Producer/Consumer, but it's only meant to be a simple example as a starting point.  I forgive it.  😊 )

-Kevin P

[santo_13]

You are using Read 1 Ch 1 Sample, which means you're software timing the captures which are often limited by driver and hardware. In your case, you can use Read multiple samples so that you don't need to fetch data from the instrument so often (configure the sampling clock to the rate you would like)

Please look at the example for continuous input.

[HK45acp]

Thank you for the reply.

My thought process was that grabbing a single measurement in a loop without a Wait VI would be the fastest the loop could run.  I could then slow it down to the rate I ultimately wanted.  I was surprised that it was so slow.

That is the VI I used: "The VI I used is the Voltage - Continuous Input Example (attached), set to get..."

[HK45acp]

Thanks for the reply, Kevin.

1. Use a hardware clock to set sample timing.  Based on the name of the example vi you mentioned, I think you're already doing this.

Check out "Front Panel capture.PNG".  I selected "OnboardClock", which was the only selection that didn't cause an error.  I'm assuming that is a hardware clock.

3. Use a Producer/Consumer pattern for any further work you do on the data, whether it's analysis, logging, graphing, etc.  This prevents your DAQ loop from getting bogged down which could lead to a buffer overflow error.

Sounds like a good idea.  I've never used that architecture before, guess it's time I learned (it looks simple enough in the template).

2. Read data from the task buffer in decent-sized *blocks*.  A common rule of thumb is to read about 100 msec worth of data from the task each iteration, leading to a read loop iteration rate of about 10 Hz.  With a 3 kHz sample rate, you'd be reading 300 samples per loop instead of 1 or 3.

My goal was to produce a data file (.csv) containing 8 channels of data, where each channel's measurements are ~1mS apart (1 kHz).  Ideally, these measurements would actually be the average of three consecutive samples for noise reduction purposes.  Perhaps I can acquire 3x the number of samples (and 3x the sample rate) and use the Consumer loop to parse and average before writing to the file?  That doesn't sound to bad now that I think about it.

Just to be sure I understand multi-channel/multi-sample, does the cDAQ (NI 9205, which is not symultaneous acquisition) collect one sample from each of the enabled channels, then loop back through them for the next samples, until the desired number of samples per channel are acquired?  The attached picture illustrates this for a case of 3 channels/2 samples.  Is that how it works?  If that's true, then 8 channels, averaging three samples to produce the 1 kHz effective sample rate for each channel would require a 24 kHz sample rate.  Is my math right?  (This assumes that any other overhead delays are small relative to the 24 kHz sample rate.)

Thanks for your help!

[Kevin_Price · Accepted solution]

Was away on vacation and just getting back to my open tabs.

Your thinking about 8 channels, 1 kHz logging, 3 sample averages is *basically* correct, except that NI and DAQmx define "sample rate" by the time it takes to acquire 1 sample PER CHANNEL in the task.   So the A/D converter would need to do conversions at 24 kHz as you surmised, but under DAQmx you would configure an 8-channel task for 3 kHz sampling.  Each "sample" would be 8 A/D converted values, one for each of the 8 channels.

The diagram you posted is not how samples are defined in DAQmx terminology.  Each time interval t = 1/(sample rate) would include A/D conversions for all 8 channels.

So again, configure for 3 kHz sampling, read about 300 samples at a time, and reduce those by averaging in blocks of 3.  There's a function named "Decimate (continuous)" that'll help a lot with the dirty work.

-Kevin P

[HK45acp]

No problem with the delay, I just got back today.

Okay, so I think I understand - NI made it easier (which is harder for people like me who are occasionally accused of overthinking things ;o) ).

Thanks for the tip on the Decimate (continuous) VI.  I wasn't familiar with it and it does look like it will save a lot of work.  Plus, I can wire a single control to change the decimation rate and sample rate (x 1 kHz) at the same time, to maintain the 1 kHz "apparent data rate".

Thanks!