Starting and stopping child DQMH clones from a parent DQMH module

[GeoffA]

We are looking for the best way to start and stop child DQMH module clones from a parent DQMH module which often is a clone. We need to store the Module IDs that are created and make sure that the parent cleanly starts and stops its child clones.

In the diagram below:

1) MAIN APP is a VI to start, manage and stop child DQMH modules. It is built from the Delacor template using the Main VI State Machine and it works well.

2) The level 2 DQMH modules provide an interface to calling programs such as TestStand. Where clones have been created at this level, calling programs address the module with the Module ID. These also work well.

3) The level 3 DQMH modules are often clones that we would like to be controlled exclusively by the parent DQMH module creating them. They are started and stopped at arbitrary times at run-time during configuration operations. These clones have been tested independently and work well with the HAL.

Is there a standard method that has been established to start and stop these level 3 DQMH modules "correctly"? We have not yet found a template that will help us out. Any ideas would be appreciated.

[FabiolaDelaCueva]

I can take a more detailed look later... the thing that comes to mind is to look into modifying the Clone Registration.lvlib to include information as to what parent launched the module ID. 

The Clone Registration.lvlib is copied into your cloneable module. Take a look at that and see if that would help.

Hopefully, someone else in the forum will have time to get back to you sooner than me. I won't be able to take a look until later in the week.

Thanks for your trust in DQMH, glad it is working out for you and that so many of the levels on your application are working well.

Fab

[Ozfarmboy]

A good "template" for launching clones is the API Tester vi.  Here you can see how modules are managed and how to handle clones being started/stopped at various times.

The Clone Registration.lvlib:List instances.vi can be used to help keep track of all current running clones.

If a calling module needs to know which specific clones it launched, then it can keep track of each module ID it launched in a module ID array (via a shift register for instance) which is obtained from calling Start Module.

If the level 3 clones need to know who their launching parent is, you could pass it a unique id via a "setup" request from the calling module straight after starting the module and synchronising its events.

[GeoffA]

Thank you Fabiola for looking at this. I am working on it.

Regards,

Geoff.

[GeoffA]

Thanks for the ideas, Christopher. I'm running with it and should have something to test soon.

regards,

Geoff.

[GeoffA]

Here is what I tried...

I set up a project called CloneTree.lvproj with two cloneable modules: “Level 2 Clone” and “Level 3 Clone”. Each has a tester VI but the Application.lvlib has not been developed. So...

Clone registration:

I did not touch the Clone Registration library in the Multiple Instances folder. For any level, the DQMH registry could be used by a higher level for cleanup of the clones caused by improper shutdown by the parents. The tester “Test Level 3 Clone API.vi” is used as a test for level 3 operation by a parent such as a level 2 clone. A clone registration object “My Clone Registry.lvclass” maintains the level 3 instances for each Test Level 3 Clone API (parent) that may run. It uses the LabVIEW Variant attribute functions and a feedback node to store an attribute variant containing the Module ID (I32) and the Init? (Boolean) values under a user assigned module name. It is different from the DQMH registry in that the attribute names are user assigned, the list does not have the All (-1) selection and it does not keep the “first” information.

Selection Ring:

- A selection ring specific to each parent shows the names of the child clones and their module IDs. ”None” is the empty default when there are no clones running under this parent. The ring can allow Show Front Panel and Hide Front Panel or whatever the applications requires. The DQMH selection ring and Active Modules list can run in parallel for diagnostic purposes. The DQMH registry is still important for “first” clone-to-run shutdown, since this information is not specific to a module.

Level 2 Clone

Each Level 2 Clone starts and stops an arbitrary number of Level 3 Clones. There are some differences between the way this parent clone and the “Test Level 3 Clone API” does it, since the tester is a simple EHL but the parent clone requires machine state information about the child module to be maintained in the MHL.

• The Selection Ring is kept in the EHL as a user entry.
• Level 3 Broadcast Events are registered in the EHL
• A child module is started with a request originating in the MHL and requiring a reply. A child module is started and synchronized in the standard way in the EHL, but the reply is returned after synchronization and does not wait for the initialization to complete.
• Child module Init? Information in the “My Clone Registry” is later updated from the child module broadcast of “Module Did Init”.
• The child module is stopped with a “Stop Module” request, but the “Module Did Stop” broadcast is not checked.
• An exiting parent sends a “Stop Module” to each of the child modules in its own registry list.

Things left to do:

• Verify that the error reporting is adequate.
• Confirm before continuing that a child module has actually stopped.
• Consider whether or not integrating the two registries is worth it, since this would require changing a substantial number of files in the Multiple Instances folder of the DQMH.

Attached is a zip file of the project, LabVIEW 15 SP1. Comments and suggestions are welcome.

Regards,

Geoff.

[FabiolaDelaCueva]

Hi Geoff, 

The code is missing Find.vi from the My Clone Registry class. 

Please update the code and I will take a look.

Thanks,

Fab

[GeoffA]

Sorry about that!! I'm out of office and disconnected until the 29th but will get back onto it then.

Regards,

Geoff

[GeoffA]

Sorry for the broken VI. This zip looks OK at my end.

Geoff.