Executing same VI multiple times, sending/retrieving data

[zperkins]

I know how to execute a single vi multiple times using the invoke node/reentrant method.  But I am not sure how to send/get data the running vi's.

A little background on my project.  I have to test up to 64 units for a long period of time.  When one of the 64 units is found, I want the test to execute the test.vi then come back to my main.vi and wait for the next unit to test to be found.

The test.vi will require some information to run so I need to get that data into the test.vi along with a way to stop the tests while they are running.  I also want to report running data back to the user, so I need to get data from test.vi.

I am using a producer/consumer/display loop(s) and I would like to be able to use my display queue to collect and sort data from my running test.vi's.

I may be going about this wrong executing test.vi using the invoke node, but I am trying to find away that the test vi's will independently execute and run.

Please let me know if I need to clarify my situation.  I have been trying to figure this out for a while, so it may make sense in my head, but not on paper.

Thanks,

Zac

[RavensFan]

If I understand you correctly, you are invoking a reentrant VI to run in up to 64 different instances?  And you need to set up a communications mechanism between each instance and the main VI.

I would look at a functional global variable or action engine.  (Search on either of those terms and  you will come up with numerous examples).

Let the FGV store data in its uninitialized shift registers.  If you need a separate queue from each VI instance to the main, then have one shift register be an array of queue references.  Let's say you are ready to invoke the first instance of your VI.  Pass to it and ID value of 0 in its connector pane.  Obtain a queue and store the reference to that in index 0 of the queue array in the FGV.  Every time you need to enqueue or dequeue from queue 0, you use index array to retrieve the reference stored in queue 0.  You would do that whenever you need to work inside the instance of the VI (have it remember that its ID was 0) or in the main VI.

Next instance of the reentrant VI, you pass it a 1 as its ID.  Let the FGV obtain a queue and store its reference in index 1 of the array.  You could have other values stored in the FGV or other arrays such as an array of booleans that serve as flags to tell the instance of the reentrant VI to stop running.

Basically the FGV or action engine becomes a storehouse of information for each instance of the reentrant VI.  It will be scalable.  Each time you need to add a new instance of your VI, you store the info in another element of the array stored in the FGV that is based on a ID number you assign as you create each instance.

[zperkins]

You understood me correctly, and offered a good solution.  I got so hung up on loading multiple instances of the test.vi that it didn't hit me to use FGV (Haven't heard of "action engine".  I looked that up and found some good stuff.)

One more question though....

You say "Pass to it and ID value of 0 in its connector pane".  When using invoke nodes, I don't have access to the connector pain.  How do I give my reentrant test.vi instance an ID?  It would be great to be able to force an ID/index when I launch it because I would be able to use that ID for my display as well.

Attached is an example of how I was planning to run multiple instances of reentrant test.vi.

Thanks again for your great response.

Zac

[RavensFan]

I guess what you could do is set a front panel control to be the "ID" number and use some of the invode nodes and property nodes to get a reference to the subVI's control in the main VI and set it to its value right before or after you start running that subVI.

It may not even be necessary to send this "ID" number over.  I am just thinking of a way so that if the reentrant subVI needs to access the functional global to get a queue reference or something else, it knows which index of the array in the functional global to get its information from.  Another copy of the subVI would know what its ID index number would be (and different from the first) so it can get its data.

[zperkins]

Excellent.  Usint the invode node method Ctrl Val.Set I am able to set a control prior to running.  I see setting an ID to the reentrant test.vi a easy way to manage the data coming back from (up to) 64 tests running.

I can see it all now!  It's so clear!

Thanks for the kickstart!

Zac

[RavensFan]

Great.  I'm glad I could help.  I'm glad to here you are working out of these architectural details now before you dive into coding and get stuck.