LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to programatically query number of running instances of re-entrant vi?

I absolutely do haha - where did you find all these??

 

edit: i think I found it...    https://pastebin.com/j1iAEZXg

 

from:  https://lavag.org/topic/18469-i-found-some-more-hidden-ini-keys/

 

0 Kudos
Message 11 of 25
(1,477 Views)

Something that comes to mind is to make a little wrapper function around the launch of the reentrant async vi.  The wrapper would be non-reentrant, and could manage the mechanics of tracking the # of running clones. 

 

One method, there's probably better ones:   The wrapper would be a kind of Action Engine with actions of "launch" and "query # clones".  The wrapper holds a queue ref that it passes into the async vi on launch.  The async vi enqueues 1 item immediately as it starts and dequeues 1 item as it terminates.  The wrapper can at any time query the # items in the queue to know the # of clones. 

   It doesn't matter if the async clones dequeue a different item than they enqueued -- the item content is meaningless, only the # of them matters.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
Message 12 of 25
(1,468 Views)

>The async vi enqueues 1 item immediately as it starts and dequeues 1 item as it terminates.

 

this is basically how I did it but with user events- the re-entrant vi's are QMH's so it was easy to add...

0 Kudos
Message 13 of 25
(1,465 Views)

Another strategy is to pass each dynamic VI a queue created by the main.

 

Then dequeue an element. This will wait until 1) an element is enqueued (manual quit) or when the main stops (even if it's aborted).

 

The dynamic VI can then abort itself, either with an abort method, or gracefully. 

Message 14 of 25
(1,457 Views)

Four years ago, I rewrote an older program (which I also wrote) that relied on "spawning" up to 24 Clone VIs to handle a set of hardware responsible for collecting behavioral data on subjects for about 2 hours.  

 

I had a routine that was responsible for spawning the Clones.  This "Create Station Clone" routine not only started the Clone running, it output a Reference to the Clone that was saved in an Array by the main program.  Simply by looking at the size of this Array, I knew how many clones were created.  I also exported a link to pass data into the Clone, also saved in an Array so I could send data to "Clone N".  Similarly, if Clone N passed me back a message saying it was shutting down, I could note that, as well, in a "Status Array", which provided an indicator letting the Main Routine know when all the Clones had shut down.

 

Bob Schor

Message 15 of 25
(1,444 Views)

@Bob_Schor wrote:

Four years ago, I rewrote an older program (which I also wrote) that relied on "spawning" up to 24 Clone VIs to handle a set of hardware responsible for collecting behavioral data on subjects for about 2 hours.  

 

I had a routine that was responsible for spawning the Clones.  This "Create Station Clone" routine not only started the Clone running, it output a Reference to the Clone that was saved in an Array by the main program.  Simply by looking at the size of this Array, I knew how many clones were created.  I also exported a link to pass data into the Clone, also saved in an Array so I could send data to "Clone N".  Similarly, if Clone N passed me back a message saying it was shutting down, I could note that, as well, in a "Status Array", which provided an indicator letting the Main Routine know when all the Clones had shut down.

 

Bob Schor


I don't think that works when you abort the main during editing. Not being able to do that does have a crippling effect...

0 Kudos
Message 16 of 25
(1,423 Views)

Hmm.  I recall, when we were working on the earlier iteration of this 2015 routine, probably 3 years earlier, we did, indeed, get crashes from the Main VI, leaving clones running "somewhere".  I recall writing a "Abort Top-Level VI" that tried to find all Top-Level VIs (excluding itself, as I realized when I ran it for the first time!) and if they were running, make them Abort.  Don't remember all the details, but it worked like a charm.  I think there's a Property Node that will return all the VIs running on the Host PC.

 

When I rewrote the routine (starting from scratch, rather than trying to "patch" my colleague's original effort), I tried to design in "orderly shutdown", and didn't have to "Abort everything in sight" ...

 

Bob Schor

 

P.S. -- found it.  This is really in an earlier version of LabVIEW, but I think it should work in most versions ...

Abort Top-Level.png

Message 17 of 25
(1,410 Views)

@Bob_Schor wrote:

 I think there's a Property Node that will return all the VIs running on the Host PC.


All VIs except clones...

 

I haven't look around in LVs cookie jar much, yet, but getting references to lost clones is very hard to impossible.

 

There's just no way to do it, as references to clones are simply not supported.

 

Keep track of the references, or make the clones close themselves. Those are the options. Everything else will somewhat work, but won't be perfect.

 

I used a 'stop all' VI, that have now been changed to 'super stop all' VI. But you'll have to get all VIs, check if they are locked and reentrant, if they are, get the magic clone number, go over n clone names to stop them individually, until the original VI unlocks. It's very tricky.

0 Kudos
Message 18 of 25
(1,385 Views)

any chance you're willing to share that vi for LV2018?

sounds like a good one to have in the toolbox...

thx

0 Kudos
Message 19 of 25
(1,371 Views)

Sure.

 

Far from perfect, but it works for me.

0 Kudos
Message 20 of 25
(1,358 Views)