DAQmx setup for high resolution, multi channel scan and graph

[cl0]

Hi,

TL;DR: I wanted to see if someone more experienced could provide some guidance on the DAQmx functions to help me efficiently read multiple channels sequentially at the highest sampling rate achievable by a DAQ device. I would like to read 3 ms of data across 24 channels in a while loop. Each channel would be read at 250 kS/s and my program will loop through all 24 channels sequentially.  My target loop rate (reading all 24 channels) is 250ms. Is this possible, or is there a better way to do this?

Hardware: NI USB-6218, Windows 10 machine

Software: LabView 2017 Full Development Edition

NI DAQmx driver: 17.0

--Detail--

I am trying to use three USB-6218 DAQs to sample and graph 72 analog inputs (RSE) at the highest sample rate the DAQ can support (250kS/s). I am doing this by creating an individual DAQmx task for each channel and splitting all tasks across the three DAQs. 

The main signals of interest are on the order of 10kHz and I would like to view ~3ms of data (750 samples) on each iteration of the loop but there are aperiodic noise/dropouts that occur across all channels that are much higher in frequency (50-120kHz). I am also interested in viewing these 'broadband' noise bursts. Each graph does not need to be to be synchronous as I am hoping to capture the phenomenon on at least one channel.  

The problem I am running into is that because each task is currently hardware timed, I believe that a DAQmx Start/Stop/Control call must be included in my main loop (not sure if this is true). This appears to be slowing down my acquisition significantly.  I have a sequence structure that is used to time the Start Task, Read, and Control (I am using 'unreserve'), as well as the overall time required to scan through all 24 channels per DAQ.  For the former, it appears each channel on average takes about 31ms. For the latter, each DAQ takes about ~800ms to run through all 24 channels.  

Based on what I've read so far, it appears that software timing will not be able to achieve a resolution better than 1ms (I am on a Windows 10 machine).

What I've tried:

To try to alleviate this, I used a producer-consumer structure to queue up data but upon using the Tools->Profile->Timing it appeared that the majority of the timing overhead was coming from the DAQmx function calls, not graphing. 

I then attempted adding all channels to a single task, starting the task outside of the main loop, and then using channel property nodes to select a single channel at a time per iteration of the main loop, using an incrementing counter to iterate through all 24 channels. The instance of the DAQmx Read in this case was the '1 channel N samples'. This appeared to make the loop run much faster; however, the returned data was an empty array and I got an 'ADC overrun' error.  

I have not experimented with changing the convert rate/sample rate clocks, or using external clocks. I am not sure that this would be the correct way to go.  

Apologies in advance for not including code - my company policy does not allow me to upload. I appreciate any help greatly!

[crossrulz]

I'd be tempted to just get a USB-6255, which has 80 analog inputs and claims a faster sampling rate than your USB-6218.  Then you can just use 1 task to sample everything.

[cl0]

I appreciate the suggestion and will look into upgrading the hardware--however, I would still be interested in seeing if there is a workaround with the hardware I currently have, if nothing else but for the sake of learning.

My limited understanding is that the onboard clock for each DAQ can only be reserved for one task at a time. Could I get around this by providing an external clock reference? Or is there something in DAQmx that could allow me to get the Start/Stop/Unreserve workflow?

Thanks for the help.  

[Kevin_Price]

Try these things:

1. 3 total tasks, one for each device, 24 channels per task.

2. 3 total calls to DAQmx Read -- one for each task.  Read multiple samples from each task's 24 channels all at once in a single call to DAQmx Read.  Don't loop over calls to retrieve data from only 1 channel at a time.

3.  Look into the producer-consumer pattern so you can defer graphing, file writing, post-processing, etc. into loops that run in parallel to the data acq loop.

4.  Trying to run loops at 333 Hz (for 3 msec of data per iteration) isn't ideal.  A long-standing rule of thumb is to iterate at something like 10 Hz, making a more efficient tradeoff between driver overhead and human ability to comprehend individual updates.

5. You should configure your tasks for continuous sampling.  You only need to start them once, before entering your main service loop.  In the loop you should only do DAQmx Read calls.

6. The profiling tool isn't perfect.  In fact, I've only very rarely found it to be useful.  Many others *have* found it useful, so I won't make any wide-ranging categorical claims.  Just that whenever I find myself wanting to investigate CPU usage in more detail, the profiling tool has almost never given me actionable info.

   Some kind of producer-consumer pattern *IS* a good idea, regardless of what the profiler might say.  The time "spent" on DAQmx calls in the profiler may be primarily just time spent waiting for new samples to accumulate.

   Again, I'm an odd duck on this stuff.   Many highly respected folks around here seem to be pretty content with the profiling tool and the "show memory allocations" option.  For whatever reason, I've gotten very little of value out of either one.  So my advice is not to overrate what the profiling tool tells you.  I rarely bother with it any more after years of trying it and finding I needed to largely ignore most of what it tried to tell me.

