09-01-2016 02:56 PM
A while ago, I posted this idea.
It turns out there is a solution.
Call by reference nodes have a (private) "Configure" method that puts a static VI path into the node.For example:
The attached VI is a tool to let you setup a Call By Reference node.
1. Run the VI.
2. Single-click on a Call By Reference node.
3. Browse to the desired VI.
4. Click on Apply.
09-01-2016 02:59 PM
Oops. That first snipet was supposed to be the method, not a property node.
Here is the method:
09-01-2016 04:16 PM
Hi Paul,
Could you save this for LV 2012 or earlier? I would usually wrap an asynchronous call in a "Launch.vi" to save space on the main diagram, but the less wrappers the better!
09-02-2016 02:30 AM
I can't open your code at the moment, but the screenshot of the method doesn't show anything about making an async call. In fact, it shows exactly the options which have already been available in the editor for a long time, although most people probably don't notice them - just right click a subVI and you have a call setup option in the menu, which will open a dialog to set it up and then wrap the call in a CBR node. No need for hidden methods or extra tools.
Of course, what's missing from this is the async option and I'm assuming you haven't found a way of doing it, correct?
09-02-2016 07:30 AM
Although it seems to work when you try it, it doesn't actually start an async call, it just makes a regular call like a sub VI.
Also it often breaks when you save the VI (error being that it can't compile).
It also has a tendency to crash LV.
09-02-2016 07:33 AM
The 2nd snippet at the top of this thread has a Start Asynchronous Call node.
Unfortunately, it doesn't really start an async call, it just makes a regular call.
09-06-2016 12:16 PM
Hello Paul,
I'm having some trouble actually creating a reproducible case of this on my end.
Are you using DETT to verify it's not calling asynchronously, instead of just making a regular call? What does this look like?
I'm wondering why, even though you are successfully getting your subVI into the Start Asynch Call, that it seems to be calling like a normal subVI. My initial instinct is that there is a problem with the way you are writing it into the Start Asynch Call, but I don't have a lot of experience using this function and can't get your attached VI to work on my end.
Are you getting this same problem when you just manually add a VI using the right click VI server>>browse option into a Start Asynch Call?
Spencer R.
National Instruments
09-06-2016 02:08 PM
I know that it's not calling asynchonously by setting it to call a time-consuming VI, turning on "Highlight Exection", and watching the data flow. There's no output from "Start Asynch Call" until after the VI completes.
*****
When you "manually add a VI using the right click VI server>>browse option into a Start Asynch Call", it doesn't link to the selected VI, it just sets the type.
09-07-2016 05:07 PM
Hey Paul,
I was able to create a reproducible case, and was seeing that the VI scripted Asynchronous Start was not executing asynchronously. I'm going to look into this further, and try to dig into why the node blocks until its finished executing. This feels like unexpected behavior, but perhaps it's coming from the way you scripted the asynchronous start node.
Spencer R.
National Instruments
09-08-2016 08:05 PM
Like you mentioned in your first post this is all relying on a private method. If there's no way to configure this type of behavior directly from the dev environment, my guess is that it's some half-finished additional functionality for the start asynchronous call.
I didn't mess around with this too much but it's very possible that this is something that we won't be able to get working, it's the risk you take when you try to use private properties/methods as I'm sure you know.