LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

array of asynchronous reentrant vi references

Solved!
Go to solution

@timi13 wrote:

so basically if I want to do a call and forget, I cannot retain the reference to the vi's called?


Hi, Timi.

 

     Sorry I joined this so late.  I tell my students that when they "get stuck", it is often because they are worrying more about how to do something ("...I want to do a call and forget ...") than what they want to do.  You also have titled this thread "Array of asynchronous reentrant VI references", but have not yet (unless I missed it ...) described the task (the what) you are attempting.

 

     Can you give us a paragraph of prose (no code needed) explaining what you are trying to do?  Concentrate on the what rather than the how.  

 

     I've used references to reentrant VIs that I call with "Start Asynchronous VI" using both "Call and Forget" and "Call and Collect".  I have also written a VI that keeps an array of references such as you describe (did you attach all the relevant VIs in a form that we could actually run?).  I'm not sure where I picked up this phrase, but (in my written documentation) I refer to invoking a Start Asynchronous VI as "spawning" the VI.  One issue with spawned VIs is exactly that they are Asynchronous -- Start Asynchronous VI starts them, but you need to think about (a) how to stop them, and (b) how to detect that they are stopped.  I'd have to go back and look at some of my code to refresh my memory, but I seem to recall that my Array of References was related to such a "stopping" issue.

 

     Anyway, I'm sure when you tell us (and, incidentally, document it for yourself) what you are hoping to accomplish, and maybe provide all of the relevant Code examples (you can actually attach an impressive amount of code by putting the VIs in a folder, compressing the Folder to a Zip file, and attaching that single file), we, and you, will have some useful suggestions.

 

Bob Schor

0 Kudos
Message 11 of 19
(1,281 Views)

 I have main vi and from that main vi, I want to spawn multiple asynchronous instances of a process. I am using the call and forget option because I want the processes to continuously run. I wanted to use the fgv to store the references and names of these processes so that I can open the front panel, close the front panel, and exit the process I choose. I will have possible 100 processes running simultaneously. I should note that in the VI I am spawning, in the vi properties->execution, I have chosen the preallocated clone reentrant execution. I attached a sample vi in an earlier post. I will try to post vi shortly

0 Kudos
Message 12 of 19
(1,241 Views)

There are a number of things which could be wrong. A couple of potential examples:

 

  1. You should not use the clone name propety to get the name of the VI.
  2. The reference might be cleaned up automatically if the VI it was created in goes idle (I'm not sure if that applies if the actual VI is still running).

I suggest you upload a simple example people can play with.


___________________
Try to take over the world!
0 Kudos
Message 13 of 19
(1,203 Views)

@timi13 wrote:

 I have main vi and from that main vi, I want to spawn multiple asynchronous instances of a process. I am using the call and forget option because I want the processes to continuously run. I wanted to use the fgv to store the references and names of these processes so that I can open the front panel, close the front panel, and exit the process I choose. I will have possible 100 processes running simultaneously. I should note that in the VI I am spawning, in the vi properties->execution, I have chosen the preallocated clone reentrant execution. I attached a sample vi in an earlier post. I will try to post vi shortly


Please find attached a kind of "framework" which I use as a starting point for a recent project. I zipped a version 2015 and also 2014 (you may need to install some MGI and openG addons via the "VI Package Manager"). Sorry about I do not have time to remove unrelated parts, but you can see how I spawn parallel processes using the "call annd forget" method, and how I keep tracking of the running (and not running) tasks using an FGV. So maybe this project example can give you some ideas...?

 

Run the main VI, and you can spawn the reentrant VIs (gauge and chart indicators) by the custom menu via right click on the example indicator cluster...

Feel free to use these VIs, or part of them. This project is not optimal for sure, I would say it is more a playground to test different ideas for me... (as you see the Large XY Graph indicator window app also not optimal, I use an FGV for data sharing instead of the better way, via UserEvents...).

 

Untitled.png

Download All
0 Kudos
Message 14 of 19
(1,175 Views)
Solution
Accepted by topic author timi13

As I was trying to make a sample program that you guys could actually run, I came across various errors that led me to the solution. I was trying to access a strictly type reference for a clone vi. But all I need to do to access a clone is get the clone name. 

 

http://forums.ni.com/t5/LabVIEW/How-do-I-get-a-strictly-typed-VI-reference-of-a-particular-clone/m-p...

0 Kudos
Message 15 of 19
(1,144 Views)

@timi13 wrote:

I was trying to access a strictly type reference for a clone vi. But all I need to do to access a clone is get the clone name. 


My own preference would be not to do that, but to track the reference yourself, for a couple of reasons:

 

  1. People at LV R&D have said that this feature is accidental. While you can use the clone name to open a reference to a specific clone, it is not by design and could potentially have some issues.
  2. I generally prefer tracking things myself, because otherwise it's easy to accidentally start creating new references and forgetting to close them, etc.
  3. When you're generating multiple references, you often might not think about lifetime issues (when the resource that the reference represents is created, when it is destroyed, etc.). This is somewhat easier to handle if there is only one reference.

___________________
Try to take over the world!
0 Kudos
Message 16 of 19
(1,117 Views)

But why do you want to directly interact with the async VIs from your main VI? I think it is just easier and safer, if you create an unique identifier (string, number, ...) for each async subVIs which you launch. Also, use an Event Structure with a dynamic user event registered for capturing events from the main VI (Generate User Event function). After setting these up, you can easily send commands to all async called VIs. If you also send unique identifier(s) to a single or multiple VIs, you can filter which VIs should execute the sent command.

 

In the above way, you do not have to deal with VI references at all. You can easily fire any operation from the main VI to be executed in any async VI. Also, you can send info/commands back to the main VI, using an Event Structure in the main toplevel VI...

0 Kudos
Message 17 of 19
(1,102 Views)

I seem to be having the same problem, and apparently when you clone a VI to get mutliple instances of one, the reference for the clones (which are actually running) is NOT what you get back from the Asnchronous Call function. Somehow you have to return the "this vi" reference from the clone to the calling program. I haven't figured out how to do this yet, my next try will be via a global variable.

0 Kudos
Message 18 of 19
(921 Views)

I think what I ended up doing was save the original name of the clone in a functional global variable then use the name to access it. 

0 Kudos
Message 19 of 19
(724 Views)