receiving exception "resource requested by this task has already been reserved by a different task" for unknown reason

[lemieuxcw]

Hi folks.

I'm running into a bazaar error that I just can't get around.  I have a series of cDAQ chassis (9188's) with a number of NI 9208's in each.  All I'm trying to do is setup the simplest of simple acquistion VI's to pull data from each of the 16 channels of each 9208 and push the values to the UI.

NOTE: the hardware is currently SIMULATED in MAX.

I'm attempting to create a Task for each 9208, but DAQmx Start Task.vi bombs out after the code successfuly creates the first few tasks.  The exception:

"Error =200022 occurred at DAQmx Start Task.vi; Possible reason(s): Resource requested by this task has already been reserved by a different task".

Please see the attached screenshot.  I provided two arrays of Physical Channel constants. The currently wired array bombs out on "AI_Module_07".  The unwired array bombs out on the last one "AI_Module_08".  It seems I can move these constants around in the array, so there is little to no pattern behind the order.

There are also screenshot segments of MAX and the exception embedded in the block diagram.

Thanks a bunch.

-Chris

[lemieuxcw]

No ideas?

I should also add, I am using:

MAX ver 5.5

LabVIEW ver 2013 f2

DAQmx 9.7.5

Thanks!

[JÞB]

Well, lets see.

"unnamedTask<77>" is a pretty good clue..... and should give you a few ideas.  

First.  Name your darn tasks!  this will make it a lot simpler to troubleshoot when you write yourself a bug.

Next, Close your tasks when you exit or at least "unreserve" them with DAQmx Control Task.vi.

Third- close the DAQ wizard you have open somewhere.
 

[lemieuxcw]

Thank you for the response.  Some comments about your suggestions:

(1) Although I see the value in adding identifiable task names, it really has no bearing on the exception being generated.  This code snippet I presented was intended to be just about as simple and broken down (yet functional) as I could make it.  Nonetheless, I added back my Task identifiers just-in-case.  Same issue.

(2) Closing the tasks.  I always close the task(s) after I've completed a transaction.  But it's difficult to close a task that never gets around to proper initialization/instantiation.   Which is what I'm experiencing here.   

(3) I rarely if ever use the DAQ wizard - so it wasn't open.

For arguments sake, I completely rebooted the computer and fired up this test app only; no DAQ wizard, MAX remained closed, no other instances or apps that could be accessing DAQ resources.  Same issue - which is just perplexing to me.

Any other thoughts?

Thank you.

-C

[Dennis_Knutson]

Have you searched for the error? It's actually pretty common. Why are you creating so many tasks? Combine them into one.

[0utlaw · Accepted solution]

Hello Chris,

Based on the screen capture you provided, it looks like you may be using too many independent tasks in one chassis- I believe that the timing engine can handle three (Four from memory, but three according to this Knowledgebase) simultaneous AI tasks- you can certainly use all eight slots for AI, but they'll need to be partitioned into synchronized subsets.

That said, if this is in fact the problem then my impression is that a more specific error would be appropriate- the "resource" referred to in this case is ostensibly the timing engine, but additional clarification would be helpful.

Best Regards,

[lemieuxcw]

That must be it!

Yes, I researched that exception to death but nothing led me to this knowledgebase post.  I even did some degree of research regarding 'maximum number of allowable tasks', but never got specific enough to narrow that down to a max num of allowable tasks on a per-cDAQ chassis basis.  Nice find.

So a little more background to what I'm attempting to accomplish.  I have a slew of 4-20mA signals (obviously) coming in, that can be logically grouped together (i.e. temperature, flow, position).  However, those sensors (for reasons out of my control) are spread across these modules, and hence spread across the chassis.  Note they all have their own corresponding global channels with custom scalings, etc that I left out of this discussion (again, for sake of simplicity).

Originally, I wanted to (for example) group ALL temperature related measurements into a single task, group ALL flow measurements into a single task, etc.  However, because they're spread about (any one module can have more than one connected 'type'), I'd run into 200022 exceptions - but for obvious reasons.

So I tried to create a single task - lump them all in together.  Still, exceptions (one or more devices do not support multidevice tasks).  That wasn't terribly obvious to me - every module is of the same type...alas, abandoned that.

Then that brought be to more of an experimental mode - which led me to the code snippet (screenshot) you see here.  

At any rate, you are certainly correct - I brought this down to (4) tasks total (1) per chassis and it's just fine.  That was just a bit of info I simply didn't know about the cDAQ chassis.

Thanks!

[lemieuxcw]

BTW, not to divert from the original topic here, it sure would be nice to know why I couldn't just lump everything together into a single task without receiving the "one or more devices do not support multidevice tasks" exception.  If only for my own understanding.

Regardless, thanks again everyone for the responses.

-Chris

[0utlaw]

Hi Chris,

I believe the multidevice error is a limitation of the chassis - X-series DAQ cards (and perhaps some others) allow for clock synchronization between devices (and therefore shared tasks), but the cDAQ chassis you're using can't be synchronized to one another without using hardware triggering or a synchronization module such as the 9469 (the aforementioned timing engines run independently on each chassis.)

Regards,

[lemieuxcw]

Makes good sense.  Thanks again, Tom.

-C