le 02-24-2012 07:36 AM
Juste une remarque je pense qu'il faut mettre un registre à décalage sur la gestion d'erreur de la boucle For car si une erreur arrive en entrée après 1000 boucles elle sera perdue.
Je ne pense pas, il n'y a que si la boucle n'executait aucune iteration que la valeur serait perdue, mais dans le cas présent ce n'est pas possible puisque le nombre d'itérations est fixé à 1000, la ligne d'erreur va véhiculer 1000 fois la valeur d'erreur présente initialement sur le connecteur d'entrée de la boucle.
tu as raison. Et dans cet exemple il n'y a pas besion; mes excuses . J'ai fait une remarque sans assez vérifier.
Mais sur le principe pour argumenter ma remarque il faut le faire:
> si la boucle FOR ne s'éxecute pas : l'erreur est perdue
> si une erreur est réalisée dans la boucle FOR sans registre à décalage elle est perdue (sauf si à la dernière intération mais si à la 2éme sur 1000)
Et c'est pourquoi il faut câbler l'erreur sur un registre à décalage dans un boucle FOR
Par ailleurs Helmut; qui avait raison comme toujours; semble d'accord sur ce principe
Comme j'ai écrit une bêtise alors un conseil : s'il peut avoir une erreur dans une boucle For il peut être intéressant de câbler "Conditional Terminal" donc arrêt sur erreur
Luc Desruelle | Mon profil | Mon blog LabVIEW | Auteur livre LabVIEW : Programmation et applications - G Web
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD) | LabVIEW Champion
MESULOG - LinkedIn site | NERYS - NERYS Group
| directeur CEO MESULOG
| CODIR - NERYS group
le 02-24-2012 07:39 AM
Helmut O'Brian a écrit :
Bonjour Luc,
En effet les registres à décalages...Un oublie de ma part dans cet exemple...
Cordialement,
Salut Maxime; Tu as raison et en plus tu me donnes un compliment!!! t'es trop gentil. bon WK
Luc Desruelle | Mon profil | Mon blog LabVIEW | Auteur livre LabVIEW : Programmation et applications - G Web
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD) | LabVIEW Champion
MESULOG - LinkedIn site | NERYS - NERYS Group
| directeur CEO MESULOG
| CODIR - NERYS group
le 02-24-2012 07:47 AM
le 02-24-2012 07:59 AM
J’approuve ta synthèse et c’était le but de ma remarque :
Helmut O'Brian a écrit :Pour moi il s'agit d'un réflexe pur et dur que j'essaie de mettre en place, c'est à dire toujours mettre un registre à décalage sur les erreurs dans les boucles...
Luc Desruelle | Mon profil | Mon blog LabVIEW | Auteur livre LabVIEW : Programmation et applications - G Web
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD) | LabVIEW Champion
MESULOG - LinkedIn site | NERYS - NERYS Group
| directeur CEO MESULOG
| CODIR - NERYS group
le 02-24-2012 08:44 AM
je suis en lv 2010,
pourquoi avoir ajouter cette particularité ? quelle est la difference entre un "asynchronous vi call "et un vi call dont on supprime
l'option attendre la fin ?
Cdt
Tinnitus
le 02-24-2012 08:53 AM
tinnitus a écrit :
je suis en lv 2010,
pourquoi avoir ajouter cette particularité ? quelle est la difference entre un "asynchronous vi call "et un vi call dont on supprime
l'option attendre la fin ?
Cdt
Tinnitus
L'avantage du "Asynchronous VI Call" par rapport à la méthode "Run VI", c'est que le premier offre un accès au connecteur du VI à exécuter de manière asynchrone, ce qui facilite grandement le passage de paramètres d'entrée au VI appelé.
C'est possible de le faire néanmoins en utilisant la méthode Control Value.Set mais c'est plus fastidieux en terme de codage.
02-24-2012 09:00 AM - modifié 02-24-2012 09:00 AM
Bonjour,
En complément de Yohann, on a également le VI "Wait On Asynchronous Call" qui permet de récupérer les données des indicateurs éventuels du VI dont l'exécution vient de se terminer (dans le cas d'un Call-and-collect)...Ce qui est plus simple que de les récupérer avec les noeuds de propriétés etc...
Cordialement,
le 02-24-2012 09:09 AM
Merci à tous.
Pas mal d'infos, je vais regarder tout ça de près.
y'a du pain sur la planche !
merci à Luc pour ses liens, notamment la "LabVIEW Style Checklist".
merci également à Luc pour son petit snippet démontrant l'utilité d'une rétroaction dans une boucle For.
Ceci dit, pour une boucle For,
vérifier si le nb d'itérations est explicite (N), ou implicite (indexation)
vérifier si l'erreur est utilisée ou non dans la boucle (ici, idem pour While),
vérifier si ... etc ...
Même si cela est intéressant sur un plan théorique de se poser ces questions,
je suis d'accord avec Helmut qui prend l'habitude de toujours placer dans ses boucles
un registre à décalage sur l'erreur.
Personnellement, je n'ai pas encore le réflexe de gérer l'erreur.
C'est un aspect totalement nouveau par rapport à l'assembleur.
Et pourtant... intéressant pour l'erreur elle-même, mais également pour le flux.
Petit clin d'oeil à Luc qui aime les lignes d'erreur "droite"
Mais je comprends pourquoi. C'est un esprit de développement en fait, cela donne une ligne visuelle de continuité dans le VI.
Promis Luc ... ça n'arrivera plus !
merci à tous.
02-24-2012 09:14 AM - modifié 02-24-2012 09:15 AM
Sous LabVIEW un code propre, aéré, avec des noms de sous-VIs et de controles explicites n'a quasiment pas besoin de commentaires (ou très peu), je dirais même qu'il se commente de lui même.
le 02-27-2012 04:03 AM
Salut tout le monde,
je me permet de faire un petit retour sur le sujet premier du fil, à savoir les appels dynamique de VIs. Le sujet et vaste et "complexe" aussi je permet de vous conseiller de regarder ces 2 vidéos sur le sujet :
http://vishots.com/dynamic-process-vis-in-labview-part1/
http://vishots.com/dynamic-process-vis-in-labview-part-2/
C'est en anglais, mais il me semble assez facile à comprendre. Cela n'aborde pas les nouveautées de LV2011, mais cela n'enlève rien à l'intérêt du propos.
Bonne journée à tous.