Discussions au sujet de NI LabVIEW

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

Face Avant bloquée - structure évènement

Résolu !
Accéder à la solution

Bonjour à toutes & à tous,

 

Je travaille sur un banc de test dans l'industrie automobile, et lors de la phase de test en question, je dois permettre à l'opérateur de pouvoir régler une consigne pour un régulateur en "direct".

 

Par exemple, avant de lancer le test, l'opérateur doit pouvoir régler une consigne présente sur la FA (et il en sera de même pendant le déroulement du test également, mais nous n'en sommes pas là). Cependant à partir du moment où il change cette consigne (avec les flèches de la commande par exemple), ça me bloque ma Face avant, dans le sens où plus rien ne répond.. En fait  j'utilise un structure event pour régler cette consigne pour ne pas l'envoyer en permanence à mon régulateur, ainsi c'est seulement quand la valeur est changée qu'elle sera envoyée!

 

Je vous mets une image en pièce jointe pour vous montrer comment la structure évènement est utilisé.

 

N'hésitez pas à me demander plus de précisions si cela n'est pas assez clair.

0 Compliments
Message 1 sur 19
3 593 Visites

Bonjour,


Il serait plus aisé de diagnostiquer directement à partir de ton VI, mais à partir de la capture d'écran, voici les pistes à suivre :

  • Décocher l'option "verrouiller la face avant pendant l'évènement" (clic droit sur la structure event et editer les elements)
  • Modifier l'architecture de ta boucle évènement. Tu ne dois rien avoir après, tu dois mettre le code utilisé en dehors d'une modification de consigne dans l'évènement "timeout", pour que cela soit compréhensible.

Cdt,

Michael

“En science, la phrase la plus excitante que l'on peut entendre, celle qui annonce des nouvelles découvertes, ce n'est pas "Eureka" mais c'est "drôle"
Isaac ASIMOV
0 Compliments
Message 2 sur 19
3 581 Visites

Bonjour Michael,

tout d'abord j'ai bien conscience qu'un diagnostic à partir d'une simple image n'est pas chose facile, mais je me trouve dans l'impossibilité de vous envoyer le VI puisque celui-ci fait appel à un nombre important de sous-VIs, certes désactivés puisque je n'ai pas encore les cartes d'acquisition de connectées, mais il faudrait quand même que je vous envoie le projet complet, chose que je ne peux pas faire vu que je développe le programme pour une entreprise et qu'avec les droits de non diffusion, etc..

 

Bref, en fouillant pas mal de temps sur le forum, j'avais pu lire effectivement qu'il fallait décocher l'option "verrouiller la face avant pendant l'évènement", ce que j'ai effectué mais sans succès. Je m'étais aussi fait la remarque de ne pas mettre mon sous-vi de changement de consigne dans la boucle event, puisque le code doit être le plus court possible dans ces structures donc j'avais pensé à comparer dans le timeout la nouvelle valeur lue par la commande avec l'ancienne et d'agir en conséquence dans mon case (si valeurs différentes --> modification de la consigne, sinon on ne fait rien). Mais avant de procéder ainsi, je voulais vérifier si mon problème venait réellement de cet évènement supplémentaire 'Changement de consigne - Valeur changée'; j'ai donc supprimé ce que je venais de coder, re éxecuté mon vi, et quand j'arrive dans cette étape où j'attends que l'opérateur appuie sur le bouton 'Start', j'ai essayé de modifier la consigne plusieurs fois, mais en fait j'obtiens le même problème : dès la consigne est modifiée, ne serait-ce qu'une une fois, j'ai l'impression que la FA se vérouille; du moins je ne peux plus appuyer sur Start ou Stop sachant que si je n'avais pas modifié cette dite consigne, j'aurais pu appuyer sur l'un ou l'autre. Etrange..

0 Compliments
Message 3 sur 19
3 575 Visites

N'y a t'il pas une incohérence avec la valeur du noeud de propriété "essai arrêté ?". Et vers quel état une valeur à vrai renverrait ?

“En science, la phrase la plus excitante que l'on peut entendre, celle qui annonce des nouvelles découvertes, ce n'est pas "Eureka" mais c'est "drôle"
Isaac ASIMOV
0 Compliments
Message 4 sur 19
3 572 Visites

Je t'ai mis en PJ la capture du case Vrai.

En fait, je dois gérer un certain nombre de sécurités sur mon banc tel que le contrôle du surpression, la détection d'un arrêt d'urgence manuel, la présence d'un explosimètre, etc.. J'ai donc en parallèle de ma boucle "Machine à état" (voir seconde PJ), une boucle spécifiquement dédiée aux sécurités de mon programme (troisième et dernière PJ).  Cette boucle tourne à 100 ms et dès qu'elle détecte une sécurité, elle change mon indicateur d'état 'Essai arrêté?'. Ainsi, tout au long de mon programme et dès que j'utilise des structures event pour communiquer avec l'utilisateur, je regarde systématiquement l'état de cet indicateur et j'agis en conséuence (soit fin du test en cours sans mise hors tension, soit fin du test en cours avec MHT du banc, etc..)

Tout télécharger
0 Compliments
Message 5 sur 19
3 569 Visites

Houlla, y a un petit problème d'architecture dans ton code.
Si je suppose bien à partir de tes captures d'écran, tu as autant de structure évènement que d'états dans ta machine d'états :s.

 

