Is it possible to pass a static VI reference into Start Asynchronous Call?

[JKSH]

Hi all,

 

If I pass a static VI reference straight into Start Asynchronous Call, I get Error 1576: A Start Asynchronous Call node received a reference input that was not configured to allow asynchronous calls.

 

The documentation says that the reference must be "'prepared for asynchronous execution by the Open VI Reference function using either the 0x80 or 0x100 option flag". The simplest way to accomplish this (that I could find) is to first get the path from the static reference and then use that to open a new dynamic reference:

 

That works, but feels a bit clunky. I don't suppose there's a way to apply the option flag directly onto the original static reference?

Edited September 5, 2015 by JKSH

[mje]

Not that I'm aware of, although that sounds like an excellent idea.

[Yair]

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-Asynchronous-Call-By-Reference-with-Strict-Static-VI/idi-p/1662372

[hooovahh]

That works, but feels a bit clunky. I don't suppose there's a way to apply the option flag directly onto the original static reference?

The only improvement I can suggest is to use the VI Name instead of VI Path.  If you're attempting to use this on a VI that hasn't been saved yet, obviously the path will return not a path.  The VI Name works because the VI is already in memory, it has to be because it is a dependency of the calling VI when you put down the static VI reference.

[JKSH]

The only improvement I can suggest is to use the VI Name instead of VI Path.  If you're attempting to use this on a VI that hasn't been saved yet, obviously the path will return not a path.  The VI Name works because the VI is already in memory, it has to be because it is a dependency of the calling VI when you put down the static VI reference.

Ooh, is it possible to obtain a VI reference by its name? Open VI Reference has "VI Path" as a compulsory input (and no VI name input)

[eberaud]

I think it's polymorphic. Try wiring a string to the path input.

[hooovahh]

I think it's polymorphic. Try wiring a string to the path input.

Yup, wire a string or a path to the VI Path terminal and it accepts either.  The VI name needs to be the full qualified name including libraries, but the VI Name property node returns it in this form.

[smithd]

The only improvement I can suggest is to use the VI Name instead of VI Path.  If you're attempting to use this on a VI that hasn't been saved yet, obviously the path will return not a path.  The VI Name works because the VI is already in memory, it has to be because it is a dependency of the calling VI when you put down the static VI reference.

Also I think I remember reading the performance of this is better.

 

 

 

More generally, is this something that could be Xnoded? I don't personally have the skills for it, but it seems like its a pretty straightforward adapt-to-type deal.

[ShaunR]

More generally, is this something that could be Xnoded? I don't personally have the skills for it, but it seems like its a pretty straightforward adapt-to-type deal.

 

You have the skills for a VIM, though

[hooovahh]

More generally, is this something that could be Xnoded?

I think so...it could even have the right click option to wait on the response or not.  I started going through the idea exchange and I probably found 10 or more ideas that could be done today using XNodes, this one is just another to add to my list.  

 

I think the most complicated part (not that it's impossible) would be the terminal generation, based on the VI reference wired.  You'd probably have to get the connector pane options as an image (which exists) for the node image, shifting it slightly just like the call by reference does today.  Then the GetTerms is going to have to determine the connector pane and make the rest of the terminals...I think that could be it.  Maybe have an option to close the reference or not with a right click.  Doubt I'll get time for this one but it is possible.

[hooovahh]

I think so...it could even have the right click option to wait on the response or not.  I started going through the idea exchange and I probably found 10 or more ideas that could be done today using XNodes, this one is just another to add to my list.  

Okay now that I thought about it a bit more I'm not certain this is possible.  The issue comes from the fact that we need to get the connector pane, of a VI but not using the VI reference, only using the data type of the wired type.  XNodes are edit time scripting, and so it can't tell you what the VI name or path to the VI that is wired to an input, it can only tell you the type of data that is wired.  So given a VI Reference Control, that is strictly typed, can you determine the connector pane using only the type of the reference, and not the data itself?  And I'm not certain that you can.

 

EDIT: Okay maybe vi.lib\Utility\VariantDataType\GetRefnumInfo.vi is what I'm looking for.

[ShaunR]

Okay now that I thought about it a bit more I'm not certain this is possible.  The issue comes from the fact that we need to get the connector pane, of a VI but not using the VI reference, only using the data type of the wired type.  XNodes are edit time scripting, and so it can't tell you what the VI name or path to the VI that is wired to an input, it can only tell you the type of data that is wired.  So given a VI Reference Control, that is strictly typed, can you determine the connector pane using only the type of the reference, and not the data itself?  And I'm not certain that you can.

 

EDIT: Okay maybe vi.lib\Utility\VariantDataType\GetRefnumInfo.vi is what I'm looking for.

 

Instead of trying to replace the AsynCall. what about replacing the static reference with your xnode so it produces the correct ref type? You'd only have to react to the VI drop.

[eberaud]

Reviving this discussion after being surprised by this behavior: (but now that I think of it I shouldn't have been surprised, it kinda makes sense!)

 

The reference I get through the Static reference is different from the one I get through the Open VI Reference even though the VI in question is not re-entrant. Does it mean I have 2 references to manipulate the same VI? It seems it's the reference that gets prepared for asynchronous call and not the VI itself, since the Start Async function gives me an error if I wire Staticref instead of Openref to its input.

 

 

 

While on the ACBR topic, I just noticed the subvi can't know which VI called it. In my screenshot, the caller of chart.config.vi calls it through an ACBR node, but the call chains shows that chart.config.vi.ACBRProxyCaller.5180012F was the caller...

 

Edited February 5, 2016 by Manudelavega

[Rolf Kalbermatter]

Reviving this discussion after being surprised by this behavior: (but now that I think of it I shouldn't have been surprised, it kinda makes sense!)

 

The reference I get through the Static reference is different from the one I get through the Open VI Reference even though the VI in question is not re-entrant. Does it mean I have 2 references to manipulate the same VI? It seems it's the reference that gets prepared for asynchronous call and not the VI itself, since the Start Async function gives me an error if I wire Staticref instead of Openref to its input.

 

Capture.PNG

 

 

While on the ACBR topic, I just noticed the subvi can't know which VI called it. In my screenshot, the caller of chart.config.vi calls it through an ACBR node, but the call chains shows that chart.config.vi.ACBRProxyCaller.5180012F was the caller...

 

Capture2.PNG

 

When you execute a Open VI reference node you ALWAYS receive a new and unique VI reference. This VI reference manages the data space, calling mechanism and also flags like how the VI can be invoked (asynchronous, clone, type of clone, etc, etc). As such it is indeed a completely independent instance of the VI from your original static VI reference. Basically the behavior you expect about VI references used to be true in a far ago past when LabVIEW did not support reentrancy, clones and asynchronous call, but it has changed dramatically under the hood with the introduction of these features. You usually don't feel much about those fundamental changes under the hood, but can run into it in such situations where the current behavior can sometimes surprise you.

 

And there is something else to this. The datatype input to the Open VI Reference node is only there to define the type of the outgoing strict VI reference. The actual VI to instantiate is defined by the VI Path or VI Name input. The VI Open Reference function will then inspect the VI connector pane to match the datatype input and throw an error if they don't match. But nothing of the refnum instance passed to the datatype input is used, except the connector pane info. Not even the name or path as you would otherwise not have to provide that for a static VI reference.