Discussions au sujet de NI LabVIEW
Pub perso ;-)
Quand on traverse une boucle For avec une ligne d'erreur
et que l'on cable cette ligne d'erreur en sortie de cette boucle For
... "on a droit" au tunnel indexé !
franchement ...
un tunnel indexé avec une line d'erreur ... cela n'a pas de sens.
Que l'on puisse "éventuellement" le placer par le menu ... oui ...
(celui qui indexera un ligne d'erreur sera un grand tordu 
)
mais bon dieu, pas automatiquement, pas "par défaut".
A chaque fois, c'est la même rangaine ... tunnel mode / last value ou SR !
@ouadji wrote:
un tunnel indexé avec une line d'erreur ... cela n'a pas de sens.
Si ca a du sens. Par exemple pour récupérer la premiére erreur d'une boucle for qui ne peut pas être interrompue par un terminal de condition. D'autant que la fonction "merge error" s'emn sort trés bien avec les tableau d'erreur. Elle ressortira la première erreur du tableau. Exemple:
Cordialement 🙂
Bonjour Naity,
ouiiii, d'accord.. mais c'est bien l'exception qui confirme la règle.
Je demande à l'ensemble des utilisateurs de LV dêtre honnête ...
et de me dire le nombre de fois qu'ils ont indexé une ligne d'erreur (!?)
Ce qui me dérange (énormément) est qu'une ligne d'erreur soit indexée par défaut ... comme n'importe quel autre type.
et que dans 98% des cas, "on est bon" pour changer cette indexation en SR.
J'ai lu également ...
"oui, mais avoir des comportements différents suivant le "type" n'est pas une bonne chose."
Et moi je réponds : le cluster d'erreur est objet particulier et totalement central dans l"utiliation de LV
et par cela, il justifie dans certains cas, un comportement particulier.
Dans le chapitre "Le Cluster d'Erreur est un Objet particulier,
ne l'a-t-on pas autorisé à être directement cablé sur un Terminal d'arrêt.
Une "option par défaut" est là pour "aider" ...
et dans ce cas précis, cela n'aide pas dans la grande majorité des cas.
Ceci dit, je suis d'accord ... le "pas de sens" était une affirmation un rien terroriste.
@ouadji wrote:
Je demande à l'ensemble des utilisateurs de LV dêtre honnête ...
et de me dire le nombre de fois qu'ils ont indexé une ligne d'erreur (!?)
Je ne peux parler que pour moi, mais je ne passe que très rarement en last value (plus précisemment, je n'utilise le last value que quand j'au un terminal de condition dans ma boucle for). Le reste du temps j'utilise le tableau et selon les besoins du "handling d'erreur" de l'application, soit je merge en sortie, soit je passe le tableau complet à l'algo d'handling d'erreur pour une gestion plus fine.
Dans mon cas, je ne suis pas pour changer ce comportement.
" je ne suis pas pour changer ce comportement."
Je m'en doutais un peu
ceci dit, et pour être honnête à mon tour ...
cette utilisation des erreurs en Tableau ... me séduit tout doucement,
En fait, je n'avais jamais "pensé" à utiliser une sortie_erreur de boucle de cette façon.
seuls les idiots ne changent jamais d'avis
La seule chose qui me dérange est la non transmission de l'erreur précédente en cas de 0 itération.
Il faut penser au cas par cas. Dans le cas d'une boucle for qui peut eventuellement être executée 0 fois, on peut conserver l'erreur d'entrée en utilisant un registre à décallage. C'est aussi une méthode quand seule la dernière erreur nous interresse. C'est aussi une raison supplémentaire je suis contre l'utilisation du tunnel de sortie simple: il n'a que peu de légitimité en pratique (je sais que j'utilise avant tout le tableau, et le registre á décalage dans des cas spécifiques comme celui que vous citez).
Cordialement
Je pense sincèrement qu'aucun de nous ne fait vraiment les bonnes actions.
- L'utilisation du tableau en sortie est bonne pour garder la vision des différentes erreurs apparues au cours des itérations, mais ne permet pas de transmettre l'erreur dans le cas où l'on fait 0 itérations.
->Il faudrait donc ajouter une structure condition pour les cas spécifiques.
- L'utilisation d'un registre à décalage est la solution que j'utilise le plus.
-> il faudrait utiliser le terminal d'arrêt conditionnel de la boucle FOR, car il n'y a pas vraiment de sens à boucler sur un code avec une erreur en entrée.
Je pense que le comportement par défaut, bien qu'il nécessite aussi quelques clics supplémentaires pour moi (mais je ne cherche pas à concurrencer Darren Nattinger), permet aux gens moins initiés de se rendre compte de ce qu'ils font, et du comprtement exact qu'aura la boucle for. Beaucoup de novices ne se rendent pas compte du comportement du tunnel auto-indexé et changent leur type de donnée par la suite pour ne pas avoir de fil brisé, sans vraiment comprendre ce qu'ils font...alors je me demande comment ils réagissent avec les nouvelles fonctions d'indexation conditionelle ^^. Mais pardonnez leur mon père, ils ne savent pas ce qu'ils font!! ^^
Quoiqu'il en soit, on se rend compte qu'il n'est pas facile de déterminer quel comportement par défaut serait le plus approprié... et puis il faudrait faire attention à ne pas devenir trop assistés non plus!!
Quand je parle de ne pas mettre l'indexation par défaut pour une ligne d'erreur,
je ne parle pas de remplacer l'indexation par un tunel "simple", certainement pas ... mais bien par un SR.
Pour moi, le tunel "de base" pour une ligne d'erreur dans une boucle est le SR.
Utiliser un tunel simple ou un tunel indexé (pour la ligne d'erreur) ... sont pour moi des cas particuliers ( pour des besoins particuliers)
" il faudrait utiliser le terminal d'arrêt conditionnel de la boucle FOR,
car il n'y a pas vraiment de sens à boucler sur un code avec une erreur en entrée."
J'aime bien cette remarque, 100% d'accord.
" il faudrait faire attention à ne pas devenir trop assistés non plus!! "
J'aime bien aussi ça ... parfaitement vrai aussi.
"Ce qui est encore mieux c'est de mettre la structure erreur autour du code chaque VI."
non ... je parlais d'une erreur générée "dans" le vi ... en tout cas, "dans" la boucle.
Dans ce cas, cela n'a plus de sens de continuer la boucle ...
autant stopper celle-ci tout de suite avec la ligne d'erreur sur le stop (le stop_conditionnel pour une For)
Une structure Case_erreur "autour" du code, c'est pour une erreur déjà présente en entrée.
Pour ces erreurs "en entrée', je suis d'accord et j'utilise une structure case.
"Pas d'accord si tu log le flux d'erreur dans la boucle for,
le mieux dans ce cas là est de resortir en tunnel car de toute façons tu n'as pas d'erreur."
Je ne comprends pas votre expression "si tu log le flux d'erreur"
