DQMH Cloneable Module Launching Issue

[IvanTanKai]

I have a program where I two VI will be calling the same DQMH module Start and Stop. The problem i face is when 2 DQMH module is opened from different VI and one of them are closed and reopen, the module ID doesn't increment to 3 instead it will launch with Module ID 1. This behavior is strange because the second module haven't been closed. On top of that, the module will crash when i try to close the third module. Labview should launch the third module with module ID 3 instead of 1. I've attached a prototype and all you need to reproduce the issue is this:

1. Open Acq UI.vi and run the VI (From here you will see that module ID is 1 which is correct)

2. Open Gen UI.vi and run the VI (From here you will see that module ID is 2 which is correct) 

3. Stop the Acq UI.vi by clicking the stop button on the front panel 

4. Run the Acq UI.vi again (From here you see that module ID is equal to 1 which is suspicious to me, this is because the Gen UI are still running at the moment. The Module ID should be 3 if things setup in the right way) 

5. Stop the Acq UI.vi by clicking the stop button on the front panel. (From here you will see that the DQMH Module 1 Front panel will pop up and crash) 

Environment

- Labview 2023

- DQMH Version 7.0.1.1316

[joerg.hampel]

Hey there, thanks for taking the time to report this behaviour here on the forums.

I'm able to reproduce the scenario you're seeing. And while it seems strange and wrong, it really boils down to how LabVIEW works under the hood. After a quick consultation with a good friend of mine, here's an explanation.

• The VI hierarchy that creates a VI reference owns it.
• DQMH's "Start Module.vi" uses the Open VI Reference primitive to open a VI reference to the Main.vi -> the VI that calls "Start Module.vi" owns the reference to Main.vi.
• When your caller goes idle, so does the reference to Main.vi

TL;DR: DQMH Modules own their own event reference lifetimes, but they don't own their own main VI lifetimes... that ownership belongs to the VI hierarchy that called "Start Module.vi" in the first place.

[IvanTanKai]

Thanks Joerg,

In that sense, DQMH cloneable module doesn't really work with multiple VI/source opening and closing multiple module instead the DQMH Module is really just for one single VI/source opening and closing multiple module?

I'm trying to figure out a way to get over this as changing other framework at this point of my project is quite impossible. I think about launching the module into singleton but that doesn't really work just because Even if I create separate DQMH module for each of my VI, I have the use cases of opening multiple Acq VI / Gen VI, with that singleton doesn't really work.

[FabiolaDelaCueva · Accepted solution]

Keeping a top level launcher open that launches the hierarchy of VIs that will be calling the Start Modules is another way to address this issue.

Check out the CML project template that ships with DQMH. The CML Main doesn't show its front panel unless you run the exe with the --debug argument from a command prompt. This VI never goes out of memory until your complete application is done. 

Let us know if an approach like this one would help you. 

Fab

[Ludwig72 · Accepted solution]

I have got used to writing a module that acts as a clone manager. There I handle the starting and stopping of the clones as well as the configuration of the instances. The clone manager also manages the references or module IDs so that other modules can retrieve them.

[joerg.hampel]

---

@IvanTanKai wrote:

In that sense, DQMH cloneable module doesn't really work with multiple VI/source opening and closing multiple module instead the DQMH Module is really just for one single VI/source opening and closing multiple module?

Fab already suggested a solution, and I want to reiterate and be specific with the wording here:

DQMH cloneable modules support multiple sources opening and closing them perfectly well. LabVIEW itself requires that all those sources share the same VI hierarchy, and that VI hierarchy stays in memory. 

The usual architecture for an application is to have one startup VI that either stays in memory itself or starts a main module or actor or similar. Running and stopping individual VIs from the IDE is a challenge for how LabVIEW manages resources. 

---

@Ludwig72 wrote:

I have got used to writing a module that acts as a clone manager. There I handle the starting and stopping of the clones as well as the configuration of the instances. The clone manager also manages the references or module IDs so that other modules can retrieve them.

---

I agree, it's also what we usually do.