DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Dynamic launch of cloneable modules

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"

JoGra_0-1708010137979.png

Which gets called by the called by reference launcher:

JoGra_1-1708010183140.png

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?

0 Kudos
Message 1 of 4
(193 Views)

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?

JoGra_1-1715939165329.png

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

 

Maybe @Darren has some ideas?

 

 

0 Kudos
Message 2 of 4
(59 Views)

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




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


Message 3 of 4
(50 Views)

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):
 

ioanp_0-1715963640474.png

 

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

ioanp_1-1715963730285.png

 

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.

 

ioanp_2-1715969358584.png

 

 

 

 

0 Kudos
Message 4 of 4
(30 Views)