Issue with control of dynamically-launched VIs

[Steiger]

I have an application where I dynamically-launch a sub-VI 12 times to communicate with 12 DUTs. The 12 re-entrant sub-VIs are controlled via one functional global which transfer commands from either the main calling VI, or from the sub-VI itself. 

While attempting to diagnose communication issues, I noticed some very strange behaviour. I update a "Command History" to assist in troubleshooting what commands the sub-VIs are getting. Attached is a screenshot of the result; each row shows the commands given to one DUT, newest commands are on the left. One of the sub-VIs (for DUT 8 in this case) never "receives" any commands. Another sub-VI (DUT 10 in this example), shows command sequences which shouldn't be possible (two INITs in a row, and a "READ" immediately following an "OFF"). 

I'm a little at a loss to understand how this is possible. Just looking at the code again, I can see a potential for a race issue in updating the command history, but the fact that a sub-VI (DUT 8 in this case) doesn't respond at all is just bizarre. Any insights or assistance would be appreciated.

I've attached the sub-VI in question. LabVIEW version is 2012; the customer's version this (doesn't) run on is LabVIEW 2010.

[pangvady]

There is probably a race condition at the code where you're reading from then writing to the Command History FGV. Place a semaphore acquire and release around this code. Make sure to pass in the same semaphore reference to each dynamically launched SubVI instance.

Another option is to simply show the Command History array directly on the dynamically launched SubVI's front panel, which you explicitly display during execution. Since the VI is re-entrant, each instance will show a unique set of commands.

[crossrulz]

This just screams race condition.  If you want your commands to be ran in a specific order with no possible way to lose commands, you should be using a queue.  And you should create a queue for each subVI you launch.  Then you just send the commands through the queue for the clone that needs to process it.

[Steiger]

I can definitely see a race condition on that Command History update being possible, but I don't get how the actual Command FG could produce a race condition, since any updates occur within the FG itself. 

The really strange thing again is that the one instance of the sub-VI will simply not process a command, staying in the OFF state, even though I can the INIT command sitting right there in the Command FG, waiting to be processed.

I will try troubleshooting that particular issue by making the dynamically-launched VIs visible (not sure what kind of mental block I had to not even think of that!), and will look into switching over to queues as well.

[Blokk]

I prefer to use dynamic User Events for communications between dynamically called subVIs and a main VI. It is just very powerful what you can do with User Events.

Some more ideas here regarding to User Events:

http://forums.ni.com/t5/LabVIEW/Triggering-a-user-event-in-one-subVI-from-another-subVI/m-p/3317337

Also have a look at the DQMH, which is an event based message-handler framework:

http://sine.ni.com/nips/cds/view/p/lang/en/nid/213286

[Steiger]

After examining the dynamically-launched VIs after they were launched, it turns out that the method of transferring initialization parameters to the dynamically-launched VI was not working as expected. I transfer the initialization parameters to a functional global, then launch the sub-VI, which reads the initialization parameters from the FG.

However, it looks like the FG can get updated before the dynamically-launched VI gets entirely started, so sub-VIs ended up with the wrong or sometimes duplicate initialization parameters!

I added another FG which gets updated by the sub-VI to indicate that it has read in the initialization parameters, and wait in the main loop until I receive this indication before transferring new initialization parameters to the appropriate FG. This seems to have solved at least some of the issues.

[Ben]

A more controlled manner to pass unique parameters to cloned VIs is included in teh example code that I included in my Nugget on creating Occurences.

It uses the ability to set a control on the VI to be cloned before it is run to pass the parameters.

That approach may be a little faster becuase multiple clones can be coming up at the same time (ignoring the detials of the Root Loop stuff) and can help avoid the possibel issue of the launcher hanging wiating for a flag to be set from a cloned VI that has start-up issues.

Have fun!

Ben