Discussions au sujet de NI LabVIEW

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

Stopper un programme sous condition et afficher un message à l'utilisateurs

Bonjour à tous, 

 

Je suis encore sur le même projet qui relie arduino et labview pour un banc de test automatique.

 

J'ai deux soucis, et donc deux questions :

 

- Premierement, j'aimerais pouvoir stopper mon diagramme sous une condition fausse, je m'explique, j'ai auto test entre deux capteurs de température avec une tolérance de fonctionnemment de 2degrés , ma valeur doit donc se trouver entre -2 et 2, pour l'instant sa va, pas compliqué, seul probléme je n'arrive pas à stopper ma condition lorsque ma valeur est hors tolérance. J'ai essayer en activant un bouton stop dans ma boucle mais sa ne marche pas, pourquoi, surement que sa vient de mes connaissances techniques, et il me faut aussi un affichage d'un message "d'alerte" vers l'utilisateurs, j'ai cherché du coté afficher un message à l'utilisateurs, mais il ne s'affichage jamais...

 

-Deuxiemement, pour effectuer un test de surchauffe de mon appareil, il faut que l'utilisateur retire un panneau de sécurité, pour effectuer ma mesure l'utilisateur doit être avertis qu'il à une action à effectuer sur l'appareil, et donc le programme doit se mettre en pause le temps qu'il le fasse, et qu'il valide pour relancer le programme.

 

Si vous avez besoin de plus de précision, n'hésitez pas.

 

Je vous lie le diagramme, 

0 Compliments
Message 1 sur 36
4 606 Visites

Bonjour,

Je vous conseille de vous orienter vers un programme machine d'état, des exemples sont disponible sur labview.

ça vous permettra de résoudre tout vos problèmes, puisqu'il est possible en codant correctemeent de ne pas attendre qu'une séquence soit fini.

Cordialement
L.MICOU
Message 2 sur 36
4 587 Visites

 Il y a tout de même un peu plus que ça.

 

Pour répondre à vos question dans un premier temps :

 

  1. 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...
  2. 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: http://www.ni.com/getting-started/labview-basics/f/dataflow

 

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 : http://www.ni.com/tutorial/14120/fr/

 

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 🙂

CLAMaxime -- Kudos are a great way to say thank you
Message 3 sur 36
4 578 Visites

Merci de ta réponse, elle ma permit de découvrir la fonction Stop qui fonctionne trés bien... 

Merci, j'ai vraiment eu l'air bete quand j'ai remarquer que je me prennais la tête pour pas grand chose.

 

Je laisse le post ouvert au cas ou si j'ai d'autre question et je le passerais résolu surement en fin de journée.

0 Compliments
Message 4 sur 36
4 561 Visites

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" 🙂

CLAMaxime -- Kudos are a great way to say thank you
Message 5 sur 36
4 557 Visites

Oui c'est bien de la fonction "gros stop" que je parle, sa ne me gene pas d'utiliser cette fonction barbare car dans tous les cas le programme doit s'arreter entierement à la partie dont je parle , si les capteurs de températures ne sont pas fonctionnels (partie principal du banc de test) les tests ne doivent pas s'effectuer. Je me penche sur la seconde partie, soit la deuxieme question et je regarde se que je peux faire, mais je pense être dans la bonne lancer.

edit: je n'est pas trop le temps de me pencher sur l'optimisation de mon diagramme, il faut juste qu'il fonctionne assez pour être présentable, sachant que les personnes à qui je présente le programme n'auront pas accés un diagramme

0 Compliments
Message 6 sur 36
4 547 Visites
Le but d'organiser son code est surtout de pouvoir le relire et se replonger dedans plus tard si besoin de modifications. Cela permet aussi d'acquérir quelques bonnes pratiques sur LabVIEW pour d'éventuels futurs projets.

Mais libre à vous de le garder tel quel 😉
CLAMaxime -- Kudos are a great way to say thank you
0 Compliments
Message 7 sur 36
4 538 Visites

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 Smiley clignant de l'œil , mais merci de vos conseils Smiley heureux

0 Compliments
Message 8 sur 36
4 532 Visites

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 Smiley clignant de l'œil , mais merci de vos conseils Smiley heureux


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.

Message 9 sur 36
4 528 Visites

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 Smiley clignant de l'œil , mais merci de vos conseils Smiley heureux


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 Smiley indifférent

0 Compliments
Message 10 sur 36
4 517 Visites