DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Hide VI Panel.vi block several second

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.

0 Kudos
Message 1 of 3
(180 Views)

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:

  1. Open front panel
  2. Open caller
  3. Open reference

Christina Rogers has a great video that explains this: 

https://youtu.be/F6BXpRPa59Q

 

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

I'm Organizing the GLA Summit!


For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out DSH Pragmatic Software Development Workshop!

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
0 Kudos
Message 2 of 3
(110 Views)

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.

Message 3 of 3
(107 Views)