DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Singleton mode : blocage Start module.vi

Solved!
Go to solution

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

test.png

banniere Luc Livre NXG Champion.png

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

0 Kudos
Message 1 of 9
(1,972 Views)
Solution
Accepted by Desruelle_luc

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:

  1. The reference to the main.vi is obtained at the first Start Module call and kept in memory until all started instances are stopped.
  2. The Start Asynchronous Call is used instead of the Run Vi Method

With that in mind, you can prevent the root loop issue by doing the following:

  • With a singleton module, you need to start it before showing the UI and avoid starting/stopping it during the application execution.
  • With a cloneable module, in case you want to start multiple instances during the application execution, you must start a dummy module at the beginning of the execution before showing the UI. All subsequent Start Module calls will work fine because the Open Vi Ref is not called anymore

The DQMH documentation mentions the issue (see the picture below) but deserves more details and actual use-case examples.

 

image.png

 

Luc, let me know if it makes sense to you. If you have any further questions, I'll be happy to help (or others).


Olivier Jourdan

Wovalab founder | DQMH Consortium board member | LinkedIn |

Stop writing your LabVIEW code documentation, use Antidoc!
Message 2 of 9
(1,912 Views)

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

banniere Luc Livre NXG Champion.png

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

0 Kudos
Message 3 of 9
(1,899 Views)

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.

Message 4 of 9
(1,860 Views)

merci

banniere Luc Livre NXG Champion.png

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

0 Kudos
Message 5 of 9
(1,856 Views)

@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)


Message 6 of 9
(1,829 Views)

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.

Message 7 of 9
(1,801 Views)

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.

Message 8 of 9
(1,800 Views)

@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

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?
Message 9 of 9
(1,726 Views)