Clear any open task daqmx

[ThijsBoeree]

Hi,

I was going crazy, because all of a sudden one analog output tasks didn't work any more it was saying it conflicted it with another 'still active' task... I searched my whole application. Couldn't find anything. So eventually i closed the whole labview application, and then it worked again, like magic. I came to the conclusion, that my stop and and clear task wasn't called when i closed my program in a different way.

So my question: isn't there a possibility to see which daamx tasks are active when you boot your program, so that you could clear any existing task?

Regards,
Thijs

[GerdW]

Hi Thijs,

have you tried to reset the device before configuring new tasks?

[ThijsBoeree]

Does that clear tasks in memory...?

[GerdW]

Just try it.

I can't as I don't have DAQmx installed at this computer…

[JÞB · Accepted solution]

Better yet,  DAQmx tasks really only need to be created once, Preferably during development and not at run time if you can avoid it at all.  Presist them to the project (if you deploy to a debug enviornment) or, to MAX if you deploy exe's.  This also lets your tasks be available for troublshooting and integration or even to a "Engineering SFP" for the station.  I can't remember the last time I delivered a solution the encluded DAQmx Create Task.vi. 

Its pretty easy to write yourself a little utility to abort and Unreserve all DAQmx Tasks.

[ThijsBoeree]

Ah! So there is a property node giving all the open tasks! 

I have 4 different tasks with the same hardware, so i make them when i start and when i close my program, but it can happen that for what reason my program crashes... This is very safe! I'll put it in the init phase of my application.

Regards!

Thijs

[JÞB]

---

@ThijsBoeree wrote:

Ah! So there is a property node giving all the open tasks! 

Regards!

Thijs

---

NOT QUITE! and be careful here.  That function gives you ALL Tasks the are known to the application context.  So any Tasks open in the current contex AND any Tasked Saved to the LabVIEW Project (regardless of state) AND any Tasked saved in MAX (regardless of state).  Some of those Tasks may have been deployed by another application- It would be rather rude of you to go deleting them and breaking someone elses application.  Of course, in such a case, the other developer should have siliently imported his *.nce file at app launch to prevent the user from doing bad things and touching what oughtn't to be touched.

[ThijsBoeree]

Maybe i should revise my application and reserve the 4 specific tasks in NI Max and then only close them at the end of my application?

[ThijsBoeree]

I always made my tasks programmaticaly and never thought about it.. I am persistent in naming the tasks...

[JÞB]

---

@ThijsBoeree wrote:
Maybe i should revise my application and reserve the 4 specific tasks in NI Max and then only close them at the end of my application?

---

Lets get the terminology clear  because you are confusing a Task "State" with a Task's existance.  Tasks aren't opened and closed and a reserved Task means something completely different that how you are using it.

Tasks are "Created" either programatically with create task.vi or using the DAQmx Wizard from the project explorer, a Task IO control/constant or MAX.  Once "Created" you can assign a "State" to a DAQmx Task.

Tasks may pe "Presisted", or saved, in a project or MAX.  All DAQmx Properties for that Task are then stored in a file somewhere in xml format where DAQmx knows to look for them.

Normally when a Task is created it is assigned a "State" of "Verified" meaning that the DAQmx Properties selected are within the device(s) capabilities (Or an error is thrown)  Once Verified a Task does not need to be verified again unless a property changes.  For most Tasks the act of transitioning to the Verified state is very fast.  With very complex Tasks you might notice a minor performance improvement by having saved Tasks that have been checked over before.

Your Tasks each have a set of hardware resources they use (Input channels, Timing sources, Trigger lines...)  When a Task attempts to transition to the "Reserved" State it gets an exclusive lock on the resources it needs (or an error is thrown stating some resource is not available usually because another Task is reservng it)  This is the error you were seeing.  You attempted to reserve a task when one or more resources was reserved by another task.  You can also explicitly transition Tasks back to the "Verified" state.  This releases all of the locks the Task had obtained.   The utility I provided will unreserve all resources without destroying any Task.  Since any of these Tasks could be in the "Running" State, simply "unreserving" them may produce an error since a running Task must either complete or be aborted.

This means that if you have multiple Tasks that need some of the same resources only one can be in the Reserved state at any one time but, all of them can exist in a verified state.

For more on DAQmx State Transitions see Seth's post here