Le labo étant encore coincé avec de vieilles licences, impossible d’utiliser les fonctionnalités des versions récentes, et en particulier les modèles QMH et QDMH de développement d’application labview. Profitant de la période spéciale que nous vivons, et histoire de penser à autre chose qu’à l’actualité, je me suis lancé dans les formations NI sur le sujet.
Un des exercices présente le modèle QDMH, que j’ai essayé de reproduire avec la version 7.1. De ce que je crois avoir compris, l’intérêt est d’avoir une structure de base similaire pour tous les développements et de concentrer les variations spécifiques à chaque application dans des structures case.
Une première étape du programme est de créer deux types de communication entre nos futures boucles: soit des évènements, soit des queues ou files d’attente. Les queues peuvent transporter des messages « lourds », des clusters associant une chaîne et un variant, qui transportent des commandes et des données d’une boucle à l’autre. Il est possible à plusieurs boucles d’envoyer des messages sur une queue, mais, pour un bon fonctionnement, il faut n’avoir qu’une seule boucle de traitement de ces messages par queue. Par contre on peut avoir plusieurs queues spécialisées. Elles sont normalement en FIFO, mais il est possible d’inverser cet ordre.
Les évènements ne portent pas d’information autre que leur survenue. Un évènement peut se propager à plusieurs boucles réceptrices en même temps. Ici, je les utilise uniquement pour déclencher l’arrêt du programme (évènement stop).
La phase d’initialisation créé un cluster de queues (une par spécialisation), et un cluster d’évènement personnalisé (avec pour l’instant un seul évènement stop).
Dans le corps du programme, je créé deux types de boucles: certaines associées aux évènements, ou aux queues. Ici en haut, j’ai une boucle de contrôle de l’ensemble de l’application qui, lorsqu’elle reçoit l’évènement personnalisé STOP, envoie un message de STOP sur toutes les files d’attente (queues) en position prioritaire -c’est à dire en LIFO-, avant de sortir de la boucle (donc de cesser de surveiller les évènements).
La boucle du bas, représentative de toutes les autres boucles basées sur les files d’attente, reçoit le message STOP, supprime sa file d’attente et envoie les erreurs possibles au gestionnaire d’erreur.
Ce gestionnaire, ici placé dans un sous VI, est lui-même une boucle qui lit une file d’attente dédiée. Il a le même comportement en cas d’arrêt.
Une boucle dédiée à l’interface utilisateur est placée dans un sousVI. Il s’agit en fait d’une double boucle, avec une gestion d’évenement classique des boutons de la face avant, et une boucle de traitement des messages spécifiques à l’UI (typiquement des demandes des autres boucles pour mettre à jour un indicateur).
Toutes les files d’attente et clusters de file d’attente/d’évènement sont des types personnalisés, de façon à pouvoir les modifier en répercutant le changement de type dans l’ensemble de l’application facilement.
Il y a sans doute un certain nombre de soucis potentiels (quid si une erreur se produit après la sortie de la boucle évènement de contrôle?), mais globalement c’est une assez bonne approximation des modèles proposés par NI sur les versions plus récentes de labview…
L’ensemble des fichiers en zip…