DAQmx two Input Tasks using different Physical Channels - Resource Reserved error

[A_Tamalonis]

I am wondering if there is a simple solution to my problem, or if I need to re-architect how I am acquiring data.

Measurement goals:

• Continuously gather Analog Input data on one channel at a 'fast' rate (1kHz) by writing that data to a buffer and reading data off of that buffer
• Periodically sample single values from a different analog input physical channel, but on the same hardware device, at a slow and non-critical rate (~10-100Hz)

Ideally these two measurements would be happening in separate SubVIs (actually DQMH modules) and they wouldn't need to be aware of each others existence.

My problem is the continuous measurement task is reserving the hardware so the other loop cannot sample the other physical channel, resulting in a "Resource Reserved" -50103 error until the continuous task is stopped. I see this issue on all three simulated devices types below. If I change the Physical Channels so that two different simulated hardware devices are used for the two tasks, both loops can acquire data simultaneously.

Simulated Hardware:

• cDAQ 9132 w/ 9215 module (4 simultaneous Analog Input channels)
• USB-6009
• USB-6363

Since the 9215 module has four ADCs and can acquire simultaneous analog input data, I was hoping I could read from each channel independently as well. While the Analog Input task is running, I am able to write to Analog Output channels just fine, even when using a USB device for all physical channels.

In the attached example (LV 2019), if you have real or simulated hardware you can set the two physical channels on the front panel and obverse the behavior I described.

Is there a DAQmx property or setting that can help resolve this issue?

A possible solution is to use a single task with both channels reading at the faster speed, send that task to both loops, and process the multi-channel data appropriately. I wanted to contain the scope of each loop, as the plan is to break these into separate DQMH modules, one that is constantly acquiring data and another that occasionally checks for a value. Another option might be having a DAQ module which collects all data and distributes it on request. Either of these options seem overly complex compared to initializing two separate DAQmx tasks for different physical channels.

Thanks for any help or advice.

Edit: There's some relative info here https://lavag.org/topic/5900-ni-daqmx-error-50103-the-specified-resource-is-reserved/ with one user suggesting a Singleton module that handles all hardware requests, so that might be the route to go with.

[RavensFan · Accepted solution]

---

@A_Tamalonis wrote:

Is there a DAQmx property or setting that can help resolve this issue?

No.  Unless you replace your DAQ device with something much more expensive that has multiple timing clocks.

A possible solution is to use a single task with both channels reading at the faster speed, send that task to both loops, and process the multi-channel data appropriately. I wanted to contain the scope of each loop, as the plan is to break these into separate DQMH modules, one that is constantly acquiring data and another that occasionally checks for a value. Another option might be having a DAQ module which collects all data and distributes it on request. Either of these options seem overly complex compared to initializing two separate DAQmx tasks for different physical channels.

Thanks for any help or advice.

Edit: There's some relative info here https://lavag.org/topic/5900-ni-daqmx-error-50103-the-specified-resource-is-reserved/ with one user suggesting a Singleton module that handles all hardware requests, so that might be the route to go with.

---

That would be the correct idea.  One task, sample both channels at the higher rate.  Then you can decimate data or average results to reduce the sample rate on the channel you don't want high rate data for.

[A_Tamalonis]

Thanks @ravensfan I appreciate your comments.

I'll have to rethink the architecture a bit to make that work smoothly, but it shouldn't be too hard/complex.

[Kevin_Price]

Just to clarify -- the specific "correct idea" would be that one and only one DQMH module should read from the data acq task.  How you further post-process and distribute the data is up to you after that.   

The main point I wanted to emphasize is: do *not* send the DAQmx task ref to 2 distinct parallel modules!  That's the same kind of no no as having 2 consumers of the same queue.  Each would only receive part of the info that way.

-Kevin P

[A_Tamalonis]

Thanks for clarifying Kevin. I was leaning away from sharing the DAQmx task, but it's useful to have that  justification for why.