Dynamic launch of cloneable modules

[JoGra]

Hi,
I'm getting some interesting behavior with cloneable modules and call by reference for a subsystem controller I'm developing. The subsystem controller is supposed to be able to start a selection of different cloneable "subsystem" modules, where each could have multiple clones. The controller will then control with a common API all subsystems.
I have based the dynamic launching implementation on the HSE-application template.

To my cloneable module i have added a "Load Module.vi"

Which gets called by the called by reference launcher:

Calling the launcher multiple time should start the module multiple times, but I only get a single instance of the module.
Which I can confirm with the modules API tester. 

However when the API tester vi is open (just open, not running) and I call the launcher, through a launcher tester vi, multiple times, I do get multiple instances. 
Somehow the API tester is loading essential parts of the clone registration into memory. 

I could confirm that by adding the "Start Module.vi" within a diagram disable structure to my launcher tester vi. 

Now the clone registration works and I can launch multiple instances of the cloneable module

What solutions are there for such behavior? Adding the "Start Module.vi" to my subsystem controller would add a static dependency, which I would like to avoid.
Is there a way to dynamically load the clone registration into memory?

[JoGra]

I wanted to bring up this topic again and ask, if this could be related to related to the "option" code for the "Open VI Reference" VI?

In my implementation I did not specify a specific code - but maybe I should? 

Maybe @Darren has some ideas?

[joerg.hampel]

Sorry, Jonathan, I completely missed your first post. We will look into this and get back to you.

[ioanp]

Hello!
I believe the answer to your problem lies in what happens with the VI where you are calling the "Load Module.vi" by reference. If the VI that loads your clone dynamically leaves memory, then it is to be expected when you call it again the clone module id will be 1.
Here is what happens when I run the second vi after I stopped the first one (note the module ID arrays):
 

And this is what happens while the first one is still running and hasn't left memory:

Looking a bit more into it, the module id comes from the "Start Module.vi" and there we see the VI that checks if the master reference exists or not (Get or create Master). If the calling vi of the Start module.vi or, specifically in your case Load module.vi, gets dropped out of memory, then the master reference is lost, so a new one needs to be created, which in turn resets the counter for module IDs.

[JoGra]

After a call with Ioan we figured out the that the "Create VI Reference" for the "Load Module.vi" needs to be called with the option 0x100 - "Prepare to call and collect" in order that cloneable modules can be started and the Module Id are returned correctly. 

Then LabVIEW seems to handle the references and memory in the background for you and no workarounds like passing the vi reference out of "Load Module.vi" into the caller and keeping it until the caller stops or adding the static reference to "Start Module.vi" in a diagram disable structure in the block diagram of the caller. Does someone have an idea, why that hack with the "Start Module.vi" worked?

EDIT : this solution did not work - had the Module tester open in the background which caused the same behaviour as including the "Start Module.vi" in a diagram disable structure... 

[ioanp]

 

I Tried recreating your example and found the solution doesn't work. However, if we connect an actual application reference to the corresponding input of the "Open VI Reverence.vi" the problem seems to be solved.

Scratch that, it still doesn't work. It seems the only way to solve this is to keep the reference to the Load Module.vi alive and clear it only once you are done with it, say when closing the application.
Have a look at this golden nugget https://youtu.be/F6BXpRPa59Q?si=z4_JFn5cKotSsUrZ&t=136 . "Simply running does not keep a VI in memory! What keeps a VI in memory: Open callers, Open VI references, Open front panels". So in conclusion, probably a few ways to skin the cat now: 
1. Keep the Load Module.vi references alive until you close your application.
2. Open the "Load Module.vi"s front panel and then immediately hide it? I do not know how farfetched this is. 

3. ... 

[JoGra]

My launcher is pretty much the same as for Ioan and it seems to work (even after restarting)

I will update if it also stops working like for Ioan.

If someone wants to try to test this issue as well, here is a project with the code. 
Requires the latest DQMH VIPM packages.

Edit: I'm using Labview 2023 Q3