topic Re: simultaneous asynchronous VI's with Notifiers in LabVIEW

simultaneous asynchronous VI's with Notifiers

pblase — Wed, 09 Mar 2016 21:06:51 GMT

I have a program that needs to open several independent control panels in subpanels, using the Start Asynchronous capability. It reads the device and the appropriate vi panel from an xml file, starts it asychronously - passing in the name for this particular instance and the name of a notifier with which the sub-vi can pass back its reference (which is not returned from the Start Asynch block, as per the help files). The main program then inserts the sub-vi panel into the appropriate sub-panel.

I've created a minimal program that replicates the problem.

This vi does the hard work:

Here is the sub-VI that is called (which, in its full version does a lot of other stuff):

The sub-vi receives its designator from the main VI at the Start Asynch block, copies it to an indicator (uses it to initialize other stuff in the full version), and sends back its "this vi" reference via the Notifier. It then proceeds to loop until the global "stop" is set by the "Stop" button in the main program.

The end goal here, BTW, is that I can have control panels set up for similar pieces of hardware that may or may not have completely different underlaying interfaces. So long as the connector scheme looks the same, I just set up the xml file to indicate the appropriate vi and run it.

So far as I can tell, the proper names and stuff are being read from the xml file and passed to the Start Async block, and the Notifer seems to be working properly (more or less). Two problems:

1) When the sub-program starts running, the "Designator" control is not set appropriately and is not being copied to the "Designator 2" indicator. I have been unable so far to figure out if the same clone is, in fact, being started twice or if there are two clones and the front panel is simply not being intialized properly. The bar control and indicator in the loop work properly.

Note that both say "MC-1" and the indicators are blank.

2) When the first unit runs, the Notifier returns "Error 1": (in the attached program this isn't shown until the program stops, but it actually occurs immediately upon the "Release Notifier" call.

Possible reason(s):

LabVIEW: An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.
=========================
LabVIEW: An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.
=========================
NI-488: Command requires GPIB Controller to be Controller-In-Charge.

Any suggestions would be welcome. I've reviewed the help files and the boards, and can't see anything obvious.

Re: simultaneous asynchronous VI's with Notifiers

Bob_Schor — Wed, 09 Mar 2016 21:49:29 GMT

Well, that's a very clever idea to have the Clones report back their identity through a Notifier. I just ran your code (had to delete a missing Global and change where the XML was saved, but it "mis-behaved" in the same way you saw). Actually, while typing this note, I had an "aha?" moment -- I want to go back and check something.

While reviewing the various option flags, I grew curious about 0x40. I'm not sure I understand when/how this is used, and don't really think it's applicable, but when grasping at straws ...

Bob Schor

Re: simultaneous asynchronous VI's with Notifiers

crossrulz — Wed, 09 Mar 2016 22:03:03 GMT

I don't see the point of the Notifier at all. You already have a reference to the VI when you call it with the ACBR Node. Why not just use it?

Re: simultaneous asynchronous VI's with Notifiers

Bob_Schor — Wed, 09 Mar 2016 22:06:31 GMT

Well, I tried a few more things. I missed entirely that you used the 0x40 option in your Open VI Ref, so I tried removing it -- made no difference. I noticed you passed the Notifier to the Clone, but didn't use the passed Queue -- I did (I didn't re-create it in the Clone) -- made no difference. You remarked that perhaps you were calling Clone 1 twice in the sub-Panel (though clearly you see MC-2 displayed in the Message Box), so I made an array of references (as you did), but saved them as U32's -- yes, they are different. It remains a puzzle (sorry) ... [More ideas are buzzing around my head ...]

Bob Schor

Re: simultaneous asynchronous VI's with Notifiers

drjdpowell — Wed, 09 Mar 2016 22:26:10 GMT

I suspect your "Designator" issue is that the indicator is set before the Front Panel is loaded. Try opening the FP before writing to the indicator.

