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 7
(260 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 7
(126 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 7
(117 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 7
(97 Views)

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... 

 

 

 

Message 5 of 7
(61 Views)

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.


Cloneable Modules.png

 

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. ... 

0 Kudos
Message 6 of 7
(46 Views)

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

JoGra_0-1716212339936.png

 

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

0 Kudos
Message 7 of 7
(30 Views)