LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

Is there a DAQmx Destroy task?

I'm a beginner with DAQmx so this may be a simple question, how do you destroy/get-rid-of/remove a DAQmx task? There's a DAQmxCreateTask but I have yet to find a way to get rid of it. My problem is I have DLL and DAQmx tasks that are created as programs call it based on who is calling. As they leave I do a DAQmxClearTask. But if calling program starts back up and calls the DLL again, I get a "Task name specified conflicts with an existing task name".
 
Thanks
 
 
"Lockheed" Joe
Testing Blog"
0 Kudos
Message 1 of 12
(6,501 Views)
To stop a task, use the DAQmx Stop Task.vi, and to remove a task from memory use the DAQmx Clear Task.vi.  Both of these are available in the DAQmx pallette in LabVIEW.

If you have any further questions please let us know.  Also be sure and consult the examples located in the LabVIEW Example Finder (Help >> Find Example) for examples of how to program DAQmx tasks.
Elijah Kerry
NI Director, Software Community
0 Kudos
Message 2 of 12
(6,470 Views)
Lookheed,

i am not sure if i understand the issue.
As far as i understand you use a DLL written by someone else which requires DAQmx-task. These tasks are created in your application with DAQmxCreateTask (which is in fact the correct way 🙂 ). You pass theses task to the DLL and it works fine if you run the application once or at least in the first "cycle of execution". After leaving the DLL you clear the tasks by using DAQmxClearTask.
Now the program loops and tries to create the tasks again. And here the issue with "Task name specified conflicts with an existing task name" occurs. Is this correct?

If YES, i asume the following: You pass the task by value to the DLL (which copies the value!) and use it in the DLL. But you never unload the DLL during runtime, so the copy of the task(name) is still in memory.
Possible solution: Either create/clear the task within the DLL or change it to call by reference at least.

hope this helps,
Norbert B.

[Edit]: Or you could unload the DLL explicitly by some functions like UnloadExternalModule (remark that this stated function is obsolete in CVI 8.0 and later!) to get rid of the DLL. Maybe this could work for you too.

Message Edited by Norbert B on 02-23-2007 03:20 AM

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 3 of 12
(6,467 Views)
DAQmxStopTask and DAQmxClearTask apparently don't clear the actual task name. I use the clear task but next time a create task with the same name is attempted, it craps out. BTW, I'm using CVI instead of LabVIEW (LabVIEW makes my carpal tunnel syndrone flair up if I use it very much)
 
 
"Lockheed" Joe
Testing Blog"
0 Kudos
Message 4 of 12
(6,459 Views)
Lockheed,

i just played around a bit with DAQmxCreateTask(,) and DAQmxClearTask() and i must admit that i cannot reproduce your issue. The task is deleted in a proper way and creating a new task with the same name again is no problem. But this seems to be the problem in your application.......
So i am asking for two things: first check if the issue i described in my first post could be possible and second if this doesnt help, please create a small example showing this issue without using the DLL. Otherwise, i still blame the DLL to create this rather odd issue!

Norbert
Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 5 of 12
(6,454 Views)

Lockheed,

I would like to know if you have made any progress with this problem.  I am in the process of writing a DLL that uses DAQmx as well, probably for the same reasons that you are.  I wanted to ask you if you are calling your DLL from a single process and thread.  If not, there is a good chance that a second task is attempting to be created while the first is still in use.  Another thought is that the DAQmx library may also be delaying the actual distruction of the task; that you may need to add a delay to allow it time to happen.  NI claims to be multi-threaded now, but this can just add even more complexity to what used to be simple code.  I wonder if we can turn that feature off?

0 Kudos
Message 6 of 12
(6,398 Views)
 I see exactly the same behaviour as LockheedJ while using the DAQmx DLL (nicaiu.dll) in Matlab.

 I load the library, create tasks with DAQmxCreateTask, read data, clear the task with DAQmxClearTask and then unload the library. If I then try to create the tasks again, using the same task name, the call to DAQmxCreateTask fails with "Task name specified conflicts with an existing task name." To avoid this error, I tried DAQmxDeleteSavedTask (because it takes a task name as a parameter) and DAQmxResetDevice, but to no avail. The only way I have found to recover is to restart Matlab.

 If there's a way to clear the task name, so I can perform many create-clear cycles using the same task name, I'm keen to hear it.

BTW, task names seem to be pretty useless because you pass it once to DAQmxCreateTask and then you can only use the task handle thenceforth... or am I missing something?

jwq.

0 Kudos
Message 7 of 12
(6,285 Views)

Data Acquisition Toolbox for MATLAB uses DAQmxCreateTask and DAQmxClearTask successfully to create and remove tasks.  However, we do randomly generate task names to ensure that we don't accidentally create conflicts, which may (inadvertently) avoid the problem.  If I remember right, another option is to use the feature of DAQmxCreateTask to allow an empty string as the task name, which will cause it do be autogenerated.

-Rob

-----
Rob Purser
Manager, Test and Measurement
MathWorks
rob.purser@mathworks.com
Message 8 of 12
(6,270 Views)

To get around the problem, I cleared all the names in the CreateTasks and only create unnamed tasks. I guess I'm not sure what the task name is good for.

Also, I'm using CVI and not LabVIEW (LabVIEW makes my Carpel Tunnel problems flare up due to all the mouse work) so I can't try the suggestion with the LabVIEW vi's.

Message Edited by LockheedJoe on 04-30-2007 07:11 AM

"Lockheed" Joe
Testing Blog"
0 Kudos
Message 9 of 12
(6,271 Views)
Thanks Rob and LockheedJ, passing an empty string as the task name avoids the conflict altogether.

0 Kudos
Message 10 of 12
(6,233 Views)