Discussions au sujet de NI LabVIEW

annuler
Affichage des résultats de 
Rechercher plutôt 
Vouliez-vous dire : 

IHM complexe avec un nombre important de contrôles / commandes

Résolu !
Accéder à la solution

Bonjour,

j'ai un projet sur lequel j'ai une dizaine d'ihm qui comportent chacune de  100 a 150 contrôle commande (logique et numérique).

Cette ihm dialogue avec un tableau mémoire contenant toutes les valeurs de variables (tableau mémoire rempli par l'UUT)

Aujourd'hui chaque contrôle est géré par nœud de propriété / variable locale. Chaque CTRL/cmd est repris dans une structure event qui reprend : 

- un condition valeur changée de toute les commandes pour mise a jour du tableau mémoire

- une condition activation d'un menu local ? pour définir un menu local si clique droit sur un CTR/CMD

- une condition sélection dans un menu local pour gérer l'appui dans le menu local

- un user event qui vient mettre a jour chaque contrôle commande quand le tableau mémoire est mis a jour par l'UUT (il y a donc dans cet event un case pour chaque ctrl/cmd).

 

Ce projet est dupliqué pour chaque UUT, cela demande un travail non négligeable (le nom le type et le nombre de ctrl/cm est différents).

 

Je me demandais si il n'existait pas un moyen de faire plus simple ? Un ihm en HTML  ? Autre chose ?

 

Merci d'avance

0 Compliments
Message 1 sur 10
534 Visites

Bonjour Vincent,

 

As-tu la possibilité de partager des exemples épurés ? (LabVIEW 2020 ou plus ancien pour ma part)

Face-avant + diagramme dans l'idéal.

 

La première idée qui me vient en tête serait de créer des sous-panneaux réentrants par type de contrôle (type de donnée).

Le projet (unique) contiendrait alors une configuration de sous-panneaux par UUT (dans un fichier par exemple).

X booléens, Y chaînes de texte, Z numériques, ...

De manière à ce qu'un UUT corresponde à une configuration plutôt qu'à un code.

 

Mais ce n'est peut-être pas envisageable, je préfère voir des exemples d'IHM avant de continuer des suppositions.

 

Dernières questions sur le "tableau mémoire", de quoi s'agit-il plus précisément ?

Son type/format change-t-il d'un UUT à l'autre ? Ou bien les UUT formatent leurs données avant de les rentrer dans ce tableau.

 

0 Compliments
Message 2 sur 10
512 Visites

Bonjour,

par programmation a partir d'un fichier de conf j'ai :

- un enum qui comporte toutes les variable (donc leur nom) dans l'ordre (TOUTES les variables nécessaire a plusieurs IHM différentes mais a une seule UUT)

la génération d'un tableau qui dans l'ordre des variable assemble un tableau de cluster avec pour chaque var : Référence, description et et NOM

En fonction des ihm : Un vi permet a l'init de récupérer les info du tableau et de les inscrire dans les contrôles (sous tire et description):

vincent69_0-1718106952742.png

Pour chaque bouton on récupère sa référence et on indique via l'enum son numéro d'ordre dans le tableau mémoire. Ici il n'y a que 22 étapes ...certaines ihm en ont 250.....!! 

je ne peut pas partager les ihm mais en voici une en cours, sans les étiquettes ni sous titres : 

vincent69_1-1718107127180.png

 

Dans la structure event il faut ensuite créer pour chaque bouton les conditions "menu local?" + "activation d'un menu local" + "valeur changée" et tous les "case" de chaque bouton si un user event "tableau mémoire" apparait :

vincent69_3-1718107562815.png

 

pas sur que ce soit plus claire en me relisant ....mais pas facile de repartir sur quelque chose fait par quelqu'un d'autre !

 

La problématique de base est de mettre à jour des ctrl/cmd pour une ihm en particulier depuis un tableau contenant les valeurs de tous les ctrl/cmd de toutes les ihm disponible de l'uut. (et envoyer dans le tableau mémoire la valeur des ctrl quand leur valeur change) ....

 

 

0 Compliments
Message 3 sur 10
483 Visites

Je me permets de repartir sur la base du besoin : mettre à jour des ctrl/cmd, inter-IHMs, à partir de relations communes.

Et pour ne pas trop chambouler par rapport à l'existant, on va garder l'idée derrière l'enum : lister les variables disponibles.

 

PinguX_0-1718114802709.png

 

Le principe est le suivant :

- un fichier de configuration (1 par IHM ou 1 au global) permet d'associer un identifiant à chaque ctrl ("l'identifiant" étant le nouvel enum)

- lors de la phase d'initialisation, chaque IHM cherche les identifiants qui sont contenus parmi ses ctrls

- toutes les IHMs sont abonnées à un même User Event

- lorsqu'une valeur a changé sur une face-avant : envoi d'un event avec l'identifiant lié au ctrl + la nouvelle valeur (peu importe le type)

- à la réception d'un évènement, chaque IHM envoi la valeur à ses ctrl, liés par l'identifiant

 

En terme de performance, ce n'est pas le net plus ultra ... à tester si ça te suffit.

Par contre c'est simple (trop ?).

Et il y a peu d'impact à l'ajout d'un nouveau ctrl ou d'une nouvelle IHM.

 

J'ai mis en attaché le VI de démo, en LabVIEW 2020.

Si besoin d'être enregistré sur une version antérieure, fais-moi savoir.

0 Compliments
Message 4 sur 10
474 Visites

Bonjour,

merci en effet sur le principe le fichier de config par ihm peut être une très bonne solution sans tous revoir !

du coup pour l'évènement 0 il n'y a pas un moyen de programmer " changement de valeur sur n'importe quelle commande de la FAV ?" ou "sélection menu utilisateur ? sur n'importe quelle commande de la face avant ? (pour éviter d'avoir a déclarer dans le case de la structure chaque bouton ...et donc devoir ajouter/modifier a chaque correction/création d'ihm ...

0 Compliments
Message 5 sur 10
455 Visites

Pas à ma connaissance, malheureusement.

 

Une solution de contournement (que je ne recommandes pas spécialement) serait de faire des scrutations "manuelles" de valeurs changées.

Soit en continu sur Timeout de la structure évènement, soit sur les évènements pouvant être source de valeur changée (clique de souris, touche appuyée).

PinguX_0-1718194623632.png

 

Il faut être très vigilant si tu pars là-dessus, une petite erreur peut vite créer une boucle infinie.

Ex: dans l'évènement [1]<Value change> il faut que la nouvelle valeur reçue soit transmise au registre à décalage.
Dans le cas échéant, au prochain passage dans l'évènement [0]Timeout le UserEvent sera perçue de la même manière qu'une valeur changée par l'utilisateur, et créera donc à son tour un UserEvent ... ad vitae eternam.

En plus de ce premier risque, le fait de faire appel à trop de nœud de propriété, trop souvent, n'est pas très sain par expérience.

 

Donc il faudrait commencer à optimiser un peu le procédé, en remplaçant les nœuds par les VIs "Set/Get Control Values by Index" de la palette "Application Control".

PinguX_1-1718195402995.png

 

Pour la sélection dans les menus dynamiques de contrôles, je n'ai pas suffisamment d'expérience pour te répondre là-dessus.

 

0 Compliments
Message 6 sur 10
447 Visites

Bonjour,

 

C'est un classique du développement de synoptique en LabVIEW.
le plus compliqué c'est s'il y a une intelligence à mettre dans le synoptique. et par expérience, ca finit par arriver.

 

Si on est que sur l'affichage et la récupération de l'appui des contrôles, le lien peut se faire par programmation sans configurer le value change pour chaque commande.

Un exemple de solution a été présenté à la GDevCon How to successfully scale UIs in LabVIEW - Iker Segovia Revilla(ULMA) - GDevCon#4 - YouTube

 

Dans les méthodes utilisables et que j'ai déjà utilisé.

Le synoptique (la vue IHM) possède des contrôles et indicateurs.

On écrit un dictionnaire pour le lien des variables.

Chaque Commande/Indicateur stocke lui même la variable à lire (par exemple dans le commentaire)

On enregistre dynamiquement les événements des commandes.

Pour mettre à jour l'IHM, si une variable change on l'applique en fonction du commentaire.

 

Synoptique.png

 

Ce code permet de faire des synoptique presque No Code. Simplement placer des commandes et écrire le nom de la variable dans le commentaire. C'est vraiment un proto très simplifié qui peut faire un point de départ.

Désolé, je n'ai pas vraiment le temps de faire une réponse plus longue.

 

Maxime R.  

  CLA - Certified LabVIEW Architect / Architecte LabVIEW Certifié
  CTA - Certified TestStand Architect / Architecte TestStand Certifié

Message 7 sur 10
431 Visites
Solution
Accepté par l'auteur du sujet vincent69

Voilà une petite astuce intéressante que je ne connaissais pas encore ! Merci Maxime. 😊

 

Du coup, en repartant de mon premier code, il suffit d'ajouter le tableau de référence au nœud "Register For Events" pour ne pas avoir à toucher à la structure évènement. Peu importe si l'on ajoute/supprime de nouveaux contrôles.

 

PinguX_0-1718202175111.png

 

Message 8 sur 10
422 Visites

Tout à fait.

A noter, l'avantage du VI que j'ai utilisé aussi pour lister les contrôles c'est qu'il liste tous les contrôles y compris dans les commandes onglets.

Ce VI est disponible dans la palette Hidden Gems installable depuis VIPM. C'est un vi inclus avec l'installation de LabVIEW mais pas dispo nativement dans la palette.

 

 

Maxime R.  

  CLA - Certified LabVIEW Architect / Architecte LabVIEW Certifié
  CTA - Certified TestStand Architect / Architecte TestStand Certifié

0 Compliments
Message 9 sur 10
415 Visites

bonjour et merci beaucoup messieurs !

J'ai un grosse partie de mon problème actuel qui est solutionné et je vais me faire un template pour mes him futures.

je vais mettre ça en place et du coup j'imagine aussi intégrer un moyen d'exclure certain control de l'envent (je suis certain que ça va arriver un jour!)

En tout ca merci beaucoup !

0 Compliments
Message 10 sur 10
378 Visites