DAQmx Task ID missing in action

[jschwartz]

Hey Steve,

If no name is assigned to a task, DAQmx generates a task name of the format "_unnamedTask<0>". The generated name can be displayed by connecting a "task out" connector to an indicator or by probing a wire.

However, indicators and probes may display an empty string "" instead of the generated name in some cases. The reason is the task was cleared before the indicator or probe display was updated. This happens if a call to the DAQmx Clear Task is executed before the display is updated, or if the task is automatically cleaned up before the display is updated.

Solution

1) Display the name as a string rather than a DAQmx Task Name indicator. This causes the task name to be immediately copied.
2) Add a delay to prevent the task from being cleared prior to the indicators and probe displays being updated.

[Electromecha]

Thanks for the feedback fellas. 

It's clear to me that the probe and DAQmx VI's execute in different threads but the fact that the task can be cleared before the probe gets updated seems like a race condition to me that shouldn't exist in LabVIEW especially if the probe is directly upstream of the DAQmx Clear Task.vi.  It violates the LabVIEW data flow paradigm. 

I've been making logical decisions about clearing tasking depending on whether a task name exists, but now I'll be sure to convert the task name to a string and then make the comparison.

Thanks for your help.

Message Edited by Space_Flight on 07-09-2009 06:20 PM

[rkmadse]

Seems to me like creating a non-terminating VI defeats the purpose of utilizing AEs.... unless I am missing something about how you can still benefit from using an AE with a non terminating vi? 

--Kellen

[RavensFan]

Your message seems to have nothing to do with this 11 year old thread you posted into.  I suggest you start a new thread with your question.  Is it a question?  Or a comment to a completely different thread?

[rkmadse]

I was attempting to reply to Kevin Price, who stated that because of DAQmx's garbage collection there is no way to stuff a task id into an uninitialized shift register and have it still be there the following time around that you call the Action Engine. He suggested using a non-terminating VI and I was wondering the benefit of doing so vs. just not using an AE at all... I thought it was relevant but not descriptive enough I suppose. Sorry!

--Kellen

[RavensFan]

When replying to a message that isn't immediately before yours or obviously a part of the conversation thread, then you should use the quote button to quote the part of the message you are replying to.

[rkmadse]

Good call, I will make sure to do that going forward. 

---

@RavensFan wrote:

When replying to a message that isn't immediately before yours or obviously a part of the conversation thread, then you should use the quote button to quote the part of the message you are replying to.

---

[Kevin_Price]

I was attempting to reply to Kevin Price, who stated that because of DAQmx's garbage collection there is no way to stuff a task id into an uninitialized shift register and have it still be there the following time around that you call the Action Engine. He suggested using a non-terminating VI and I was wondering the benefit of doing so vs. just not using an AE at all... I thought it was relevant but not descriptive enough I suppose. Sorry! 

---

And whuddya know, I happened to run across this thread anyway so I'll venture a response, referring to what I said back in msg #2 of this thread.

The context of my thinking was about testing and troubleshooting the DAQ Action Engine.  Under the old legacy driver, I used to simply open the front panel of the AE and run the "Init" action, which would store the resulting task ID in a shift register.  On the next run, the task ID would still be valid and I could run a "Start" action successfully.

This no longer worked under DAQmx due to the automatic cleanup when the top-level AE went idle.  It caused DAQmx task refnums to become invalid.

The "non-terminating" vi I mentioned back in msg #2 was *not* referring to the AE itself, but to a simple test vi that would call the AE.  I'd make a simple gui with an enum for all the actions and a "Go" button.  Each time I clicked "Go", I'd call the AE with the corresponding action.  All this stuff was in a loop so that the AE never went idle and thus the task refs remained valid.

Basically, it was the simplest workaround to let me keep using DAQ AE's under the new regime of DAQmx.   These days I've been doing more with messaging systems like the QMH and don't tend to make AE's much any more.

-Kevin P