Discussions au sujet de NI LabVIEW

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

Flux de données entres boucles parallèles - la galère visuelle des conduits dans labview (channel instance)

Salut !

 

Je viens vous voir pour connaitre vos différentes méthodes de communication de données entre boucles parallèles.

 

Il y a 10 ans, dans mes premiers temps de programmation sur labview, j'avais la fâcheuse habitude (que j'ai vite perdu) de programmer de manière séquentielle dans une seule boucle while... (un reste de programmation grafcet sur automate...). 😰 Et j'ai vite été rattraper par les problèmes que cela engendre : un temps d'exécution lent... et souvent variable. (et je vous parle pas de pas utiliser de sous-vi à l'époque... oui j'ai eu un programme de 15 écrans de long ^^).

 

J'ai donc appris rapidement a paralléliser les tâches essentielles et gagner en efficacité. Aujourd'hui tout va bien, et le seul problème que je rencontre parfois c'est la transmission de données entre boucle, surtout pour celle dont les vitesses d'exécutions sont différentes.

 

- Dans un premier temps, les variables locales ça peut faire l'affaire dans un seul petit VI. Mais je les utilises uniquement sur des valeurs non critique, qui ne nécessite pas forcement que l'état soit synchronisé, surtout dans les boites de dialogues.

 

- Les variables globales, je les utilises surtout entre sous-vi de boucles différentes, généralement en booléen pour connaitre des statuts lents qui changent très peu, ou alors pour avoir une visualisation instantané de capteurs, qui peuvent omettre la variation rapide de données.

 

- Les variables globales fonctionnelles (VGF, ou VG de type 2) : Ici, par contre, pour ce qui est de la transmission de données rapides, comme l'acquisition de données qui doivent être exploités par plusieurs sous-vi, je passe généralement par des sous-vi que j'utilise comme variables globales plus élaborés qui permette suivant un enum (ou une chaine) de stocker, initialiser/vider, restituer les valeurs. C'est un sous-vi qui utilise une structure condition relié à une commande chaine ou enum qui est située dans une boucle while toujours sur stop avec des registres à décalage sans initialisation pour garder les valeurs entre chaque appel. Très efficace, et peut être appelé pour effectuer une de ces fonctions quand on veut. Utile pour les graphes de type XY qui prennent de temps pour regénérer l'affichage...

 

- les files d'attentes : je les utilise uniquement pour les process rapides quand la boucle consommatrice est plus lente ou pour les process long, avec une boucle consommatrice plus rapide (sinon problème de remplissage buffer). Ou alors dans la communication de commande à une boucle de message.

 

