Discussions au sujet de NI LabVIEW
stop multi_while
Résolu !
@cb28 :
abort vi
ça, c'est dynamiter la maison pour stopper la téléviseur. 
@JB :
aucune fonction pour détruire une occurence --> une attente d'une occurence ne peut être terminée autrement qu'en la générant
je ne comprends pas ta remarque JB.
La fonction "wait on occurence" possède une entrée "timeout" ...
ou alors parlerais-tu de l'occurence elle-même, générée par "generate occurence" ?
Mais cela est-il important/nécessaire ... si tous les "wait on occurence" sont arrivés à leur timeout ?
un des avantages de la solution par structure Event
est que l'on peut facilement incorporer un "code_cleanup" en sortie de boucle interrompue. (dans l'event "stop_value_change")
Pour moi, le plus gros avantage de la méthode_Event reste le fait que toutes les boucles stoppent simultanémént,
car la structure Event joue aussi le rôle d'un wait(ms) interruptible.
Salut à tous,
J'arrive un peu tard dans la discussion, les éléments de discussion ayant déjà tous été énoncés à mon avis.
Il n'y a à mon avis pas de solution idéale, et chaque solution peut trouver son intérêt (complexité, évolutivité, réactivité, ...).
Cependant, voilà ce que je peux dire de mon point de vue:
- Fonction abort : Evidemment qu'elle est à bannir, car elle empêche l'utilisation d'un code de clean up en sortie.
- Noeud de propriété ou variables locales : Je préfère les variables locales pour des raisons de tps d'exécution. Pour ce qui est de la gestion du flux de donnée, il suffirait presque de forcer leur lecture à la fin de l'étape par une structure séquence, de même pour l'utilisation de notifications qui malgré la gestion inhérente de flux de donnée, devra bien être utilisée en dernier élément de l'étape en cours.
- Occurences : Je ne connais pas assez leurs limites pour commenter
- Notifications : très utiles, et je suis d'accord avec Ouadji, je n'aime pas non plus l'arrêt par gestion d'erreur. Cependant, une notification juste pour un Stop amène beaucoup de fil à travers ton diagramme et rend le code moins propre (en terme de visuel, pas de programmation).
- FGV : appropriée, peu encombrante, utile pr garder un déterminisme ds le cas d'une utilisation temps-réel, mais effectivement, casse le flux de données.
Ouadji, tu parles d'un Set Stop dans le maitre et Get Stop dans les esclaves. Pour ma part, je suis plus pour que toutes les boucles utilisent un Get Stop, et que toutes les boucles agissent sur un Set Stop en sortant, ainsi, la 1ere qui s'arrête arrête les autres.
- Structure Event : Je ne vois pas directement de contre-indication à son utilisation. Attention toutefois au comportement de la face avant. Par défaut, les événements "gèlent" la face avant pendant leur exécution. Donc l'utilisation de plusieurs structures événements risques de bloquer la gestion de face-avant de manière très répétée, et notamment quand tu voudras agir sur le bouton stop. (L'appui sur le bouton sera bien pris en compte, mais pas directement visible par l'utilisateur, qui pourra croire à un freeze de l'application).
On peut toujours désactiver le freeze de la face avant, mais si des événements sont en exécution, cela peut aussi donner des impressions de non réactivité à l'utilisateur.
Ah si, petit bémol quand même, c'est qu'à part pour gérer ton stop dans plusieurs boucles, je ne vois pas vraiment quel avantage on peut trouver à gérer différents événements utilisateurs dans des boucles séparées.
A+
ouadji a écrit :
@cb28 :
abort vi
ça, c'est dynamiter la maison pour stopper la téléviseur.
@JB :
aucune fonction pour détruire une occurence --> une attente d'une occurence ne peut être terminée autrement qu'en la générant
je ne comprends pas ta remarque JB.
La fonction "wait on occurence" possède une entrée "timeout" ...
ou alors parlerais-tu de l'occurence elle-même, générée par "generate occurence" ?
Mais cela est-il important/nécessaire ... si tous les "wait on occurence" sont arrivés à leur timeout ?
En effet, petite omission de ma part et je complète donc ainsi : une attente d'une occurence ne peut être terminée autrement qu'en la générant ou après le timeout si celui-ci n'est pas infini.
J'ai abandonné les occurences depuis plusieurs années mais je me souviens m'être fait piéger à quelques reprises en oubliant de générer cette occurence "finale" de manière "anormale" (normalement générée par un événement particulier de l'application) dont le seul but était de mettre fin aux attentes (qui n'avaient pas de timeout dans mon cas).
A mes yeux, la principale limitation et la raison première pour laquelle je n'utilise plus les occurences est que, en raison de leur incapacité de transmettre des données, elles ne produisent pas du code modulaire. En utilisant une notification ou une queue, et même si elle ne sert initialement qu'à transmettre une donnée unique du type booléen servant de demande d'arrêt de la boucle, la porte est grande ouverte pour implémenter facilement d'autres fonctionnalités en ajoutant d'autres types de données.
Ces éventuelles adjonctions futures seront grandement facilitées en transmettant par notification ou queue un cluster avec le contenu ci-dessous :
- un enum définissant le type de données
- un variant contenant les données
Le cluster ainsi que l'enum sont évidemment à définir en tant que (strict) typed def.
@Olivier :
Ouadji, tu parles d'un Set Stop dans le maitre et Get Stop dans les esclaves.
Pour ma part, je suis plus pour que toutes les boucles utilisent un Get Stop, et que toutes les boucles agissent sur un Set Stop en sortant,
ainsi, la 1ere qui s'arrête arrête les autres
Je ne parlais pas du cas (que tu évoques) ou la 1er qui s'arrête à cause de la fin de son code ... arrête aussi les autres
Dans ce cas (ton cas) ... oui ... pour chacune, un Get dedans, et un Set en sortie.
Je parlais du cas où l'on désire stopper l'ensemble des boucles depuis un bouton "stop".
Le bouton stop se trouvant directement cablé au terminal_stop dans la boucle Maître ... et aussi sur un SET.
Les autres boucles étant à l'écoute sur un GET.
Pour moi, le gros inconvénient du système FGV, est qui faut initialiser la FGV.
Sans initialisation, avec le SR de la FGV, si tu fais 2x run de suite ... soucis !
-------------------------------------------------
Occurence ..." les limites de"
Quelles limites ?
Je suis dans un cas spécifique où j'utilise l'occurrence pour une fonction bien précise ...
Pourquoi aurai-je besoin que cette occurrence puisse aussi faire des choses dont je n'ai pas besoin (dans ce cas spécifique)
Oui, une notification permet "plus" ... mais je n'ai pas besoin (ici) de ce plus.
Dans ce cas précis de l'arrêt de plusieurs boucles, une Occurrence ne présente aucune limites
par définition du fait qu'elle me permet de réaliser parfaitement la fonction demandée.
-------------------------------------------------
freeze
d'accord avec toi sur ... "attention" au freeze du FP.
Pas pour l'event "stop_value_change" lui-même ... excécuté en principe instantanément,
mais bien s'il y a d'autres gestions d'event dans le vi.
------------------------------------------------
à part pour gérer ton stop dans plusieurs boucles,
je ne vois pas vraiment quel avantage on peut trouver à gérer différents événements utilisateurs dans des boucles séparées.
Il n'y en a pas ... c'est juste pour la gestion de stop.
avec comme avantages:
arrêt instantané de toutes les boucles quelque soient leurs temporisations (tempo générée par la structure Event elle-même)
facilité de placer un code_clean_up dans l'event stop_value_change.
A part ça ... plusieurs Structures Event qui gèrent le même event ... (?) ...
à part l'auto-flagellation ... je ne vois pas trop non plus 
@JB :
En utilisant une notification ou une queue, et même si elle ne sert initialement qu'à transmettre une donnée unique du type booléen servant de demande d'arrêt de la boucle, la porte est grande ouverte pour implémenter facilement d'autres fonctionnalités en ajoutant d'autres types de données.
ok, là je suis d'accord.
Moi je dis que c’est labview qui m’engraine au terrorisme du code.
On trouve de quoi faire péter la baraque même dans la palette de fonction !
Pffff...si on peut même plus dynamiter tranquille alors ….
a+
PS : Super la synthèse d'Olivier !
