LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 
Reply

Integrate Start Asynchronous Call with Static VI Reference

A while ago, I posted this idea.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Integrate-Start-Asynchronous-Call-with-Static-VI-Refer... 

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.cfg.pngFor example:

cbr.png

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.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 1 of 10
(1,516 Views)

Oops.  That first snipet was supposed to be the method, not a property node.

Here is the method:

cm.png

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 2 of 10
(1,514 Views)

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!



CLA // LabVIEW 2016 // BALUG // Unofficial Forum Rules and Guidelines
0 Kudos
Message 3 of 10
(1,491 Views)

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?


___________________
Try to take over the world!
0 Kudos
Message 4 of 10
(1,460 Views)

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.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 5 of 10
(1,439 Views)

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.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 6 of 10
(1,438 Views)

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

0 Kudos
Message 7 of 10
(1,364 Views)

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.

 

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 8 of 10
(1,355 Views)

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

0 Kudos
Message 9 of 10
(1,308 Views)

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.

Matt J
National Instruments | CLA
Message 10 of 10
(1,269 Views)