22 réactions sur “ DQMH, un peu plus qu’un framework ? ”

  1. Brice Réponse

    Salut Olivier,

    Tout d’abord, je te souhaite une belle et heureuse année 2020 !
    Ensuite, merci à toi pour cette belle présentation de DQMH qui donne envie d’aller plus loin. Je travaillais jusque là avec un framework maison et je pense que je vais basculer vers celui-ci, qui apporte énormément de fonctions utiles et permet une modularisation “native” du code produit.

    A très bientôt !

    Brice

  2. Olivier Jourdan Auteur ArticleRéponse

    Salut Brice,
    Meilleurs voeux également. Que 2020 soit plein de projets LabVIEW intéressants pour toi !

    Je ne peux que t’encourager à faire le pas vers le DQMH.

    Un petit conseil pour éviter les désillusions prend le temps de bien comprendre la philosophie du framework avant de te lancer dans ton premier projet. Si tu ne fais pas ça, le risque sera de vouloir te raccrocher aux choses que tu as l’habitude de faire avec ton propre framework et il y a de fortes chances que cela ne fonctionne pas bien. Non pas parce que ce que tu as l’habitude de faire n’est pas correcte, mais tous simplement parce que cela ne correspond surement pas avec le DQMH. L’exercice demande un effort au début, mais c’est vraiment un bon investissement !

    N’hésite pas à me tenir au courant de tes premiers pas avec le DQMH.

    À+

    Olivier

  3. BOBILLIER Eric Réponse

    Bonjour Olivier
    Merci pour cette présentation que je découvre seulement maintenant. Je pense que je vais sérieusement regarder le fonctionnement interne de DQMH pour l’utiliser dans mes prochains projets. Juste une question, pourrais-tu nous dire si tu le sais , quelles sont les évolutions du passage de DQMH 4 à la version 5 actuellement proposé par DELACOR. Merci

  4. Olivier Jourdan Auteur ArticleRéponse

    Bonjour Éric,
    Je suis content que cette présentation ait éveillé ton intêret pour le DQMH.
    Concernant les évolutions notoires apportées par la version 5, je dirais que les plus visibles sont la capacité de créer un testeur compatible RT pour les modules Singleton (on ne pouvait faire ça que pour les Cloneable dans la version précédente) et la possibilité de valider tous les modules DQMH en une seule fois et de le faire via une step de CI.
    Il a eu de grosses modifications sur la gestion du démarrage des modules qui améliore la fiabilité, mais ce n’est pas “visible”.

    Sinon, il y a une grosse quantité d’amélioration des outils de scripting existant pour faciliter la vie des utilisateurs. Tu peux voir la liste complète ici –> https://delacor.com/dqmh-documentation/dqmh-5-0-release-notes/

    Comme pour Brice plus haut, n’hésite pas à me tenir au courant de tes premiers pas avec le DQMH. Je trouve toujours intéressant de comparer les expériences!

  5. BOBILLIER Eric Réponse

    Bonjour Olivier
    Je prends enfin le temps de me pencher sérieusement sur ce framework et de creuser un peu plus loin qu’un exemple de base.
    actuellement j’ai une interrogation concernant les évènements broadcast et leur option de génération qui permet de choisir comme “argument Source” un “Existing Request Argument”. l’idée que je m’en fait est que l’événement broadcast peut être déclenché dans le main.vi en réponse à un évènement Request. Cette pratique semble assez proche d’un request and wait reply si on la borne à un seul émetteur qui reçoit le message broadcast en retour de sa request. Elle prend plus de sens si l’on imagine qu’un module maitre envoie une request à un second module, qui à son tour le propage en broadcast à tous ses abonnées.

  6. BOBILLIER Eric Réponse

    Cependant, et c’est là tout le sens de ma question, on voit que si la requête originale est du type “Request and Reply”, la notification liée à la Reply est propagée au message de broadcast. Ce qui risque que de poser un problème si chaque abonné au broadcast essaie de répondre à cette notification. Il est bien sur possible de ne pas les laisser gérer cette notification, mais je pense qu’un message de warning serait utile dans ce cas lors de la génération de la requête broadcast pour prévenir ce cas lors de l’utilisation. J’espère avoir été assez clair dans mes explications.

  7. Olivier Jourdan Auteur ArticleRéponse

    Bonjour Eric,
    Content de voir que tu trouves le temps de te pencher sur le DQMH. Au passage, tu pourras peut-être jeter un oeil à Antidoc, associé à un projet basé sur le DQMH, tu en auras presque fini avec l’écriture de la documentation de tes codes LV –> https://youtu.be/NQW4HDjRPoE

    Concernant ta question, la fonction dont tu parles est (je pense, parce que je ne l’utilise jamais (surement à tort)) liée au Round Trip event. Je m’explique:
    – le round trip event permet de créer une request with reply ET un broadcast ou le même cluster sera utilisé pour la reply et le broadcast.
    – l’idée est de permettre de “sniffer” les réponses envoyées par le module en général avec le tester. La documentation du DQMH donne l’exemple d’une utilisation avec TestStand, mais cela peut aussi être utilisé dans LV pour déboguer ton application en démarrant l’API tester en parallèle de l’application.
    – Si l’on revient à la fonction dont tu parles, je pense qu’elle existe pour pouvoir créer un Round Trip à partir d’une request préexistante. Si cette requête était une simple requête (sans reply) il faudrait passer par le menu convert DQMH event avant pour la transformer Request with reply.

    Est-ce que cela répond à ta question ?

  8. Olivier Jourdan Auteur ArticleRéponse

    En complément d’information, après discussion avec Fabiola Dela Cueva (architecte du framework) l’option de sélectionner l’argument depuis une requête existante “is a leftover from when the roundtrip was not as powerful as it is today”.
    La fonction est conservée, mais plus réellement nécessaire.

  9. BOBILLIER Eric Réponse

    Ok. Merci pour ces éclaircissements et aussi pour ton super outil Antidoc.(Gros boulot j’imagine)
    Effectivement, je pense qu’il vaut mieux éviter de l’utiliser et plutôt prendre le roundtrip qui est moins dangereux (cf mon message précédent) car il ne propage pas la notification semble t’il. Peut-être vaudrait-il mieux la supprimer dans la prochaine version du DQMH pour éviter au “newbie” comme moi de ce poser trop de questions.
    J’ai une nouvelle question et peut-être aura t’elle la même réponse que la précédente (vestige du passé).
    Voici: lorsque l’on crée un événement requête, il nous est proposé une option “Custom” dans la rubrique Enqueue Message Vi.
    Pourrais-tu si tu le connait me donner un cas d’utilisation de cette option ?
    Merci
    Eric

  10. Olivier Jourdan Auteur ArticleRéponse

    On peut dire que tu cherche vraiment à ne rien manqué, excellent!
    Cette option est une nouveauté de la version 5.0 qui s’adresse aux développeurs qui modifient la manière dont les messages sont envoyé à la MHL. C’est une option très utile, mais dont l’utilisation est assez rare a ma connaissance. Tu as plus de détail dans la release note de la version 5.0 –> https://delacor.com/dqmh-documentation/dqmh-5-0-release-notes/

    “If your custom DQMH template requires a different enqueue (for example for a DQMH Queue child or if the DQMH libraries were built into a PPL), we added the ability to specify a custom enqueue message VI to be scripted into the MHL when creating request events Singleton and Cloneable Module templates updated to use Start Async Call instead of Run VI method for launching Main VI”

  11. BOBILLIER Eric Réponse

    Merci Olivier. Je vais regarder cela en détails. Je n’avais rien trouvé dans la doc, mais je n’ai pas pensé à jeter un œil dans le release note.
    Pour info, j’ai installé ton outil Antidoc et je l’ai testé sous FireFox équipé du plugin asciidoctor.js et tout fonctionne correctement. Seule petite différence avec ton explication pour Chrome, il n’est pas utile de sélectionner “autoriser l’accès aux urls de fichier” car cette option semble native dans le plugin. Du moins je ne l’ai pas trouvé et comme cela fonctionne…
    Merci encore.

  12. Olivier Jourdan Auteur ArticleRéponse

    Merci pour to retour sur Antidoc et sur la config de Firefox.

    J’espère vraiment que ce duo, DQMH + Antidoc répondra à tes attentes.

  13. BOBILLIER Eric Réponse

    Oui DQMH et Antidoc semblent un bon candidat pour mes futurs projets. Je m’interroge par contre sur la taille de la documentation générée par de gros projets à plusieurs dizaines de modules. Peut-être qu’une évolution serait de séparer l’aspect structure (relation des modules) et documentation des vi’s sous la forme de 2 fichiers asciidoc? Mais bon j’abuse déjà un peu et dans sa forme actuelle, il me suffit déjà bien.
    Par contre je m’interroge sur un point technique du DQMH. Lorsqu’un vi s’abonne aux évènements “broadcast” d’un module via “Obtain Broadcast Events for Registration.vi” il reçoit l’ensemble des évènements générés par ce module. Puis il les consomme via sa structure événement en utilisant l’évènement utilisateur associé à chaque event broadcast. Cependant, il se peut qu’un abonné n’ait pas l’utilité de consommer tous les broadcasts. N’y a-t-il pas un risque qu’ils restent bloqués en attente dans la structure évènement (risque de débordement ?) ? Ne Doit-on pas les consommer via un événement dont le seul rôle serait uniquement de le consommer ?
    Merci encore

  14. Olivier Jourdan Auteur ArticleRéponse

    Concernant la taille de la doc, ce qui guide les développements actuels, c’est de ne mettre que ce qui est utile dans la doc. La liste des VI est une de mes pistes de travail –> https://gitlab.com/wovalab/open-source/labview-doc-generator/-/issues/80
    après je sais pertinemment que les besoins de chacun peuvent diverger, c’est pourquoi Antidoc installe une palette avec les routines de base qui permettent de construire le doc afin de permettre à chacun de construire sont propre document, mais cela requiert un investissement plus important…
    Pour info, j’ai un projet plus de 40 modules. Antidoc génère un document de 500 pages. La navigation au sein du doc reste simple avec les liens internes qui sont générés.

    Pour ce qui est des broadcast, tu peux (doit) t’abonner aux seuls événements qui ont un intérêt pour toi. À un élément du “register event” doit correspondre un événement de la structure sinon il y a fuite de mémoire. Après, il n’y a pas plus de problèmes qu’avec une file d’attente, si on met trop de temps à dépiler, on a des problèmes.

  15. BOBILLIER Eric Réponse

    J’avoue que je ne suis pas bien sûr d’avoir bien compris ta réponse concernant les broadcasts. Voici ce que je comprends: Si il faut qu’à chaque élément du register event doit correspondre un événement de la structure évènement, il faut donc mieux pour les évènements broadcast dont je n’ai pas besoin, utiliser un cas dans la structure évènement mais qui ne fait rien (car je n’en n’ai pas besoin) plutôt que de ne pas prévoir ces cas.
    Car je ne vois pas comment m’abonner aux seuls évènements qui m’intéressent.
    L’idéal aurai été d’avoir un dispositif de filtrage pour la liste des évènements broadcasts lors de leurs utilisation. ou de pourvoir créer des Obtain broadcast events for registration personnalisés.
    Cependant en cherchant sur le net j’ai trouvé cela : https://forums.ni.com/t5/LabVIEW/Event-Inspector-Window-Unhandled-Events-quot-how-bad-quot-are/m-p/3660445?profile.language=fr#M1028610
    Ce qui me laisse penser si j’ai bien compris que depuis LV2013, les évènements enregistrés mais non gérés sont détruit automatiquement par LV. Il n’y aurait donc pas de memory leek et Il ne serait donc pas utile de les gérer par un cas qui ne fait rien.

  16. Olivier Jourdan Auteur ArticleRéponse

    Eric, pour mieux comprendre, je te conseille de regarder le projet exemple fourni avec le framework, CML DQMH. Si tu regardes le main.vi du module Acquisition tu pourras voir:
    1 – qu’il implémente une 3e boucle (Helper loop) qui est en soi un concept important à connaitre pour utiliser le DQMH
    2 – que cette Helper loop s’abonne à un certain nombre d’événements du module, mais pas à tous en utilisant la fonction unbundle by name. Chaque événement a son cas dans la structure event. Si ce n’était pas fait ainsi, tu aurais une fuite mémoire.

    De cette manière pas de problème.

    Est-ce plus clair ?

    NOTE 1 : une règle très importante à retenir, un register event pour une structure event. On ne fork jamais la référence qui sort du register event.

    NOTE 2 : cette conversation est intéressante, car j’entends assez souvent des personnes qui découvrent le DQMH avoir “peur” de l’usage des events. Je pense qu’une présentation spécifique sur leur usage (en dehors du DQMH) pourrait être vraiment intéressante. Peut-être dans un futur LUGE…

  17. BOBILLIER Eric Réponse

    Ok merci beaucoup je vais regarder cela demain. Et je suis preneur pour une présentation dans LUGE. Même si je suis un peu loin vu de ma Bretagne ;))

  18. BOBILLIER Eric Réponse

    Bonjour Olivier
    Je te recontactes car j’avance dans mon projet et comme tu peux t’en douter je rencontre qq soucis avec le la fiabilité de mon architecture et peut-être celle du DQMH 5.0. Dans mon projet j’ai créé un module clonable ( 25 clones doivent au final tourner en //) dont la face avant peut à la demande apparaitre dans un subpanel sur la FA du testeur. Ce module communique pour le moment avec le tester et un module singleton chargé de collecter les erreus. Ce dernier est lancé et arrêté via le testeur. La pluspart du temps tout ce petit monde semble bien fonctionner, mais assez souvent lors de l’arrêt via le bouton “Stop Module Instance” (All) le testeur semble bloquer plusieurs disaines de seconde et parfois crash LV2018. Il m’envoie bien les messages indiquant que les modules ont été arrêtés mais refuse d’arrêter le testeur. Bon j’imagine que la raison peut venir de plein de choses et je ne te demande pas de débbuger mon programme. Par contre pourrais-tu me dire si tu as déjà utilisé le DQMH5 avec des modules clonables et si dans ce cas tu en as été satisfait. Comme je l’ai demandé sur le forum DQMH, je m’intérrogeais sur le lancement asynchrone des modules par le testeur et le fait qu’il génére des instances de vi qui dans un premier temps sont inutilisé (4 au moins) mais qui semble être alloué à des instances de module effective dans un second temps( lors du lancement d’une instance). Mais cela semble normal?!? enfin je retesté avec un autre module cloeable et j’obtiens la même chose. As-tu un avis la dessus?
    Par ailleurs j’ai aussi testé la mise à jour d’un module clonable DQMH4 avec l’outil “Validate Module” et il m’a effectivement proposé plusieurs modifs que j’ai validés. Cependant lorsque j’ai regardé les différents Vi modifiés et le template de mon Vi clonable j’ai trouvé énormément de différences, par exemple dans le lancement des clones (start Module) et leur arrêt (Stop module) sans parler de la librairy VI reference Management présente uniquement dans le 5. Le DQMH devient d’une complexité telle que je n’arrive pas trop à retrouver mes petits et à résoudre mon problème ( particulièrement sur le déréférencement des clones et la libération des recourses), et donc je m’interroge sur sa fiabilité.

    • Olivier Jourdan Auteur ArticleRéponse

      Salut Éric,
      Bonne année au fait 😉

      Concernant la fiabilité du DQMH, je ne peux rien garantir, mais seulement te faire un retour d’expérience. La plus grosse application que j’ai développée à ce jour à plus d’une quarantaine de modules dont 14 sont cloneable. La plupart de ces modules cloneable sont affichés dans l’interface via des subpanels et dans certains usages de mon client, certains de ces modules peuvent être clonés plus d’une 50aine de fois.
      L’application est utilisée sur une 10zaine de banc de test et à ce jour le client est très satisfait, donc je n’ai vraiment pas d’inquiétude sur le DQMH.
      Il m’arrive de rencontrer le problème que tu décris (arrêt long ou même sortie en timeout), mais assez peu souvent. Je n’ai jamais investigué ce problème particulier, car a priori il se produit en cours de développement et lorsque j’ai auparavant fait des choses pas forcément “propres”. Donc difficile pour moi d’incriminer plus le DQMH que mon code.
      Je regarderai de plus près la prochaine fois, car s’il existe un problème au niveau du DQMH et qu’il est remonté, je suis plus que confiant sur la capacité et la volonté de DELACOR de le corriger.
      Note que l’application dont je parle utilise la version 5 du DQMH.
      Le premier point des “major features” de cette version concerne la modification du démarrage des modules –> https://delacor.com/dqmh-documentation/dqmh-5-0-release-notes/
      Il est donc normal que tu constates ces différences entre les 2 versions.

      Concernant les problèmes particuliers que tu rencontres, c’est difficile de se prononcer sans voir le code…

      En espérant t’avoir rassuré.

  19. BOBILLIER Eric Réponse

    Bonjour Olivier
    Bonne année et surtout bonne santé à toi aussi.
    Je crois avoir résolu mon problème et le DQMH n’y ai semble-t-il pour rien. J’ai beaucoup complexifié le Main.vi de mon module. A tel point que la complexité était de 6.5 dans les propriétés\ utilisation mémoire du VI. Cela a entrainé une optimisation partielle de la compilation
    dynamique ( à l’édition) du vi. J’avais beau faire des modifs et des enregistrements mais rien n’y faisait. Et en voulant creuser, j’ai décidé de faire une copie du main et cela à entrainé de suite une re-compilation complète du VI (et de ses sous-vi ?). Et depuis le problème de réactivité semble résolu. Je viens encore d’apprendre un truc dans LV. Et depuis je recompile régulièrement mon Vi.
    Merci en tout cas et désolé d’avoir porté le discrédit sur le DQMH.
    Bon week-end

  20. BOBILLIER Eric Réponse

    Par contre j’ai quand même une remarque à faire sur le DQMH 5. Comme je l’ai indiqué sur le précédemment et sur le forum DQMH, cette version du DQMH utilise l’appel asynchrone pour lancer les clones et ce qui fonctionne correctement, mais ne semble pas libérer la mémoire lorsque l’on arrête le clone.
    Dans le DQMH 4, ils ont utilisé une génération des clones plus classique avec appel du vi serveur (option x08) et surtout l’utilisation de”supprimer ref auto” qui permet de réellement décharger de la mémoire le clone lorsque celui-ci est arrêté. Perso, je préfère cette technique car elle ne risque pas de générer un encombrement mémoire si dans l’application on génère un nombre élevé de clone. Peux-tu me dire ce que tu en penses ?
    Le seul avantage que je vois à l’usage de l’appel asynchrone dans le DQMH 5 est la possibilité rapide de rajouter des paramètres au lancement du clone via la ref strict (Main VI Type–strict_vi_ref.ctl),. Mais j’oublie peut-être quelque chose…

    • Olivier Jourdan Auteur ArticleRéponse

      De mémoire, le changement de méthode corrige un bug lié au root loop (http://www.labviewcraftsmen.com/blog/the-root-loop).
      Ceci étant dit, je ne pense pas que cela crée de problème avec la mémoire. L’appel dynamique avec l’option x80 (call and forget) a le même comportement que l’option “supprimer ref auto” à VRAI.

      Concernant le problème dont tu parles sur le forum NI, je n’arrive pas à le reproduire en partant du projet template fourni avec le framework… Je vais poster directement là-bas pour éviter les échanges croisés.

Répondre à Olivier Jourdan Annuler la réponse

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *