Adding a "(don't) wait until done" option to the Call By Reference node

[tst]

I would love it if the Call By Reference node had a "don't wait until done" option, so that we can stop using the inconvenient and inelegant Set Ctl Val method or other inconvenient ways to pass arguments to dynamically called processes.

I believe the main issue with this is what to do with the outputs from the subVI (since you won't be able to use them) and I can think of two options:

1. This option would be settable at edit time and would break the caller if you wire any of the outputs.

2. This option would be settable at run-time and you would get default data from the outputs and an error or warning from the error out terminal of the node if you wire any of the outputs.

[JackDunaway]

This is actually a brilliant idea. I just today had to dynamically call a VI and use the set control value function. I hate this function, because it creates an invisible dependency between the name of the control in the subVI and the set control value function in the "caller". Invisible dependenices that you cannot trace via the LabVIEW environment make it WAY harder to maintain code. If you choose a better, more descriptive name for that subVI input and forget to change the parameter of the invoke node, you've got yourself a broken app! Kudos, tst.

[tst]

While I'm at it, it would also be nice if the CBR node had a mode in which we can simply drag the VI into it instead of having to open a reference with the type, etc. This would also be useful for cases where we know exactly which VI we want to run. Of course, then the name CBR wouldn't fit, but this would still be a nice addition.

[Jarrod_S.]

I would add to this the ability in the asynchronous CBR node to automatically create and output a queue or user event reference with the bundled output data. That would complete the equation.

Another thing to note is that using the Set Ctrl Value method isn't just inelegant. It also requires the Front Panel to be loaded for the VI, which causes extra memory usage and problems in built executables that strip the Front Panel by default.

[tst]

> automatically create and output a queue or user event reference with the bundled output data

How would this work?

Would the data be sent only once, when the VI finishes executing?
This would be useful if you want to do some initialization and be able to wait elsewhere for the init to complete, but wouldn't be useful for parallel processes which don't have an "expiration date".

Would the data be sent whenever all the indicators were updated? This could be tricky, since some of the indicators may never be updated, while others may be updated multiple times.

[JackDunaway]

For me, if I wanted an "output" queue or user event, I would rather set it up myself. For nearly all of the instances that I could use this idea today, I would not even need an "output" notification - it's truly fire-and-forget.

[Ben]

The ground work may alread be in place for this idea. If  VI is marked as a sub-routine you can configure the sub-VI call as "Skip if Busy" so LV already has the ability to fake any return values.

Ben

[jcase]

An asynchronous Call By Reference feature has been added to LV 2011. While the idea described here is not implemented, the new async CBR should solve this problem. Please, try out the new async CBR.

[G-Money]

Already in LabVIEW. Functionality implemented in LabVIEW 2011 that should solve the functionality sought by this idea.