- et dernièrement depuis cette année, les conduits (une évolution des files d'attente en gros). Super efficace pour transmettre les données entre les boucles, très utiles avec les tags ou messages, de plus c'est visuel, mais déroutant car ce n'est pas un flux de données...

Par contre c'est là ou je galère avec ces conduits... à chaque nouveau type de données, labview génère un sous-vi stocker non pas dans les VI.LIB de labview mais dans le dossier de documents de la session windows, dans un dossier channels instances. Et le soucis vient donc du fait que si on programme sur plusieurs PC... labview devrait regénérer ces VIs s'il ne sont pas présent sur le PC... sauf que non, même avec labview 2020 ça marche toujours pas... du coup le programme n'est pas facilement exportable, même synchronisé sur un cloud, car il faut copier ce dossier et le coller à chaque nouvelles créations de conduits d'un nouveau type.

 

Aussi, le problème c'est graphiquement, labview de sait pas comment les gérer pour positionner les éléments, oublier la fonction nettoyage... comme les boucles sont en parallèle, et que si il y a des flux dans les deux sens, il est perdu alors quand y'a beaucoup de flux... Là ou les files d'attentes sont uniquement en entrée, les conduits s'utilisent aussi en sortie, et c'est le bordel visuellement.

 

Enfin, le plus gros problème des conduits, c'est qu'ils empêchent de tester un sous-vi, car ils deviennent inutilisables seuls dès qu'un conduit est en entrée ou sortie. Et labview ne bloque pas le lancement du VI, mais génère une belle erreur en ouvrant le sous-vi du conduit 😒

 

Un petit exemple de conduits pour du code en parallèle, c'est moche, très moche, mais efficace :

Kaleck_0-1593779583447.png

ça fait longtemps que j'avais pas eu un programme aussi moche ^^ C'est plus joli dans chaque sous-vi quand même 😁

 

Bon et vous, comment vous utilisez vos conduits ?? Et plus généralement, comment vous structurer vos codes quand vous avez plusieurs fenêtres, plusieurs régulateurs, boucles d'acquisition, générateurs... bref dans un gros programme.

 

Kaleck

 

0 Compliments
Message 1 sur 5
1 972 Visites

Salut Kaleck,

Je sais que les conduits existent mais je ne les ai jamais vu utilisé encore et je ne me suis pas penché dessus. Et ton introduction n'est pas très encourageante.

 

Pour de l'acquisition/traitement (production/consommation) de données j'utilise les files d'attentes. En général après le traitement je stocke la dernière valeur dans une VGF pour pouvoir y accéder depuis n'importe où.

 

Dans les VGF je stocke également la valeur des contrôles de l'interface utilisateur pour pouvoir les utiliser dans les sous-VI et réduire le nombre de nœuds de propriété valeur.

 

Pour communiquer des états internes au programme ou des autorisations j'utilise souvent des variables globales. Ce sont en très grande majorité des booléens. Je stocke aussi en variables globales des paramètres de configuration qui ne changent plus après l'initialisation.

 

Je n'utilise malheureusement pas de sub-panels. Alors je me retrouve avec un méga-cluster de références avec tous les objets de la face avant, que je cable à un sous VI dédié à la mise à jour pour l'utilisateur.

 

J'évite à tout prix les variables locales car pas possible de les inclure dans les sous-VI

 

Yddet

0 Compliments
Message 2 sur 5
1 907 Visites

---

0 Compliments
Message 3 sur 5
1 887 Visites

Salut Yddet, Merci de ta réponse. C'est intéressant de connaitre la méthode de programmation d'autres personnes.  Mais dans la globalité on fait la même chose avec les VG, VGF et files d'attentes. A mon avis, les channels instances sont bien mais faut pas en abusé. J'ai profité du confinement pour faire les cours labview core où j'ai découvert ces fonctions. Le plus dur étant d'avoir assez de recul sur sa programmation pour voir quoi utiliser et quelles données transmettre. Surtout quand le "cahier des charges" évolue au fil du temps... Pour ma part, l'utilisation de plusieurs interfaces est uniquement justifié suivant la quantité d'information à afficher à l'écran, et aussi, comme c'est le cas actuellement sur le projet en cours, d'avoir un écran tactile avec des commandes utilisables avec les gros doigts et que l'on doit aussi voir à distance 3-4m sans difficulté. Par contre je n'ai jamais réussi a utiliser l'intégration d'une interface VI dans une autre interface (face-avant distante ou un truc comme ça)... Je trouve qu'il est plus simple de faire appel à la face-avant style popup qui vient se caler sur celle en cours (sans bloquer son exécution bien entendu), ou alors de passer par un vi qui gère différentes faces avants (genre, panneau de mesure, panneau d'analyse, etc...) que j'appelle généralement launcher et qui est celui qui est lancé au démarrage du VI. A+  Kaleck

0 Compliments
Message 4 sur 5
1 882 Visites

 

Je n'avais jamais utilisé les conduits. Mais le fait qu'ils soient sauvegardés dans "mes documents" est absolument horrible. De plus je ne trouve pas ton diagramme très engageant. Effectivement ça n'a pas l'air de simplifier vraiment.

 

Perso pour les tâches parallèles j'utilise un mix entre les queues et les évenements, et les variables globales. Et parmi les évenements, un événement générique formé d'un cluster "chaîne commande" et "variant données".

 

Je te conseille d'installer et tester le projet d'example du module Delacor QMH. https://delacor.com/products/. Tu installes la librairies depuis le VI Package Manager. Ensuite, tu peux créer le projet d'example associé. Ce projet d'example correspond vraiment au projet classique. Il ne faut pas être rebuté par le nombre de VIs dans les modules, car ceux-ci sont générés automatiquement depuis le menu tools->DQMH->...

 

 

Le piège de tout centraliser dans un VI est à mon sens dangereux. Il faut clairement séparer la commande et l'interface-utilisateur. Quitte à tout sérialiser, ou à tout passer par des variables globales. Utiliser plusieurs VIs comme "sub panels", au lieu d'un seul immense VI, est aussi une bonne idée.

0 Compliments
Message 5 sur 5
1 864 Visites