Asynchronous VI and Get Control Value Method

[LDBM]

In LabVIEW Help about Async. calls to multiple instances of a VI for Parallel Exec , the caveat and recommendations paragraph indicates "

 

"VI Server properties and methods cannot modify parallel instances of an asynchronous VI call. If you call a VI Server property or method on a 0x40 VI reference, the property or method cannot modify the VI clone that the Start Asynchronous Call node actually calls. Instead, the property or method affects the original target VI. To apply VI Server properties or methods to the VI clone that the Start Asynchronous Call node actually calls, call the property or method within the target VI itself. "

Would there be an example of this around?  What I want to do is this: 

async.vi is the vi to launch in parallel several time. It is presumably reentrant.

main.vi: the launcher vi.

Main.vi launches async.vi clones 1, 2, 3. Each clone, when it starts running, generates a reference for an object it uses internally: Ref. What I want is to obtain this reference from clone 1, 2 & 3, and i was hoping calling the Get Control Name method to do this. But so far no luck. I tried Call and Forget, and Call and Collect...

Thx.

Laurent

[mikeporter]

What you are attempting to do will not work for the reason given in the highlighted section you quoted. To do what you want you save the target VI as a VIT. Now when you open a reference to it you will have a reference to the clone you created.

Mike...

[Jarrod_S. · Accepted solution]

There is a big race condition in this example. Even though you've launched the async VI, you can't be sure it's populated the Ref control when you try to query it later.

Furthermore, the GetControlValue method requires that the front panel for your VI is present. This is generally true when running LabVIEW code in LabVIEW.exe, but if you build your own EXE then often the Application Builder will strip out front panels of subVIs where it isn't seen as necessary.

Your approach might work better if you simply pass a queue reference into the async VI from main and have the async VI put its Ref value onto the queue. Then just have main listen on the queue for incoming Refs. This will definitely work.

Back to your original question: How can you use the Asynchronous Start for multiple reentrant clone instances and still know which VI reference you're using exactly? I think you can do this without using VITs. I think what you want to do is NOT use the 0x40 flag to denote reentrancy. What this flag means is that you can just open one VI reference and start multiple clones of it in parallel. This is not what you're trying to do. You're opening multiple individual references that you want to control individually through VI Server. To accomplish this, try switching out the 0x40 flag with the standard 0x08 flag for loading a reentrant clone instance. I am pretty sure I've done this successfully in your case. Note that I the info I gave you was simply obtained through trial and error and reading the help, so it could be inaccurate!

[LDBM]

Thx Jarrod.

Comments: 

Re: Race Condition: Correct. Main,vi makes sure that the first thing done was to set that control ref. But I realize this is bad practise.

Re: GetControlValue requiring front panel: good point. I forgot about this.  

So using queue, is better. Plus it will allow me to use the AMC in the code of the async VIs.

I tried with x08 instead of x40 and it seems to work in terms of launching  the async.vi instances independently of each other. I also modified the Async vi, so all its parameters can be passed via  the nodes in the Start Asynchronous call vi.

Now , as an aside, I was curious to see whether x40 options allows for a "simulateneous" launch  - strictly speaking -  like on plot B, or in fact leads to an overlapped execution like on plot A?. According to the AsynchronousCallAndCollectUsingOption0x40.vi (LV examples), x40 is supposed to produce simulatenous calls, while not using x40 leads to serial calls where the same instance is used when its previous run is completed.

My observation is that it is plot A that represents x40 option. Delta-t between each clone can be very small, but they do not seem to launch " simulateneously, stricly speaking.

L.

[Jarrod_S.]

I am not sure about simultaneous launches, but I suppose I doubt you would get truly simultaneous launches. At the very least you have to call the Asynchronous Start function multiple times sequentially, so that alone will induce some delay between the starts. If you want to synchronize execution in the parallel clones, consider passing them a shared notifier reference that they all wait on before continuing on to their "real" work.

[LDBM]

Ok Thx. That's what I was suspecting. I took the "simulateneously" comments in the example VI a little too literraly.

L.