simultaneous asynchronous VI's with Notifiers

[pblase]

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.

[Bob_Schor]

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

[crossrulz]

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?

[Bob_Schor]

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

[drjdpowell]

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.

[pblase]

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

http://zone.ni.com/reference/en-XX/help/371361L-01/glang/start_asynchronous_call/

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.

[pblase]

Because I don't. When called with option x40, starting multiple clone copies simultaneously, the Asyncronous Start node (http://zone.ni.com/reference/en-XX/help/371361L-01/glang/start_asynchronous_call/) returns a reference to the main vi not the clone.

[pblase]

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

[pblase]

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?

[pblase]

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