11-11-2022 04:54 PM - edited 11-12-2022 05:45 AM
Hi all,
greetings from France.
To begin, a big thank for your fantastic work with DQMH Toolkit.
My problem : My program hang with "start module.vi". I would like to have your opinion.
I have singleton modules, which I start in my program, when the user performs actions under front panel IHM.
The modules are singleton mode. The user can right-click on front panel objects, run-time menu for example (run-time shortcut menu). We have detected that the "start module" vi can hang if a run-time menu is open.
I writed an example. cf Example_StartDynam.vi in the PJ folder
I have the latest version of the DQMH toolkit.
I have the feeling of being blocked in the root loop. But the root loop problem was solved from version 4 to 5 of the DQMH toolkit.
Your opinion? I am wrong?
See you soon.
A+ Luc
----------------------------
message origine en Français
Bonjour à tous,
un grand merci, pour commencer pour votre fantastique travail.
désolé de poster en Français 🙂 je traduirai par la suite. J'écris à une heure tardive, un peu fatigué, et je traduirai par la suite.
J'ai détecté un problème, et je voudrai votre avis.
J'ai des modules en singleton, que je démarre dans mon programme, lorsque l'utilisateur exécute des actions.
Les modules sont en singleton. L'utilisateur a des graphiques, des objets .net, et autres. Il peut faire des clics droit sur les objets, afin d'ouvrir des menus (run-time shortcut menu). Nous avons détecté que le vi "start module" peut être bloqué si un run-time menu est ouvert.
Le vi n'est pas bloqué en cloneable.
J'ai réalisé un code exemple. cf Exemple_StartDynam.vi dans le dossier en PJ
j'ai la dernière version du toolkit DQMH.
J'ai le sentiment d'être bloqué par la root loop. Mais le problème est "normalement" réglé depuis le passage de la version 4 à 5 du DQMH.
Votre avis?
Je me trompe?
merci à toute l'équipe ! A bientôt et au plaisir de vous voir
Luc Desruelle | Mon profil | Mon blog LabVIEW | Auteur livre LabVIEW : Programmation et applications - G Web
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD) | LabVIEW Champion
MESULOG - LinkedIn site | NERYS - NERYS Group
| directeur CEO MESULOG
| CODIR - NERYS group
Solved! Go to Solution.
11-12-2022 06:02 AM - last edited on 11-12-2022 06:17 AM by joerg.hampel
Hi @Desruelle_luc,
Thank you for your trust in the DQMH. I'm replying in English as I guess it will interest other DQMH users, too, as the topic is a bit tricky.
The behaviour you are experiencing is expected. Indeed, the Open VI Ref node requires access to the Root Loop to be executed. That's why starting a singleton module (or a clonable with the start as singleton option enabled) is blocked by an opened menu in the UI. There is no possible fix for that.
Since v5.0, the Start Module function for the Cloneable module has changed to prevent this issue:
With that in mind, you can prevent the root loop issue by doing the following:
The DQMH documentation mentions the issue (see the picture below) but deserves more details and actual use-case examples.
Luc, let me know if it makes sense to you. If you have any further questions, I'll be happy to help (or others).
11-12-2022 06:14 AM
it's crystal clear !
merci beaucoup. J'avais effectivement une mauvaise compréhension sur la root loop et le start module. Merci
A+ au prochain LUGE
Luc Desruelle | Mon profil | Mon blog LabVIEW | Auteur livre LabVIEW : Programmation et applications - G Web
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD) | LabVIEW Champion
MESULOG - LinkedIn site | NERYS - NERYS Group
| directeur CEO MESULOG
| CODIR - NERYS group
11-12-2022 07:01 AM
Note to the DMQH designers: it is possible to reduce dependence on Root Loop further. In both Messenger Library and Actor Framework usually only the first started module requires Root Loop; subsequent ones do not.
11-12-2022 07:03 AM
merci
Luc Desruelle | Mon profil | Mon blog LabVIEW | Auteur livre LabVIEW : Programmation et applications - G Web
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD) | LabVIEW Champion
MESULOG - LinkedIn site | NERYS - NERYS Group
| directeur CEO MESULOG
| CODIR - NERYS group
11-12-2022 08:33 AM
@drjdpowell wrote:
Note to the DMQH designers: it is possible to reduce dependence on Root Loop further. In both Messenger Library and Actor Framework usually only the first started module requires Root Loop; subsequent ones do not.
Seeing as Open VI Reference needs root loop access unless opening an untyped VI that's already in memory, I'm not sure I understand how we could further improve DQMH here. Every singleton and cloneable module is a different VI on disk, so for every singleton and each first instance of a cloneable, we have to open a typed VI reference.
How would you suggest for us to further improve this strategy, James?
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)
11-12-2022 01:42 PM
In the AF, for example, there is only ever one reference to a single (shared reentrant) "Actor.vi". This calls "Actor Core", which is dynamic dispatch and is overridden by the child classes. Thus Root Loop is only required once, when the first Actor, of any type, is launched.
11-12-2022 01:46 PM
BTW, I did once have a real world bug where the User had opened a menu and then walked away (left the menu open for two days). Program stalled at an Open VI Ref that only happens twice a day.
11-14-2022 12:06 PM
@drjdpowell wrote:
Note to the DMQH designers: it is possible to reduce dependence on Root Loop further. In both Messenger Library and Actor Framework usually only the first started module requires Root Loop; subsequent ones do not.
We use the exact same approach as Actor Framework starting with DQMH version 5.0