Discussions au sujet de NI LabVIEW
XNode (Wait(ms) or Multiple + Dataflow)
Résolu !
Un VI 
Pour le Dataflow intégré, le VI Polymorphique 'classique" limite les possibilités aux types déclarés dans les différentes instances. 
Le Graal absolu était donc le XNode !
Peu documenté, il faut tout expérimenter soi-même.
Beaucoup de "travail", beaucoup de recherches, des nuits courtes 
...
d'abord sur le XControl (le petit frère du "grand") et sur le Scripting aussi ( résultat ici )
Ce XNode est "très simple", au sens du Code repris dans les différentes Abilities.
Ceci dit, la "structure" est complète et autorise ... ce que l'on veut.
Le XNode n'étant pas une technologie "ouverte" (et NI en garde bien les secrets),
cela est, et reste, une simple "curiosité" ... une "amusement" (pour les tordus comme moi )
L'aventure était passionnante !
PS:
Ce XNode se nomme "myX.xnode".
soit utiliser "Select a VI" ou simplement le "glisser" sur le BD.
deux façons de passer de 
1) clic-droit sur le XNode, accès au menu.
2) double-clic sur le XNode.
Il s'agit donc d'une simple fonction "Wait(ms) / ms Multiple" avec une ligne de flux incorporée.
Le "truc" est que cette ligne de flux accepte n'importe quels types de données
Bonjour Ouadji,
Beau travail.
Tu peux pas nous faire un petit tutoriel XNode ? J'ai jamais eu le courage de mettre les mains dedans 
Bonne journée.
Cordialement,
Salut Helmut ...
Je commençais à être "inquiet"
aucune réponse ... le "sujet" ferait-il peur ? (me dis-je)
Merci pour le "Beau travail" ... sympa.
J'ai ramé pour trouver la "porte d'entrée" ... "l'esprit du truc", le feeling.
Mais quand on a compris, à la limite c'est plus simple que le XControl.
Pour le moment je suis sur un 2eme XNode.
Une fonction "Select" ... mais avec N inputs. Une fonction graphiquement extensible comme Bundle.
Un Tuto ?
Je ne suis pas un expert_xnode, mais je peux essayer de t'aider pour les "débuts".
Le premier outil a avoir dans sa poche est le xnode_manager ( ici ).
Il va te permettre de créer le squelette de ton xnode et notamment le fichier XML.
Le fichier XML est juste une "déclaration" des différentes "abilities", rien de plus. (pareil pour le XControl)
xnode_manager te permettra d'ajouter ces différentes "abilities" (il faudra les choisir suivant tes besoins)
Au début, elles seront "vides", il faudra y mettre ce qu'il faut 🙂 (comme pour le XControl, ne pas modifier les entrées/sorties prédéfinies)
Une ability est une "chose" que LV appelle suivant les événements du xnode (l'équivalent par exemple de Data_Change pour le XControl)
La 1ere Ability appelée est "initialize". Ensuite "Bounds" pour définir les dimensions de ton xnode,
"GetTerms3" pour définir les entrées/sorties et leurs caractéristiques.
"Images" pour son apparence, et bien entendu "GenerateCode" pour ce qu'il doit "faire".
Pour GenerateCode c'est 90% de Scripting ... il faut se familiariser avec le scripting "avant".
Première manip :
Prendre le xnode_manager ... xnode/new ...
Y ajouter "State.ctl" ... state.ctl est indispensable, il va te permettre d'échanger ce que tu veux entre la plupart des abilities (idem que XControl)
y ajouter "Initialize" et "Bounds". Dans Bounds initialiser la sortie bounds (dimension de ton xnode - width/height)
Stop ...petit test ... faire glisser ton xnode sur un BD et se rendre compte que ton xnode prends les dimensions de "bounds".
Et là ... tu tu te rends compte que ton xnode "réponds" à ce que tu places dans tes abilities. (bingo)
Ensuite créer "GetTerms3" et définir les "entrées/sorties" de ton xnode (va voir dans le mien)
Prochaine étapes :
un grand thermo de café ... et s'y coller ... essayer, tester, encore et encore!
Un event peut déclencher plusieurs abilities ... penser aux breakpoint pour mettre en évidence la séquences et le timing des appels.
Le but ? pour un event donné, savoir qui peut donner des infos, et à qui.
Tout ceci est moins compliqué qu'il n'y parrait ... avec quelques petits "tests" ... on a vite compris la musique.
Prends mon xnode, décortique le, modifie le (pour voir les changements), essaye et teste un maximum.
Le sujet est très peu documenté ... on en parle un peu sur Lava.
Mais tu apprendras 1000x plus en testant toi même qu'en lisant tout ce qu'on a pu écrire sur le sujet.
En retour, pose les quetions que tu veux, j'essayerai d'y répondre.
Bon code !
Salut Ouadji,
Désolé pour le temps de réponse... mais j'ai pas mal trituré ton XNode 😉 qui marche nickel. Vraiment BRAVO!
Pour ce qui est d'un tuto je peux regarder si je n'ai pas des éléments à apporter sachant que c'est une technologie interne à NI et qu'il faut une licence particulière pour les faire (sauf via le XNode Manager de LAVA).
Salut, j'étais au CLA Summit et là j'ai mal à la tête. JKI ne nous a pas parlé de XNode… il faut attendre de revoir le bon forum francophone !!
Je viens de lire le post… très intéressant ! Moi je dis bravo à toi.
J’ai pas regardé le code, mais il est dans mes ToDo…
J'ai parlé de toi au CLA summit... : .../... Ouadji ils sont plusieurs dans sa tête.../...
Bravo
une licence de dév. XNode ?
Je n'ai pas de Licence "XNode".
Je n'ai par ailleurs pas accès aux fonctionnalités propre à cette Licence.
Toutes les Méthodes et Propriétés propre aux XNodes me sont innaccessibles.
Je n'ai pas accès au gestionnaire de dev XNode interne à LV.
J'ai utilisé uniquement "des choses" accessibles "par tous" sur le Net, c.a.d. :
Le XNode_Manager accessible en open source sur LAVA.
Ce dernier n'est pas indispensable ... il suffit d'utiliser un fichier XML déjà existant et de greffer son propre code dans les Abilities.
(Toutes les Abilities "vierges" sont présentes et unlock dans le répertoire de LV.)
Un token accessible à tous qui me permet d'avoir accès au menu "Generated Code" (présent à 36 endroits sur le Net)
Ce dernier "facilite", mais dans l'absolu n'est pas indispensable.
Pour le reste :
Rajouter une constante ... ok, d'accord, je prends!
ceci dit, ce Wait(ms)_Dataflow est déjà derrière moi.
(pas trop le temps de "revenir" en arrière)
gérer un peu plus les erreurs et surtout les corréler avec l'indicateur Generated Code?
Je suis d'accord ... je fais cela dans mon dernier XNode en dev. (Select N Inputs) ... oui, c'est mieux !
fermer les références
là, je me pose une question. (???)
Dans "ModifyCode" , j'ai voulu utiliser la Reférence d'une Structure_Case construite dans "GenerateCode" (Référence passée dans State)
Je n'ai pas pu le faire (!!!) ... les Ref construites dans "GenerateCode" ne sont plus accessibles dans "ModifyCode" (j'ai bien râlé!!!)
Je me suis donc dit :" donc, quand LV termine le code d'une Ability, il ferme lui-même les Ref."
Qu'en penses-tu Eric ?
Et là, je me dis que si j'avais accès au Propriétés et Méthodes des XNodes, je pourrais peut-être piloter la "non_fermeture" de ces Ref.
Mais, je n'ai pas accès à ces fonctionnalités.
epilogue:
Le XNode n'est pas une technologie ouverte par NI. (je le sais, et je respecte totalement)
Ce que je fais reste de la "bidouille" ... avec ce que je trouve à gauche et à droite. (tous des sites "grand-public")
Le non_accès aux Propriétés et Méthodes des XNodes (Class XNode) me fait passer à côté de l'essentiel. (mais je fais avec)
Et pour terminer, rien ne sort de mon PC, c'est du 200% amusement intellectuel, nothing else !
