From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
Discussions au sujet de NI LabVIEW
Machine d'état et structure événement: valeurs non mise à jour
Bonjour,
j'ai un programme utilisant une machine d'état.
Dans un des états, j'ai une structure d'événement. Je n'arrive pas à ce que mes variables soient mises à jour dans cette boucle.
Je vous joins un exemple (Example_StateMachine.vi) avec des sous-vis associés.
Merci pour votre aide.
Le fil rose (cluster contenant les clusters 1 et 2) est mis-à-jour lors de l'état "wait". Même si tu modifies le contenu des cluster 1 et 2 lorsque tu es dans l'état "live" ce sera toujours les valeurs de l'état "wait" préalable qi seront affichées. Une solution simple est d'utiliser directement les terminaux "cluster 1" et "cluster 2" dans l'état "live".
Ben64
Je viens faire un tour sur ce sujet car il m'intéresse fortement, n'étant pas très à l'aise avec les clusters (mais j'y travaille !) 🙂
Alors je ne sais pas trop ce que l'auteur du post entend par valeurs mises à jour (je n'ai que Labview 2017). De ce que je vois j'ai l'impression que le but serait d'actualiser les controls présents dans les clusters. Ma méthode (qui fonctionne mais n'est peut-être pas la plus optimisée) est de modifier les variables grâce au bundle by name, et ensuite je les "mets à jour" grâce au unbundle by name qui envoie les données sur les variables locales des controls. (Chaque control étant dans un des états de la structure évènement). Je glisse une image qui sera peut-être plus parlante.
Si des méthodes sont plus efficaces, je suis preneur !
La solution qui m'apparait la plus robuste est l'élimination de la double boucle (une seule boucle est nécessaire) et d'utiliser le shift register pour storer les données. La double boucle rend la compréhension de la logique difficile. L'image ci-dessous montre l'exemple qui est aussi ci-joint. Notez que je n'ai pas testé l'application mais la logique est bonne.
Une approche similaire serait de créer une variable (enum) "État" dans un cluster qui contiendrait aussi cluster1 et cluster2 pour le shift register. Cette variable "État" prendrait les valeurs "Live" et "Wait" et d'utiliser une case structure pour chacun des cas; mais toujours avec une seule boucle.
