02-21-2007 08:22 AM
02-23-2007 12:00 AM
02-23-2007 03:13 AM - edited 02-23-2007 03:13 AM
Message Edited by Norbert B on 02-23-2007 03:20 AM
02-23-2007 06:44 AM
02-23-2007 07:01 AM
03-06-2007 08:04 PM
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?
04-29-2007 06:46 PM
DAQmxResetDevice, but to no avail. The only way I have found to recover is to restart Matlab.04-30-2007 07:08 AM
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
04-30-2007 07:08 AM - edited 04-30-2007 07:08 AM
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
05-02-2007 08:35 PM