01-20-2021 05:43 AM - edited 01-20-2021 05:45 AM
Hi
In my project, I use many cloned Modules that can be loaded in a subpanel. But for tests, they are just loaded in memory without showing the front panel. When I try to stop them with "Stop Module Instance" Button of the tester, this can take a few seconds before really stop. To find the problem source, I have run the statistics tool and find that the problem comes from "Hide VI Panel.vi" which is called by "Handle Exit.vi". I don't really understand why "Hide VI Panel" is used in "Handle Exit.vi". The explanation in a comment on the diagram about staying in memory until the module really finishes works isn't clear for me. Anyway, I have made a modification to "Hide VI Panel.vi" by hiding the front panel state, only if we are in standard, maximized, or minimized. And that has solved my issue.
01-25-2021 08:58 AM
Hi Eric,
We haven't experienced what you describe. Can you reproduce the issue with the API Tester? If so, please let us know the steps to reproduce.
@Eric_BOB wrote:
I don't really understand why "Hide VI Panel" is used in "Handle Exit.vi". The explanation in a comment on the diagram about staying in memory until the module really finishes works isn't clear for me.
There are three things that keep a VI in memory:
Christina Rogers has a great video that explains this:
The first clone to be launched owns the event references for all the clones. This is why we can send an event in parallel to all clones by using a -1 address. This is also why each clone needs to check if the message was directed to them. We keep the first clone in memory to ensure all the other clones can still receive their events and handle them. The first clone is no longer running, it is just in memory with the only purpose of keeping those references alive.
Please let us know if this is more clear now or if you are still not clear on why we keep the clone VI reference in memory for the first clone.
Thanks for your trust in DQMH and us.
Best regards,
Fab
01-25-2021 09:25 AM
Hi Fabiola
It's more clear for me.
For my issues about delays when I want to close FP of modules and lots of freeze moments, that's not come from DQMH. Like I said to Olivier on his Web Site it was a problem of compilation. My module becomes fat and his statistics compilation complexity is around 6.3.
That introduces partial compilation and not complete every time I make my test.
Finally, after a complete compilation, all seem to run ok.
Many Thanks for DQMH and your help.