Discussions au sujet de NI LabVIEW
Débutant : Fenêtre d'initialisation de paramètre
Résolu !
" Je vais essayer de comprendre ce flux d'erreur "
ah ??? quel flux d'erreur ? (dans K.vi ?)
il n'y a rien à comprendre dans un flux d'erreur, c'est un flux ... la propagation de l'erreur s'il y en a une ..
(un flux d'erreur ... c'est aussi un flux de données ... ou la donnée est l'erreur (présente ou pas)
explique moi ce que tu ne comprends pas dans le "flux d'erreur".
ouadji a écrit :
Tout ce qui précède la boucle While sert uniquement pour pouvoir afficher la fenêtre popup proprement.
Ce code précise que l'origine du FP (qui sera visualisé) se trouve aux coordonnées (0,0)
Ah oui d'accord ! Je vais étudier chaque petit bloc pour bien comprendre et savoir refaire !
ouadji a écrit :
La phase "init" exécute le sous-VI (K.vi) ... et donc le flux de données "entre" dans ce sous-VI.
Le flux arrive "sur" la structure Event ... et là .. le flux stoppe.
Pourquoi ? Parceque c'est une structure Event ... et que le code "attend" un événement (pour le moment il n'y en a pas)
Quel événement ? ici, cette structure Event est paramétrée pour répondre à un seul événement, soit : "stop":value change.
A-t-on appuyé sur le bouton "stop" ? ... non ! ... donc la structure Event "attend" !
Pendant que cette structure Event "attend", tu peux modifier comme tu veux la données qui se trouve dans le Contrôle "K".
PS: notons que tant que le flux se trouve dans ce sous-VI ("K.vi") ... dans le main ... on est "bloqué" dans la phase "init".
Pourquoi ? Parceque dans cette phase "init" se trouve ce fameux VI K.vi ... et que celui-ci est en cours, il n'est pas terminé.
Et tant que K.vi n'est pas terminé ... la phase "init" du Main ne sait pas se terminer non plus.
La phase "init" du Main attend que K.vi se termine et lui envoie une données sur sa sortie "K out".
Le Main attend que le flux de données "sorte de K.vi" et lui rende la main.
Avec ça j'ai tout compris le flux de données ! Nickel !
En tout cas merci énormément de ton explication hyper claire et de ton temps ! Ca m'a énormément aidé, je pense avoir tout compris ! Reste à savoir si je sais refaire et adapter à mon cas 
En tout cas je pense maintenant avoir une idée de comment creer un bouton pause par exemple, voir meme un bouton modifier (mes paramètres) ... Ce qui me sera très utile par la suite pour mon projet.
Je vous remercie tout les deux, le sujet est donc résolu (mais pas d'inquiétude, vous allez me revoir bientot avec de nouvelles questions 
)
Erwan
Avec ça j'ai tout compris le flux de données ! Nickel !
Tu dois savoir que le "flux de donnés" est la Pierre Philosophale de LabVIEW, le Graal absolu.
Celui qui prend cette notion "à la légère" ... doit tout de suite arrêter d'utiliser LV.
Le flux de données est la première page du "livre LabVIEW" ... si tu lis cette page en diagonale ou si tu ne ls lis pas ... ferme le livre LabVIEW et programme en C.
C'est une notion qui peut "sembler" simpliste de prime abord ...mais qui peut "jouer des tours" particulièrement vicieux.
Par contre, quand on a acquis le feeling parfait avec ce concept ... on peut s'en jouer et l'utiliser à son profit. (c'est une merveille)
90% des soucis de code viennent d'une compréhension superficielle de ce principe.
Le symptôme hyper classique de quelqu'un qui ne comprend pas cette notion :
- les structures séquences ... et les variables locales.
Le flux d'erreur :
Cette "ligne" sera reliée de fonction en fonction et permettra de propager l'erreur ... si une erreur survient.
Une fonction qui reçoit une erreur à son entrée (d'une fonction précédente qui a généré une erreur ... ne s'exécute pas)
Donc ... dès qu'une erreur survient ... toutes les fonctions qui suivent et qui sont reliées à cette ligne d'erreur ne s'exécuteront pas.
Il y a des exceptions ... les fonctions du type "close Reference" s'exécutent même si une erreur est présente à leur entrée.
(les noeuds de propriété aussi, quand l'option had oc est positionnée ... mais oublie ça pour le moment)
Toutes les fonctions LV ne disposent pas d'une entrée et d'une sortie d'erreur.
Ce flux d'erreur te permettra également de séquencer ton code ... mais (pour moi) son rôle principal est de propager l'erreur.
Tu pourras de cette façon "savoir" quelle est la fonction qui a posé soucis et qui a généré une erreur.
aspect et disposition :
C'est du code graphique ... tu codes en LabVIEW ... tu considères que tu es en train de réaliser une épure.
La "propreté" du flux d'erreur ...
Le flux d'erreur est une ligne droite (pas d'escaliers) qui traverse ton code de part en part, comme une colonne vertébrale.
Je reconnais, que personnellement, j'attache beaucoup d'importance à la propreté d'un code. (à chacun son truc)
Mais quand le code devient un rien complexe ... un code tip-top propre ... point de vue lisibilité et compréhensibilité ... c'est quand même "autre chose" !
Tu verras beaucoup de code "pas propre" (parfois c'est même de l'ordre du "n'importe quoi")
N'en tiens pas compte et obstine-toi (encore plus si tu débutes) à une propreté sans failles ...
Plus tard ... tu me diras "merci" ...et surtout ... tu te diras merci à toi-même.
@Ouadji,
Tout pareil , bravo, ah quand ton propre livre 😄
Comme ça je lirais peut etre un jour la première page concernant le flux de données
Sinon, pour appuyer ses dires, il faut en effet, dès le départ s'obstiner à faire du code propre, car même avec ces bases, malheureusement ils nous arrivent de devoir sortir du code qui ne convient pas à notre niveau d'exigence, mais il faut en être conscient, ainsi tu peux ajouter des commentaires supplémentaires quand de toi même tu juges une partie de ton code insuffisante niveau ergonomie sans avoir ni le temps ni l'argent d'améliorer la chose.
Bonne journée à tous.
@Michael :
" malheureusement ils nous arrivent de devoir sortir du code qui ne convient pas à notre niveau d'exigence,
..... sans avoir ni le temps ni l'argent d'améliorer la chose"
et oui ... ça, c'est une remarque "de terrain" ... quand on ne code "pas tout seul" ... quand il y a un "client" derière.
Je suis d'accord ... c'est "aussi" une réalité. Personnellement, je code seul et je suis mon propre client ... je peux me permettre d'être "idéaliste".
La pédagodie ... un "grand mot" ... mais bon, oui, je pense avois cette "faculté".
J'arrive assez facilement à me mettre dans la peau ce celui qui lit ...
En fait ... je me parle à moi-même et j'écris les phrases "qui me feraient comprendre facilement".
Et en plus quand on a "de l'autre côté" quelqu'un qui est "motivé" ... c'est chouette.
sur ce ... j'ai du boulot au jardin ... a+
D'accord avec les autres, tu explique bien ^^ et merci pour cette explication !
Je connais bien cette propreté de code à adopté (je dis je connais, après j'ai pas forcément la rigeur necessaire 
) vu que j'ai quelques connaissances en java, C et vhdl, mais ici je trouve ça encore un peu différent !
Du coup, par simple curiosité (mais votre avis à tous m'interresse fortement), dirais-tu que mon code est "propre" ? Et vu que je doute que ce soit le cas, qu'arrangerai tu ? (histoire que mon travail soit un minimum lisible. Par exemple je n'ai mis aucun commentaire et je sais que je devrais ...)
(pour expliquer vite fait, c'est une FSM à 4 états dont l'état "end" ne sers pas à grand chose pour le moment, l'état "init" attend l'initialisation des données via ta popup à peine modifié, l'état "wait for start" attends que l'utilisateur appuie sur start, ce qui déclenche l'acquisition de données (pour le moment juste une led et "running") et le bouton start est désactivé, on peut faire alors pause ou stop pour tout arreter --> passage par l'état "end" qui n'est autre qu'un reflexe de vhdl !)
PS : Si vous voyez de grosses incohérences dans mon code, ou des remarques, surtout hésitez pas !! Il s'appelle practice, mais le projet final c'est la meme chose !
Pour le "fond" de ton code ... je n'ai pas regardé en détails (pas le temps de suite, ce soir je regarderai)
Pour la "propreté" ... voici ma version en pièce jointe. (LV2014)
rien de "grave" ... de l'alignement, des espaces inutiles, des "escaliers", de la "disposition", décocher "view as icon",
pour les Contrôles, le label à gauche .... pour les indicateurs, le label à droite ... (ti verras par toi même)
Un escalier ce n'est pas grave ... mais si tu en laisses "un" ... alors pourquoi ne pas en laisser 10, ou 100 ..
Pas d'escalier inutiles, c'est pas d'escaliers inutiles, c'est zéro, c'est aucun. (je parle bien d'escalier inutiles)
attention ! : pour ton "enum", tu dois faire un "type def". (je ne l'ai pas fait ... ce sera pour toi une occasion d'en faire un)
