Discussions au sujet de NI LabVIEW
Stopper un programme sous condition et afficher un message à l'utilisateurs
le - dernière modification le par
Content Cleaner
Il y a tout de même un peu plus que ça.
Pour répondre à vos question dans un premier temps :
- Le résultat de la comparaison pour la tolérance n'est pas câblé au terminal de condition de boucle. Elle ne peut donc pas arrêter le VI. Par ailleurs le terminal de condition de boucle est positionné sur "Continuer sur condition vraie". Normal donc que le bouton STOP n'arrête rien lorsque vous passez à vrai. Enfin la boîte de dialogue ne s'affiche jamais car vous mettez son terminal "Activer" à faux...
- Pour votre mise en pause et vu que vous n'avez qu'une boucle, un simple pop-up devrait suffire. Ou alors créez une étape "Pause" qui bouclera tant que l'opérateur n'aura pas agit sur le système.
Il reste néanmoins d'autres "problèmes" que vous pouvez régler facilement. Vous pouvez notamment supprimer une bonne partie des variables locales présentes en affichant directement les résultats sur les indicateurs associés. Ceci permettrait de supprimer l'étape 6 par exemple. De même, pensez flux de données ! Dans l'état actuel, certaines étapes pourraient être simplement supprimées sans modifier l'ordre d'éxécution du programme.
Une aide pour bien comprendre le principe: https://learn.ni.com/learn/article/labview-tutorial-french
Comme le suggère Lulu, une machine d'états permettra d'arrêter le programme dès la détection d'une valeur hors tolérance sans attendre que l'ensemble de la séquence se termine.
Plus d'infos : https://www.ni.com/en/support/documentation/supplemental/16/simple-state-machine-template-documentat...
Bref, quelques modifications simples qui pourraient vous être utiles à l'avenir et qui rendra le VI plus facile et agréable à lire/maintenir. N'hésitez pas si vous avez d'autres questions 🙂
Si c'est bien de la fonction "Arrêter" (le gros panneau STOP) donc vous parlez, je vous déconseille son utilisation, au moins dans votre cas. Une simple condition de boucle et un programme correctement construit sont largement suffisants et évitent d'avoir recours à des méthodes "barbares" 🙂
Mais libre à vous de le garder tel quel 😉
Je dois finir mon diagramme avant le 22 juin en tenant compte des erreurs que je peux rencontré je préfére garantir qu'il fonctionne au moment de ma présentation, et je penserais à l'optimisation aprés mes exams 
, mais merci de vos conseils 
Bentox a écrit :
Je dois finir mon diagramme avant le 22 juin en tenant compte des erreurs que je peux rencontré je préfére garantir qu'il fonctionne au moment de ma présentation, et je penserais à l'optimisation aprés mes exams
J'étais comme ça aussi jusqu'à il y a peu, et puis je me suis rendu compte que "l'optimisation" consistait à tout recoder, donc à jeter tout mon premier jet de code.
Quand on commence c'est effectivement plus long de bien structurer son code car on ne sait pas trop comment faire et ce n'est pas très intuitif (structurer en sous VI, rassembler les éléments homogènes dans des clusters, réaliser de machines à états si besoin, éviter les variables locales lorsque cela n'est pas utile, documenter la bulle Ctrl+H, supprimer au maximum les séquences empilées...) et puis petit à petit on se rend compte qu'on gagne finalement beaucoup de temps à avoir un code propre et flexible (on réutilise des VI, on sépare proprement les étapes du processus, on se rend compte qu'on a plus 36.000 fils qui passent partout le même nombre de variables locales).
Ce n'est pas dramatique d'avoir un code pas très propre, c'est même courant lorsqu'on créé "juste un petit VI pour un petit truc mais qu'au final on débuggue longtemps et qu'on rajoute pleins de fonctions". Mais l'étape d'optimisation de la lisibilité n'est pas du tout accessoire pour avoir un code réutilisable.
ec01 a écrit :
Bentox a écrit :
Je dois finir mon diagramme avant le 22 juin en tenant compte des erreurs que je peux rencontré je préfére garantir qu'il fonctionne au moment de ma présentation, et je penserais à l'optimisation aprés mes exams
J'étais comme ça aussi jusqu'à il y a peu, et puis je me suis rendu compte que "l'optimisation" consistait à tout recoder, donc à jeter tout mon premier jet de code.
Quand on commence c'est effectivement plus long de bien structurer son code car on ne sait pas trop comment faire et ce n'est pas très intuitif (structurer en sous VI, rassembler les éléments homogènes dans des clusters, réaliser de machines à états si besoin, éviter les variables locales lorsque cela n'est pas utile, documenter la bulle Ctrl+H, supprimer au maximum les séquences empilées...) et puis petit à petit on se rend compte qu'on gagne finalement beaucoup de temps à avoir un code propre et flexible (on réutilise des VI, on sépare proprement les étapes du processus, on se rend compte qu'on a plus 36.000 fils qui passent partout le même nombre de variables locales).
Ce n'est pas dramatique d'avoir un code pas très propre, c'est même courant lorsqu'on créé "juste un petit VI pour un petit truc mais qu'au final on débuggue longtemps et qu'on rajoute pleins de fonctions". Mais l'étape d'optimisation de la lisibilité n'est pas du tout accessoire pour avoir un code réutilisable.
Je me doute que l'optimisation est primordiale, mais je n'ai jamais eu de "cours" sur labview, j'ai tout appris par moi même depuis le début, et partir d'un VI vide pour crée un banc de test automatique en raliant deux language de programmation distinct était un peu difficile pour moi.
L'optimisation viens grâce à vos commentaires sur toutes mes questions et je vous remercie, mais le temps que j'ai pour finir est trop limité pour que je me penche dessus malheureusement... Je suivrais vos conseils quand j'aurais plus le temps, soit aprés mon examen.
Tant que j'ai des personnes patientes et compétentes sous la main, j'aimerais savoir comment générer un rapport à la fin de mon banc de test, il faut juste que je récupere mes valeurs affichés sur ma facade avant, j'ai essayé d'utilisé la fonction "gén rapport" mais il me met touours une erreur de fils non connectés, si vous pouvez m'eclairer une fois de plus 