-Kevin P

[cl0]

Sorry for the late response - a few things came up so this got pushed aside temporarily.... Here is the latest update:

Steps 1, 2, and 5 were implemented. I did not try a producer-consumer architecture yet (step 3)

Step 4: I did have a 'Wait' wired to a 1 ms delay just to prevent excessive CPU usage per NI's recommendation for while loop timing). The rate I believe was really a factor of the Start/Read/Stop overhead, and me reading 3 ms of data.  

The resulting program looped much faster but I received an ADC error after the DAQmx Read.  Error -20019: ADC conversion attempted before prior conversion was completed. 

The DAQmx functions allow for the user to 'break' the rule of exceeding the max aggregate sample rate of the device (n channels * sample rate) IF the task is set up for 'Continuous'.

So the code will be able to run, but the hardware does not appear to be able to keep up.  If setting up the task for 'Finite Samples', an error will be generated and the code will not run.  

Still not sure if a solution exists out there but I do appreciate your input Kevin_Price. I will be wary of the profiling in the future. 

[rwunderl]

---

@cl0 wrote:

The DAQmx functions allow for the user to 'break' the rule of exceeding the max aggregate sample rate of the device (n channels * sample rate) IF the task is set up for 'Continuous'.

So the code will be able to run, but the hardware does not appear to be able to keep up.  If setting up the task for 'Finite Samples', an error will be generated and the code will not run.

---

Just because DAQmx allows you to do this, it does not mean you are getting data at 250 kS/s PER channel. This is impossible with this hardware unless you implement what you first suggested: run the task on only 1 channel at a time.

My understanding is this is what you would have to do:

• Reserve all 3 USB devices at the same time
• Create 72 tasks, 1 per channel with 750 Finite Samples @ 250 kS/s
• In a loop iterating over the 72 tasks:
  • Start, Read, Stop each task in turn (do not Clear the task)

OR

• In 3 parallel loops iterating over the 24 channel tasks of the 3 different devices:
  • Start, Read, Stop each task in turn (do not Clear the task)

then

• Aggregate the data in a separate loop
  • Possibly synchronize using some event
  • (But you've already said you don't care about asynchronous display)
• Graph the results
• Clear the tasks on application stop.

I don't know if any of these things returns a DAQmx shared resource error or something without trying it for myself.

You also do not need to add a Wait to any loop that is timed by a DAQmx Read. A 1-ms Wait in a 3-ms Read loop should be a no-op anyway, but it is unnecessary (especially if the loop stops on-error).

The data acquisition loop(s) should do nothing but DAQmx Reads (and requisite Starts and Stops, but this is unusual to have in a loop). The data needs to be passed to a separate loop for aggregation, display, and/or logging.

If you have tried all of this and it does not get you the update rate you desire (4 times per second), then you probably just need to do as previously suggested and get a device with better specifications.

[Kevin_Price]

I think rwunderl read through your requirements closer than I did for my prior reply.  😞

Bottom line: the device you have is not capable of satisfying all the requirements you laid out.  You either need much more capable device(s), or you'll have to make significant compromises somewhere in your requirements.

You've tried one approach: 24 tasks per DAQ, 1 channel each.  Loop over a Start / Read / Stop sequence for each task.   (You won't benefit from any "DAQmx Control Task" calls in your situation.)   Each iteration collects 3 msec worth of data at 250 kHz but the overhead of getting the task started and stopped bumps your loop time up to about 31 msec.  So you end up with 10% active acquisition time and 90% overhead.   And that only gives you a peek at 1 of 24 channels per DAQ device.  Any particular channel's behavior is only observed well below 1% of the time.

   That's *one* possible compromise and you didn't find it satisfactory.

Another is to set a 10 kHz sample rate with 24 channels per task to stay within the 250 kHz aggregate sample rate your device is spec'ed for.   This could run continuously and all channels would be observed 100% of the time.  But they'll be observed at a 10 kHz rate rather than 250 kHz.   This may not be a high enough sample rate for the observation / measurement you're doing.  (Although, depending on what kind of signal properties you need to characterize, there are some special rare occasions where *undersampling* can give you good results.  Check out this fairly long and thorough thread for example.   But also keep in mind some caveats described here.)

The main other "compromise" is the wallet, shelling out big $$$ for hardware that's capable of meeting your original requirements. 72 channels at 250 kHz is far from trivial but should be possible.  It ain't gonna come cheap though.

-Kevin P

[cl0]

Hi all, I realized I never followed up and just wanted to say thanks for the help.

I ended up continuing with the approach but grabbing 9ms per channel which was just enough to allow me to observe the behavior I was looking for.  The overhead scanning through all channels ended up being something around ~30 ms per channel with the start/stop/unreserve but luckily this worked out for the project and the signals of interest.  

Won't mark it as solved as I don't want to confuse anyone looking for a similar solution but for future reference if I come across something similar I will be sure to look at posts that others have included.

Thanks again!