0x40 creates a reference to a pool of clones. You only need one pool, so move the Open Reference function outside your For Loop. You also don't need to name your notifier; just pass it in.

Re: simultaneous asynchronous VI's with Notifiers

pblase — Wed, 06 May 2026 16:00:25 GMT

Sorry about the global. The x40 option tells the Start Asynch node to run the clones as separate threads.

https://www.ni.com/docs/en-US/bundle/labview-api-ref/page/vi-lib/dlg-ctls-llb/start-asynchronous-call.html

If you set the 0x40 option flag when you open a reference to a target VI, the Start Asynchronous Call node starts a call to a clone of the referenced VI, not to the referenced VI itself. Therefore, if you call a VI Server property or method on the original reference that the Open VI Reference function returns, the effects of that property or method are not reflected in the VI clone that the Start Asynchronous Call node actually calls. To perform VI Server tasks such as opening or positioning the front panel on the VI that is actually called, you must call the property or method within the reentrant VI itself.

Re: simultaneous asynchronous VI's with Notifiers

pblase — Wed, 06 May 2026 16:00:46 GMT

Because I don't. When called with option x40, starting multiple clone copies simultaneously, the Asyncronous Start node (https://www.ni.com/docs/en-US/bundle/labview-api-ref/page/vi-lib/dlg-ctls-llb/start-asynchronous-call.html) returns a reference to the main vi not the clone.

Re: simultaneous asynchronous VI's with Notifiers

pblase — Thu, 10 Mar 2016 14:44:17 GMT

"don't need to name the notifier" I was experimenting. I tried it both ways, same result.

Re: simultaneous asynchronous VI's with Notifiers

pblase — Thu, 10 Mar 2016 15:28:14 GMT

Yep, that solved that one. I put the indicator inside of the second sequence block and wrote out to it, and it updated fine. Then I created a local variable for the control and put it into one of the sequence blocks, writing the control value back out to itself, getting rid of the indicator.That worked too.

Now I wonder, why wasn't it working when I wrote the control value out to the indicator outside of the sequence block? For that matter, why isn't the control updating its displayed value properly?

Re: simultaneous asynchronous VI's with Notifiers

pblase — Thu, 10 Mar 2016 15:33:02 GMT

I wonder. Will something nasty happen if I simply don't dispose of the notifier reference in the subVI?

Re: simultaneous asynchronous VI's with Notifiers

pblase — Thu, 10 Mar 2016 15:49:34 GMT

Ok, there is definitely something weird going on here. If I put the "Release Notifier" block inside of the Sequence Block, it works.

Combine this with the Designator problem, which is also solved by putting a local variable to the "Designator" control inside of the sequence, and the rule seems to be: don't write to anything unless it's inside of a sequence block.

Re: simultaneous asynchronous VI's with Notifiers

drjdpowell — Thu, 10 Mar 2016 18:55:44 GMT

@pblase wrote:
Combine this with the Designator problem, which is also solved by putting a local variable to the "Designator" control inside of the sequence, and the rule seems to be: don't write to anything unless it's inside of a sequence block.

The rule is, if things must happen in a specific order, enforce that order. You have two threads racing to destroy a Notifier reference (note you "Force destroy" input in your main VI) and one thread racing to load a front panel before another sets an indicator on that not-yet-created front panel.

Re: simultaneous asynchronous VI's with Notifiers

pblase — Fri, 11 Mar 2016 14:17:53 GMT

But there are two different references. The subpanel is only destroying the reference that it obtains locally, and the main thread doesn't destroy the thread until after it has received the answer back from the subvi. And this doesn't explain the control behavior.

Re: simultaneous asynchronous VI's with Notifiers

drjdpowell — Fri, 11 Mar 2016 14:48:26 GMT

and the main thread doesn't destroy the thread until after it has received the answer back from the subvi.

The main thread potentially force-destroys the subVIs notifier before the subVI releases it (why are you force destroying anyway?).

And this doesn't explain the control behavior.

You can't do something to the front panel till the front panel is loaded.