How can we tell if a VI is already running before calling Start Asynchronous Call?

[Photon_Dan]

The new Start Asynchronous Call node is awesome for spawning multiple instances of reentrant VIs.  However, I've stumbled a bit in using it for non-reentrant VIs.  The old practice of using the "Run VI" method would allow us to check the Execution.State of the VI before invoking the method to run it.  That way if the State was Running or Run Top Level, we could skip the invoke node and just use a property node to open its front panel.  WIth the Start Asynchronous Call node, it looks like we have to use a strictly typed static VI reference, and when we open the VI reference, the VI gets reserved and its Execution.State = Running.  So, how can I tell if it is not just reserved by the thread but actually executing before making a redundant Start call?

By the way, the redundant Start has interesting behavior.  It will actually cause the targeted VI to be executed again after it stops.  Even if you hit the Abort button on the target VI, it will immediately execute again and again equal to the number of times the Start Asynchronous Call node was run.  There's nothing wrong with that, and I suppose the simple answer is to just go back to using the old "Run VI" method.  It's just that the ability to wire up those inputs directly to the connector pane is so nice.  Perhaps I am missing something obvious.  Oh, I am referring to the Call and Forget mode (0x80).

Thanks,

Dan

[Ryan-C]

Hey Dan,

What version of LabVIEW are you running?  I'm still trying to wrap my head around the question, but knowing the version number would help.

Thanks!

[Photon_Dan]

The Start Asynchronous Call feature is new to LabVIEW 2011, and that's the version I'm currently using.

[WayneS1324]

Maybe put a notifier inside of the vi? You could monitor this notifier from other vi's.

Sort of like a sign of life that you see from some hardware devices.

Just an idea.

[Ryan-C]

Yes, I like the notifiers idea.  Perhaps send notificationafter the VI finishes -- so, if you haven't received the notification yet, it means it's currently running?

I like this example as far as notifiers: http://zone.ni.com/devzone/cda/epd/p/id/4469

Best of luck,

[Ryan-C]

Dan,

Today I came across the solution you want, utilizing a VI Reference and a Execution.State Property Node: http://digital.ni.com/public.nsf/allkb/E5726FB3FD4ADF3586256F0E0069AAA8?OpenDocument

Best,

[Photon_Dan]

What I am seeing is that the Execution.State property always returns "Running" even if the VI is not actively running.  It is merely reserved for running by its parent.  My solution is to go back to using the old Run method from an Invoke Node.  All the creating notifiers and stuff is nice, but it requires extra code on both the caller and the subVI.

[mikeporter]

Sometimes the old technques are still the best. You know what they say about, "...if it ain't broke..."

Mike...

PS: You still in FL? Going to be at NI Week?

[JÞB · Accepted solution]

Perhaps I am missing something obvious.  Oh, I am referring to the Call and Forget mode (0x80).

---

Yeah- you forgot it forgets  Run method still seems to be a bit better choice for this mode

[p-rose]

Just throwing it out there, I know I'm a year.5 late on this but if it's a psuedo-modal dialog or some other window that you only want a single instance visible at one time, you can check the FP.State property on the strictly typed vi reference. If it's loaded and visible to the user it will be "Standard", if it was closed or not opened prior then the state will be "Closed".

I think the standard behavior of serializing execution on another thread would be great for doing a pre-set number of iterations with a sub vi in a non-blocking sort of way but for sub vi's meant for UI interaction checking FP.State works.