Continuously creating, configuring, starting, and clearing a DAQmx task leads to -50103 The specified resource is reserved.

[AVieira]

Hello everyone,

Hardware: cDAQ-9174 with two modules, NI 9263(Outputs) and NI 9215(Inputs).

I'm running a loop that executes Nexec times the following tasks:

- Configure and execute an output task.

- Configure and execute a read/write task with both modules, registered to a callback when finnished.

   . Read values, being acquired, in an inner loop.

   . Wait for the callback to be executed, where I clear booth in/out tasks.

- Configure and execute an output task. Like in the first step.

This loop runs, say, Nerror times until I get error -50103. In every execution mentioned above I create, configure, execute and clear a task many times over (3 times per loop run, as indicated above).

Here's a bit on the error's behaviour:

> Most of the times the loop runs many times before encountering the error. In this case Nerror can be as big as 500 good runs without an error, though usually between 20 and 300.

> Sometimes, rare but happens, the error happens many times straight as a loop execution is attempted (mind that the error -50103 stops the loop and user input is required). In this case Nerror is usually small, like 8 good runs before I get the error, each of the successive tries. (Pretty annoying for the user.)

For reference, each execution of the loop is arround 1 to 5 secs long and the software I'm developing needs to run the loop for something like 1024 times, i.e. Nexec=1024. This makes for somehting like a hole hour to execute a complete loop.

I've combed my code and have error reports being generated every time a DAQmx function is executed with details about it and I can't figure out why I get this error. Before starting a task I make sure to clear it! I've even gone to the extreme of clearing the task many times before creating it again, with DAQmxClearTask(), which seems to reduce the error's frequency.

I've found KB on this issue:

  http://digital.ni.com/public.nsf/allkb/485201B647950BF886257537006CEB89

where the causes for this error are described.

I'm still hoping that it is some error with my code (means its fixable), but given that Cause 2 in KB indicates that the error can happen just by creating and clearing a task many times, I need to ask. Is this a known issue? Even if my code is ok I may sometimes get this error with this archytecture (creating and clearing a task every time I need to do something)?
If so I could try to fix it by having my code "try again" until it works, clearing all tasks each try.


Thank you very much,

If concrete code is required let me know and I'll make it available.

Arthur V.

[edjones93]

Hello Arthur,

I'm struggling to locate the known issues page for DAQmx to verify if this is indeed a known issue. However I do have a suggestion, depending on the configuration changes you are making, you could just uncommit and re-commit the task while making changes during this. This will allow you to perform re-configuration without clearing the task continuously, I have included a document on the DAQmx Task Model below:

https://zone.ni.com/reference/en-XX/help/370466AC-01/mxcncpts/taskstatemodel/

I have also included documentation on the code which allows you to change the task state:

http://zone.ni.com/reference/en-XX/help/370469AD-01/lvdaqmx/mxtaskctrl/

Hopefully this should resolve your current issue, keep me apprised as to how it goes.

Best regards,

Ed

[AVieira]

Thank you for your reply. I will examine it in the comming days.

Right now, to handle the issue I made my software roboust against this error by just trying again if it shows up. Every time it happens I log it as a known error, so I'll be able to assess it's behaviour later. As it is a rare event it should have close to none negative impact on my application to retry if it happens. I have checked that, at least in a few cases, trying again once is enough and the second try is successful.

This "creating and clearing" architecture is useful to me as multiple instances of my software will compete for access to the device. So it's important that when one instance is idle it clears it's tasks so that the modules are free to be accessed by another instance.

Thank you very much.

[edjones93]

Hello,

Could you clarify the architecture? As long as you have a main constructor and destructor (start and end case) you could still implement the commit and uncommit, use a global variable to store the task handle across all instances of the application however also implement a semaphore.

Here is some documentation on semaphores:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms686946(v=vs.85).aspx

Best regards,

Ed