Comportements VI et SubVI différents

[FabriceW]

Bonjour,

cela fait maintenant quelques mois que j'utilise LabVIEW pour tester des cartes électroniques et il y a un point sur lequel je bloque et où je ne trouve pas de solution.
Il me semble que le principe de LabVIEW est de pouvoir utiliser des subVI au maximum pour gagner en visibilité et réutiliser des fonctions, mais j'ai remarqué que la plupart du temps, quand j'appelle un VI déjà existant, son comportement n'est pas le même que lorsque je le joue tout seul dans son propre front panel. Du coup je ne fais pas de subVI et je me retrouve avec des schéma énorme. Et comme la fonction zoom n'existe pas c'est assez pénible.

Pour illustrer ce que je dis j'ai fait un VI très simple que j'ai appelé 'compteur', qui prend une valeur en entrée et qui l'incrémente de 1 vingt fois toute les 100ms à l'aide d'une boucle for. Dans ce VI j'ai mis ma sortie à l'intérieur de la boucle pour voir la valeur augmenter au fur et à mesure, et cela fonctionne très bien.

Mais maintenant si je créé un nouveau VI, que j'appelle mon VI compteur et que je lui mets un controle en entée et un indicateur en sortie je vois que le résultat est différent : l'incrémentation ne se voit plus et j'ai l'indicateur qui est mis à jour seulement à la fin de la boucle, avec la valeur finale.

Que faut il faire pour que le VI appellé ait le même comportement que le VI d'origine seul ?

[Mathieu_R.]

Bonjour,

Le comportement est le comportement attendu. Et ceci du fait du 'flux de données'. Le sous-VI est vu comme un nœud. Sur un diagramme, il faut que les entrées d'un nœud soient disponibles pour exécuter le nœud en question. Par nœud, on entend n'importe quelle fonction du diagramme, primitives, sous-VI, structures (For/While/etc.). Et les sorties d'un nœud ne sont disponibles qu'après l'exécution du nœud en question.

Dans votre cas, on a Input en entrée, OK, on rentre dans l'exécution du sous-VI, et une fois les 20 itérations réalisées dans le sous-VI, la sortie peut être 'alimentée', on récupère alors la valeur finale - et seulement celle-ci - dans le code appelant.

En soit, tant qu'il s'agit de traitements, je ne vois pas d'intérêt à faire 'vivre' le compteur à l'extérieur du sous-VI : on y fait un traitement, je n'attends que le retour, ce qui se passe dedans... Si pas besoin d'affichage 'live' de ce qu'il se passe dans le sous-VI, il n'y a rien de plus à faire. Et en première approche, les sous-VIs sont là pour ce type d'usage (boîte noires, fonctions métier, personnalisée, spécifique à votre besoin, en complément des fonctions 'natives' de LabVIEW).

Toutefois, s'il y a besoin d'afficher des choses qui se passent dans le sous-VI depuis 'l'extrieur', il faudra communiquer avec cet extérieur. Plusieurs techno sont envisageables (VI Server, Queues, User Events, Notifier, Channel Wire, etc.) mais c'est là un autre sujet, et cela implique forcément une complexité accrue.

Cordialement,

[FabriceW]

Merci pour la réponse. Là j'ai utilisé un VI très simple mais j'en avais fait un autre à peu près similaire dont je voulais me servir pour générer une rampe en entrée d'un autre VI, et dans ce cas il est indispensable que la sortie bouge au fil du temps. Et l'idée était juste de faire un sous VI pour gagner de la place, mais sans changer le comportement. Je trouve dommage qu'il n'y ait pas un moyen simple de faire ça.
J'ai regardé rapidement les solutions proposées mais ça ajoute effectivement de la complexité. Et pour le moment avec un channel wire je n'arrive pas non plus à avoir ma sortie qui bouge.

[Mathieu_R.]

Deux exemple posés rapidement pour illustrer un Channel Wire (jamais utilisé sérieusement en dehors d'exemples) et une Queue. La boucle master génère un nombre aléatoire, la boucle esclave consomme et affiche la donnée en question. Tel que configuré, on est en 'lossless", c'est à dire que chaque élément de master doit être traité par slave.

Pour trouver le l'aide sur ces fonctions, utilisez l'outil de recherche d'exemple (menu Help » Find Examples... ou son pendant en français si vous utilisez une version française de LabVIEW), et filtrez par sujet, vous devriez trouver des exemples de mise en œuvre des ces outils.

Je reste dubitatif (comme dirait une excellente connaissance) : n'ayant pas plus de contexte, je vais sûrement être à côté de la plaque. Mais à mes yeux, si on utilise un sous-VI, l'aspect animation n'a pas beaucoup de sens. Ou alors, on parle de tâches qui doivent fonctionner en parallèle, et alors un mécanisme de communication entre boucles devient nécessaire (queues ou autre).

Le fait de créer un sous-VI insère un nœud dans le diagramme, et donc, potentiellement altère le flux de donnée.

Flux de donnée modifié, comportement modifié.

Finalement, quel est le besoin ? A quoi ressemble le diagramme (schéma) énorme ?

[FabriceW]

J'ai vu des exemples d'implémentation comme celui là pour le channel wire, d'une boucle vers une autre, mais pas d'un sous VI vers le VI au dessus. J'ai essayé ça mais sans succès :

En faisant comme ça l’Output3 reste à 0 tout le temps. (L’Output2 garde le même comportement qu’avant : mise à jour seulement à la fin avec la dernière valeur)

Pour passer une valeur d’une boucle à une autre j’utilise les variables locales pour le moment, même si je sais que ça casse le flux de données et qu’il vaut mieux éviter. Mais c’est tellement plus pratique…

Sinon comme je le disais dans mon dernier message, le besoin est de générer une rampe sur l’entrée d’un VI (par rampe j’entends un signal qui varie linéairement au fil du temps).

Par exemple sur le screenshot ci-dessous, initialement j’avais une entrée manuelle pour le Duty cycle. Le but était de faire varier ce duty cycle, j’ai donc fait un VI RAMP pour ça. Mais lorsque j’ai lancé mon VI global je me suis rendu compte que le duty cycle ne bougeait pas. J’ai donc débranché et mis mon VI RAMP plus bas et mis un indicateur dessus pour voir sa sortie, et je l’ai remplacé directement par son code (partie tout en bas qui fournit ‘Output Data’). Et comme ça le duty cycle varie comme prévu, et je vois que la sortie de mon VI RAMP ne bouge pas…

En conclusion je dois mettre tout le code qui prend de la place sur mon schéma, alors que je préfèrerais avoir juste mon VI RAMP à la place.