When trying out a new program most error messages that LabVIEW gives me are not very helpful because they refer to "unnamed task" such and such.
And so I would like to give names to my tasks.
It ought to be simple but still it illudes me. So now I ask... How do I give a name to a task so that error messages then will be helpful?
5 replies to this topic
#1
Gan Uesli Starling
-
- Premium Member
-
- 37 posts
More Active
- Location:Holland MI, USA
- Version:LabVIEW 2011
- Since:2007
Posted 20 July 2012 - 11:25 PM
"Democracy is two wolves and a sheep voting on what to have for lunch..." Ben Franklin
#2
Ton Plomp
-
- Premium Member
-
- 1,980 posts
How many lines per hour? Zero!
- Location:Netherlands
- Version:LabVIEW 2012
- Since:2000
Posted 21 July 2012 - 08:27 AM
You can do this in MAX, or with the LabVIEW function 'New DAQmx task':
Ton
Ton
#3
torekp
-
- Members
-
- 161 posts
Very Active
Posted 22 July 2012 - 08:43 PM
But beware: if one of your threads closes the task, and then another tries to access it, you can get the old unnamed task error, I think. I'm pretty sure I've done this bellyflop at times.
#4
asbo
-
- V I Engineering, Inc.
-
- 1,273 posts
I have no idea what you're talking about... so:
- Version:LabVIEW 2011
- Since:2008
Posted 23 July 2012 - 01:22 PM
If that's true, that's really annoying - the wire of the task has the name of the task in it.But beware: if one of your threads closes the task, and then another tries to access it, you can get the old unnamed task error, I think. I'm pretty sure I've done this bellyflop at times.
#5
Aristos Queue
-
- Premium Member
-
- 2,641 posts
LV R&D: I write C++/# so you don't have to.
- Location:Austin, TX
- Version:LabVIEW 2011
- Since:2000
Posted 23 July 2012 - 02:20 PM
The following post is an area I am *not* an expert in. Please contradict me if you know better...
asbo: I'm not sure if this is the case with this error, but my understanding is that many of the errors reported by DAQ are designed with real-time in mind where even in the error case they avoid allocating memory -- i.e., no strings in the error code clusters. This means that all you get is the static text that can be obtained from the error code number itself. Much of the DAQ code was written before there was a conditional disable structure, so special casing the behavior on desktop wasn't an option. I have seen some recently written VIs that behave differently and give more helpful errors in the non-RT case.
asbo: I'm not sure if this is the case with this error, but my understanding is that many of the errors reported by DAQ are designed with real-time in mind where even in the error case they avoid allocating memory -- i.e., no strings in the error code clusters. This means that all you get is the static text that can be obtained from the error code number itself. Much of the DAQ code was written before there was a conditional disable structure, so special casing the behavior on desktop wasn't an option. I have seen some recently written VIs that behave differently and give more helpful errors in the non-RT case.
#6
asbo
-
- V I Engineering, Inc.
-
- 1,273 posts
I have no idea what you're talking about... so:
- Version:LabVIEW 2011
- Since:2008
Posted 23 July 2012 - 11:25 PM
Thanks for the insight, AQ. I'm going to write a test case to look into the desktop behavior of this, just out of curiosity, but the point you make about RT use cases makes a lot of sense.
Later: In LabVIEW 2011 with DAQmx v9.3.5, you *do* get the task name as part of the error message, in a fairly retrievable way. Further, you can probe task wires to see the task name and you can typecast/coerce task wires to strings to retrieve the task name. Somewhat disappointingly, a property node can no longer retrieve the name.
I don't have a RT box available to me, but I still expect AQ's guess to hold true.
Later: In LabVIEW 2011 with DAQmx v9.3.5, you *do* get the task name as part of the error message, in a fairly retrievable way. Further, you can probe task wires to see the task name and you can typecast/coerce task wires to strings to retrieve the task name. Somewhat disappointingly, a property node can no longer retrieve the name.
I don't have a RT box available to me, but I still expect AQ's guess to hold true.
