Asyncronous Call By Reference

[Jim_Kring]

Here is an idea that I have wanted to make happen for a while. It is the Asyncronous Call By Reference. Basically, it is just a Call By Reference, but split in half so that the call is not syncronous (blocking), and return data can be obtained from multiple locations.  Plus, there should be ways to check the status of the asynchronous call and kill it.  I've even implemented this, to some degree, here http://forums.openg.org/index.php?showtopic=88

Message Edited by Jim Kring on 06-10-2009 08:14 AM

[tst]

You mean like this? The main difference seems to me to be that in my suggestion return data cannot be obtained from any location.

[AristosQueue (NI)]

This idea is very similar to this other idea:

Add "fork VI" method to VI method nodes

I'm going to ask moderator to consolidate these two ideas into one.

[tst]

By the way, users who are not logged into the OpenG forums can't download attachments or see images posted there, so most people probably don't see the image you attached (I didn't initially). You might wish to enable anonymous downloading in the forums.

[Marc Blumentritt]

OK, so this is the third idea asking for a way to "fork/call asyncronous/d'ont wait until done Call by reference node" a VI. Seems there is a lot of need for this, doesn't it?

[AristosQueue (NI)]

I went digging in the R&D brainstorm bin and found a *very* complete document that has been updated many times over the years. It seems one group of developers has worked on this problem many times and keeps hitting snags involving return values and how to asynchronously catch results of the call... making the call is easy.

So I decided to ask: Would it be a useful feature just to have the Call By Ref able to spawn a new running instance with no way to programmatically get the outputs later? I think from various comments that many people would be happy with such a set up, but I'd like to hear the community feedback. 

[Intaris]

User Events, Queues, Notifiers........  Take your pick.

Shane.

[tst]

Stephen, that's certainly my primary use case for this, as reflected in the idea I linked to earlier. I would probably even prefer the edit-time breaking of the caller I suggested there, because if it's only used for launching processes, it would usually be known in advance.

I even suggested a better shortcut there for launching processes - allow us to drag the VI directly into the CBR node, thereby alleviating the need to open the ref with the strict type, etc. This would mean that we basically have a rouge top-level VI (since we have no reference to it), but it should be up to the user to handle communication with it.

[Intaris]

I definitely agree that it's essentially up to the user to decide upon and implement the communication.  It's an advanced feature so there's less hand-holding required.  We (more or less) know what we're doing so I think fire-and-forget should actually be OK.

Shane.

[Jim_Kring]

---

@Aristos Queue wrote:

Would it be a useful feature just to have the Call By Ref able to spawn a new running instance with no way to programmatically get the outputs later? I think from various comments that many people would be happy with such a set up, but I'd like to hear the community feedback.

---

YES!!! That would be enormously useful.

[JackDunaway]

Just today, I modified one of my dynamically called start-and-forget it VI's. I added a few input parameters on the connector pane, and was sorely reminded that I would have to "pass" the values via the "Set Control Value" invoke nodes prior to letting 'er rip.

Just like any VI I call dynamically that runs asynchronous to the caller, I don't care about the outputs! Nope, don't care to get the outputs later programmatically! Just want to pass those parameters like a normal VI, not having to use 4 different invoke nodes!

(Another downer on the "Set Control Value"... if I rename the control on the called VI, the caller errors out 'cause it can't find the control it's trying to set. By not implementing Jim's feature, the LabVIEW developer will continue to be FORCED to perfectly spell the name of the control... can you say "text programming?")