Error -200022 Resource Reserved Using Tasks on Different Modules

[nasa-rand]

In a cDAQ-9179 , in slots 1, 2, and 3 there are three NI-9230 (BNC).  They have all of their channels grouped into a task called ACC setup in Max with continuous samples at 1k rate.  In the same chassis at slot 7 is an NI-9207 with all of its channels grouped into a task called AI setup in Max with continuous samples at 1k rate.  The tasks are read by calling DAQmx Read (Analog 1D DBL NChan 1Samp).vi with its error out wired to DAQmx Clear Task.vi.  If the tasks are run with with the previous Clear error out wired to the DAQmx read (reading in sequence) then all works.  If I disconnect that error line to run the tasks in parallel then one or the other will throw Error -200022 Resource Reserved.  These tasks do not have a module in common and both are set to internal clock.  What resource might be blocking parallel execution?

          

[mcduff]

Without seeing your task, cannot tell. Just tested with a simulated device and they can run in parallel.

[nasa-rand]

I also am able to run them simultaneously in MAX.

I always set my tasks up with the DAQmx configuration VIs because then the config travels with the project rather than having to export it from MAX, but I inherited this project.

I configured these tasks using DAQmx and all is working fine.  I'm not sure why configuring these in MAX and calling the tasks from LV caused this problem but I'll just go though and do the rest of the tasks in DAQmx and delete everything from MAX.

Thanks for taking the time to look at this mcduff!

[Kevin_Price]

This is only a guess but I wonder if both MAX tasks, being configured statically and in isolation, may have internally "decided" to try to use the "ai" timing engine.  Then when trying to run them in parallel, only 1 of them can succeed and the other will post a resource error.

But when you do all the configuration dynamically with DAQmx calls in app code, DAQmx is smart enough to know in real time that after one of the tasks uses the "ai" timing engine, the next AI task will need to use "te0" or "te1".  (Or maybe there can be others.  The few times I've dealt with this were on chassis that only supported up to 3 AI tasks.)

-Kevin P

[mcduff]

---

@Kevin_Price wrote:

This is only a guess but I wonder if both MAX tasks, being configured statically and in isolation, may have internally "decided" to try to use the "ai" timing engine.  Then when trying to run them in parallel, only 1 of them can succeed and the other will post a resource error.

But when you do all the configuration dynamically with DAQmx calls in app code, DAQmx is smart enough to know in real time that after one of the tasks uses the "ai" timing engine, the next AI task will need to use "te0" or "te1".  (Or maybe there can be others.  The few times I've dealt with this were on chassis that only supported up to 3 AI tasks.)

-Kevin P

---

That’s a good theory. Interesting that it is still hidden if you convert the task to code. 

can the OP upload the DAQmx tasks?

[nasa-rand]

I have attached the MAX configuration (nce changed to txt) which contains all of the tasks setup on this machine.

I did try Advanced Timing > Timing Engine > 1 for one task and 2 for the other.  That made no difference.

[mcduff]

I don't use thermocouples, but in your task you specify 1000Sa/s for a temperature measurement.  For both the DAQmxTask VPETS RTD and DAQmxTask VPETS TC the SampleClk.Src is left blank. (I do not know what that means.) I did not think TC measurements would sample that fast unless using another clock for synchronization purposes.

What happens if you lower the temperature measurement to 10Sa/s, or something similar?

[nasa-rand]

You are correct.  I have tried changing those values also without any change to the problem. I put them back to the original values as I was moving through testing different theories so I didn't end up with multiple changes to the original setup.

I have setup these tasks in DAQmx and am running them in 4 independent loops.  When running just the two tasks in question all works well but as soon as I add in either the TC task or the RTD task then the problem occurs; however, if I leave the RTD and TC tasks running and remove either the AI or ACC task then all works well again.  Additionally if I add a timing delay to one of the loops then the behavior also changes and then one of either the TC or RTD loops will also display the error at a longer interval apart than I see from the AI or ACC tasks.  I am setting up some demo/experimentation VIs and testing different configurations.  I'll let you know what I find and/or post some example VIs for your perusal.

Thanks again!

[mcduff]

One more question. You want to run these at the same time, why not just one task with everything in it?

[nasa-rand]

I could group the AI and Accelerometer channels but the thermocouples and RTDs sample rate is much slower.