Il est fortement déconseillé, et à proscrire d'avoir plusieurs structures évènements dans un VI. Si c'est le cas, cela veut dire qu'il y a un problème dans l'architecture du code. Si c'est juste pour eviter de faire une étape si celle-ci a déjà été réalisé, je te dirais plutôt de faire une comparaison avec la valeur précédente avec un noeu de rétro action.

 

Malheureusement, sans la totalité du code, je ne pourrais pas t'aider plus, Ton programme est trop complexe pour être compris sans une vue complète.


Bon courage pour la suite.

“En science, la phrase la plus excitante que l'on peut entendre, celle qui annonce des nouvelles découvertes, ce n'est pas "Eureka" mais c'est "drôle"
Isaac ASIMOV
0 Compliments
Message 6 sur 19
3 563 Visites

Juste une remarques, quand tu utilises les propriétés activé/désactivé des boutons, pense à faire une initialisation correcte au début de ton programme pour être sur de l'état de tes boutons. Car en mode débug, on a tendance à utiliser le bouton "rouge", et on termine souvent dans des configurations non prévues.

“En science, la phrase la plus excitante que l'on peut entendre, celle qui annonce des nouvelles découvertes, ce n'est pas "Eureka" mais c'est "drôle"
Isaac ASIMOV
0 Compliments
Message 7 sur 19
3 561 Visites

Si je suppose bien à partir de tes captures d'écran, tu as autant de structure évènement que d'états dans ta machine d'états :s.


Non, en réalité regarde la FA en PJ, et tu vas comprendre que j'utilise en réalité des boucles events à chaque fois que j'ai besoin de récupérer un choix de l'utilisateur : par exemple, j'ai donc une structure event dans mon état 'Choix du cycle' où je récupère le type de test que veut réaliser l'opérateur (vidange, purge, charge, etc..). Ensuite en fonction de ce qu'il choisit, certains paramètres vont être désactivés et d'autres activés (état 'Initialisation paramètres') puis j'ai effectivement une autre boucle event dans mon état 'Choix des paramètres' où je récupère les infos de conditions de fin de purge/charge choisies par l'opérateur. Toutes ces boucles event me servent juste en réalité à enregistrer les paramètres d'essais que choisit l'utilisateur. Enfin, une fois le choix ou non de sauvegarder l'essai,  je vais rentrer dans l'état Vidange si l'utilisateur avait choisit une vidange, ou charge s'il avait choisi une charge et ainsi de suite. Dans ces différents états, je retrouve effectivement une nouvelle machine à état décomposant les différentes étapes du test qui va suivre : état 'Initialisation du test' (où je fixe mes vannes de commutation dans un état par exemple, etc..) puis j'arrive dans mon état 'Attente départ' où effectivement il y a encore une structure event mais ici je n'utilise que le time out me permettant de checker régulièrement que l'utilisateur n'aie pas appuyer sur le bouton "Arreter l'essai".

Edit: en réalité ma boucle event dans Attente Départ ne sert à rien, puisque mêlme si elle n'est pas présente, je peux quand même détecter l'appui sur le bouton "Arrêter'", je l'avais en fait créé justement pour permettre à l'utilisateur de régler la consigne de fin de purge (si différente de celle inscrite par défaut) avant de lancer le démarrage du test!

et pour finir, tous mes boucles events dans mon code sont câblés à 100 ms pour exclure le risque d'être bloqué dans l'une d'elles et de ne pas pouvoir en sortir!

Bref, c'est effectivement très compliqué à expliquer et du coup à déboger sans que tu aies devant les yeux l'architecture entière du VI. Et par ailleurs, mon premier état de ma machine est bien sûr l'état idle où j'initialise tous mes boutons, mes clusters, mes graphes, etc!

0 Compliments
Message 8 sur 19
3 559 Visites

As tu regardé où se bloquer le diagramme lors de la réalisation de ce bug, avec le mode pas à pas ?


Tu génères le défaut puis tu cliques sur l'ampoule jaune dans la fenêtre de diagramme, et tu regardes sur quoi tourne le flux de données.

“En science, la phrase la plus excitante que l'on peut entendre, celle qui annonce des nouvelles découvertes, ce n'est pas "Eureka" mais c'est "drôle"
Isaac ASIMOV
0 Compliments
Message 9 sur 19
3 554 Visites

C'est exactement ce que j'ai fait quand j'ai détecté le bug :

j'ai désactivé toutes les boucles que j'ai en parallèle (à savoir celle pour la sécurité, celle pour l'acquisition et celle pour la sauvegarde) pour être sur que ça ne puisse pas provenir de ces dernières puis j'ai relancé le programme, une fois la phase de sauvegarde faite et quand je rentre dans mon état où j'attand que l'opérateur appuie sur le bouton 'Démarrer', j'ai changé ma consigne puis je suis passé dans le mode pas à pas. Et quand je regarde ce dernier, le bug est présent puisque je ne peux plus avoir accès à mes commandes de la FA, cependant le programme continue de tourner et reste en permanence dans l'état 'Attente Départ' : comme je ne peux pas modifier mon bouton 'Démarrer Essai', il reste en permanence à FAUX et le programme boucle cet état..

0 Compliments
Message 10 sur 19
3 551 Visites