Multiple un-used Clone loaded in memory

[Eric_BOB]

Hi

In my project, I have created one cloneable module (Module Com) that becomes a bit fat. I have tested it with Tester and find strange things. The first time I load one instance, I obtain 5 instances of Modules (main.vi). Only the last is really functional (Module Com 1) and the 4 others are just inactive copies of Module Com 0. I'm not sure but I think Ii have already had this kind of excessive copies when I have tested Start asynchronous call.vi on another project (without DQMH). Have you ever encountered this kind of problem?

After the first launch, all seem ok and I obtain only one instance each time I load the clone. I'm not sure it's really a bug, but like sometimes my project take excessive time to stop cloned modules and stop tester and seem to hang, I suspect this kind of quirk.

[Eric_BOB]

It seems it's normal with an asynchronous call to create few unused instances(create with VI Reference Management.lvlib:Get or Create Master) in "Ready to run" state. To be more precise, when you run the tester, LV creates a clone instance (Main.vi:414001), and after when you call "Start module.vi" the first time, LV creates 4 instances more (4140002 to 4140005) and associate 4140005 to the first clone. If you call again "Start module.vi" LV associate 4140004 to the 2nd clone instance. It's the same thing for the two next calls(4140003 & 4140002). If you call again LV creates one new ref (4140006) etc...

[Eric_BOB]

Another thing is that since DQMH5 uses the asynchronous call, when you stop the cloned modules, they stay in memory and are unloaded only when the program is stopped. In DQMH4, the creation of a clone is done via the classic way of calling the VI server with the x08 option and using the "Auto dispose ref" method. In this way, unused clones are unloaded from memory and there is no risk of congestion in the event of massive use of clones.

[Olivier-JOURDAN]

---

@Eric_BOB  a écrit :

Hi

In my project, I have created one cloneable module (Module Com) that becomes a bit fat. I have tested it with Tester and find strange things. The first time I load one instance, I obtain 5 instances of Modules (main.vi). Only the last is really functional (Module Com 1) and the 4 others are just inactive copies of Module Com 0. I'm not sure but I think Ii have already had this kind of excessive copies when I have tested Start asynchronous call.vi on another project (without DQMH). Have you ever encountered this kind of problem?

After the first launch, all seem ok and I obtain only one instance each time I load the clone. I'm not sure it's really a bug, but like sometimes my project take excessive time to stop cloned modules and stop tester and seem to hang, I suspect this kind of quirk.

---

Hi Eric, I didn't reproduce the bug you describe with the project template provided with the framework. Can you try to reproduce it with this template?

Thanks,

Olivier 

[Eric_BOB]

Hi Olivier

For my problem, i have sending  you explaination on your web site Wovalab https://www.wovalab.com/fr/2019/11/27/dqmh-un-peu-plus-qu/

Sorry for the other but it's in french. Like I said in your web site, the problem of big latency didn't come from DQMH, but from size of my main.vi and of compilation optimisation. 

That's solved now.

However, the un-release memory of clone when they are Stop them  stay. To look memory occupation, i use this tool https://lavag.org/topic/18991-cr-vi-organizer/ . Don't forget to select Closed and include Clones in the configure options. But perhapse you have another tool to see that.

You can make test with creating one cloned module and load few instances with the tester.

[Eric_BOB]

Just a clarification. DQMH5 leaves stopped clones in memory as long as the vi launcher (AKA Tester) is running, and unloads them when it stops. Whereas DQMH4 removes them from memory as soon as they are stopped and even if the vi launcher is not stopped. This makes a small difference but can lead to the risk of unnecessary memory loading with the massive use of clones.

[Olivier-JOURDAN]

Hi Eric,

As you can see below, I'm just using the regular "tool" provided by LabVIEW and can't reproduce what you're describing.

Can you try the same with your project and with the template project provided with DQMH?

[Eric_BOB]

Hi Olivier

Your video lool like the DQMH4 template. I send you my video for one simple example using the DQMH 5 template. Sorry I do that with VLC and don't find how to add comments and see the mouse pointer. The first strange thing is my actives modules numbers are 1,2,3 while in yours it's 4140001,4140002, 4140003 like in DQMH 4.

[FabiolaDelaCueva · Accepted solution]

Hi Eric,

If you want the same behavior as DQMH 4.0, you have to turn on to TRUE to destroy the master reference. This is in the VI at the lowest left of your Main.vi. This is the VI that creates the event references.

Please read the note though, we are leaving the reference alive to address Andreas' Test. 

Check out this Video from a presentation I gave for the User Group in Chicago that explains why we added this feature to DQMH 5.0.

Let us know if you have other questions.

Best regards,

Fab

[Eric_BOB]

Thanks, Fabiola

I just tested this option, and indeed if I stop all the clones, they are removed from memory. However, if I remove one or more, but leave an active one, these are not removed from memory. If I compare with DQMH 4, there is a difference because at each shutdown of a clone it is immediately removed from memory, and does not wait for the others to shutdown.

But hey, that doesn't seem too critical to me.