11-23-2013 08:10 AM - modifié 11-23-2013 08:12 AM
Pour ceux que le sujet intéresse ...
Un des gros reproches adressés aux XNodes est ...
vu qu'ils ne sont pas officiellement supportés, et donc n'ont aucune garanties de fonctionnement entre les versions de LV,
il est peut conseillé, voir suicidaire de les incorporer dans un développement quelconque.
J'ai contourné ce problème en offrant la possibilité (une fois les diverses manipulations du XNode terminées),
de convertir le "XNode_résultat" en sous-VI. Le sous-VI reprend exactement le code du XNode, et de plus,
ce sous-VI se reconnecte aux divers Contrôles tel que le XNode l'était. (On peut repasser au XNode avec "Undo".)
Avec un sous-VI (classique), plus de soucis de compatibilité ou de versions.
Une fois le XNode transformé en sous-VI, on peut "ouvrir" ce sous-VI et y faire ce que l'on veut.
Pour réaliser ce code, j'ai rencontré un soucis de taille.
Lors de la création du sous-VI (par la Méthode "SubVI from selection") LV attribue aux Terminaux du sous-VI ainsi créé,
des Noms parfois différents des Noms attribués à l'origine dans le XNode.
Cela se passe d'ailleurs à l'identique quand on crée un sous-VI manuellement sur le BD.
Un fil raccordé à un ContrôleU32 "toto" ne génère pas un sous-VI dont le Terminal correspondant portera le nom de toto.
Dans le sous-VI créé, vous aurez peut-être simplement un Termianl dont le Nom sera "Numéric".
La difficulté n'a pas été de créer le sous-VI lui-même ... mais de le reconnecter à l'identique aux Contrôles externes.
Ceci dit, le fonctionnement de l'Ability ReplaceSelf est subtile ...
LV crée un Diagram temporaire, la compréhension ne ce mécanisme n'était pas trivial.
(3 jours et quasi 3 nuits de recherche )
Donc il est un peu difficile d'expliquer ici (avec de longues phrases) le "pourquoi du comment",
(mais l'analyse du code donnera tous les secrets sur cette difficulté et ses solutions)
(je réponds aux questions)
Le code est contenu dans l'Ability " ReplaceSelf "
ci-joint un XNode pour tester rapidement. (LV2011)
ouvrir le vi "ici_pour_tester" , clic-droit sur le xnode , xnode > sub-vi
Je reprécise que, je n'ai aucune license xnode (bien dommage!)
Les "outils" utilisés sont : le " XnodeManager" et le "Scripting_WorkBench", tous deux dispo sur Lava.
(ce dernier me donne les quelques Noeuds dont j'ai besoin)
Pour le reste, cela reste de l'amusement stricto-perso.
le 11-24-2013 07:20 AM
Well done !
J'aime beaucoup le principe à utiliser :
- juste avant la distribution en exe, ça évite d'avoir un sale XNode et toute les librairies de support aux XNodes dans l'exe...
- pour éviter les soucis de mutation si le VI appelant doit être ouvert avec une version plus récente de LV.
A+
Eric M. - Senior Software Engineer
Certified LabVIEW Architect - Certified LabVIEW Embedded Systems Developer - Certified LabWindows™/CVI Developer
Neosoft Technologies inc.
12-12-2013 03:41 AM - modifié 12-12-2013 03:42 AM
Version 2 - un grand bond en avant
J'ai beaucoup bossé sur cette 2eme version.
21 versions intermédiaires (toutes fonctionnelles) ... pour en arriver à cette version 2.
Au début (version 1), pour la "reconnection", je travaillais avec les Noms des Terminaux (Name et Label.Text)
Tout fonctionnait bien .. jusqu'au moment où je me suis posé la question piège ! ... (je suis un grand tordu)
La dite question est la suivante :
et si le XNode possède plusieurs entrées/sorties qui ont toutes le même Nom ?
et si le XNode possède une ou des entrées/sorties sans aucun Nom ?
La version 1 se plante magistralement devant ce type de situation ! (la nuit qui a suivi fût blanche )
Le code a donc été repensé dans sa totalité.
Cette version 2 se moque totalement des Noms des terminaux du Node.
Cette fois je travaille avec les UID.
J'ai placé en pièce jointe uniquement le code de l'ability ReplaceSelf.
Elle est déconnectée de sa librairie (bien entendu).
Il suffit de faire un copier/coller (uniquement) du code et de le reconnecter dans votre propre ability ReplaceSelf.
Cette ability peut se déclencher via "OnDoubleClick" ou via "BuildMenu+SelectMenu"
Je suis pas mal content.
Pour comparer cette version 2 à la version 1 ...
on pourrait comparer une Renault4 à une F1
à destination de ceux que le sujet intéresse de près ou de loin.
Questions et/ou retours (+ ou -) bienvenus.
le 12-13-2013 01:38 PM
Eric ... c'est peut-être pour toi (?)
il me reste un dernier petit soucis avec ce code.
J'ai trouvé un contournement ... mais sans contournement ... ce serait plus "propre".
J'explique "simple" :
1) tout se passe dans l'Ability ReplaceSelf
2) je transforme le code du XNode en sous-VI comme ceci (ça fonctionne tip-top)
3) Tout fonctionne sans soucis ...
mais ... si jamais il y a un soucis ... je dois pouvoir "replacer" le code du XNode à l'origine (avant subVI_from_selection)
pour cela je pensais utiliser simplement ceci : (car je n'ai pas accès à Undo sur un Diagram qui n'est pas TopLvDiag)
4) En utilisant "Inline" (sans rien d'autre) ... LV crashe.
5) Pour que cela fonctionne je dois faire ceci :
Le "x" est la Ref en rouge dans la 1ere image.
J'ai beaucoup cherché pour trouver ce code ... il fonctionne tip-top, mais cela ressemble à un "contournement de bug".
Il me semble que "Inline" seul aurait du fonctionner.
ce code est "critique" :
par exemple, si je ne convertis pas en "flat_séquence" avant le "remove" ... LV crashe.
la question :
de toute façon ... il n'est jamais normal que LV plante. (LV crashe quand j'utilise "Inline" sans rien d'autre)
Mais ... Ou est mon erreur ? Que devrais-je faire pour que "Inline", utilisé seul, fonctionne ?
Le code complet est en pièce jointe, version 2 (message juste au dessus)
Je suis dans une impasse ... à part ce code "de contournement", je n'arrive pas à trouver la "version propre".
Merci beaucoup (pour avoir pris "la peine de", pour le temps ...)
12-24-2013 08:09 PM - modifié 12-24-2013 08:21 PM
Conversion d'un XNode en sousVI ... j'ai enfin trouvé le Graal
Pou ceux qui préfèrent "voir avant" : unzip, run TESTER.vi, clic-droit sur le node, convertir pattern 4833.
Pour ceux que cela intéressent, j'explique un rien :
L'ability ReplaceSelf a pour but de remplacer votre XNode par ce que vous voulez.
Le "ce que vous voulez" sera du code ... ce code est a construire "soi-même" via scripting.
Ce code scripting se place dans le Diagram de cette ability ReplaceSelf.
Quand un fait du scripting, on "agit" sur un "autre" code, dans un "autre" Diagram. (c'est le but du scripting)
Mais quel est donc ce Diagram sur lequel on va agir ? Ce Diagram "target" se nomme "XNodeGenCodeScratchPad".
C'est l'espace de travail dans lequel vous allez construire le code ... qui remplacera votre XNode.
Ce Diagramme est "la "feuille de brouillon xnode" de Labview.
Dans l'ability ReplaceSelf, l'Input Diagram pointe vers ce Diagram_target XNodeGenCodeScratchPad.
Convertir ?
Il faudrait ...
Que cela "soit propre".
Que le sousVI crée soit connecté comme l'était le XNode.
Que les fils restent à leurs places.
Il faudrait que rien ne bouge ... sauf que le XNode devienne sousVI.
Deux soucis principaux :
Quand on veut convertir un XNode en sousVI, deux problèmes se posent rapidement.
1) labview va choisir lui-même le connector pane pattern ...
c'est foutu pour le "côté propre", les fils qui ne doivent pas bouger ...etc ...
2) labview attribera aux Terminaux du sousVI des Noms qui sont parfois différents des Terminaux du XNode de départ.
ici aussi ... ça coince complètement.
Cette dernière version (le top ) solutionne tout ces problèmes
Elle permet de choisir son connector pane pattern, de choisir les emplacements sur ce connector pane et conserve les noms des I/O.
Rapide explication du code.
That's all.
Quelques petits screenshot sympatiques. (j'aime assez d'avoir "capturé" le Diagramme du XNodeGenCode de LV )
ci-dessous : (screenshot pris à la fin de "For Loop 1" - voir code ReplaceSelf)
A
Après le "move" ... on voit la copie du XNode sur le Diagram_scratchpad.
A1
On entre "dans" cette copie du XNode.
Après le "select all" et le "convert to subVI" ... on voit ce sousVI
A2
C'est le code interne de ce souVI.
On voit que : le Nom des Controls a été modifié ("Dataflow IN" est devenu "Dataflow IN in" et "Dataflow OUT" est devenu "Dataflow IN out" ... parfois c'est encore bien pire)
On voit que LV a choisi lui-même un connector pane. Ce choix est totalement malheureux et ne respecte pas du tout le "cablage" du XNode origine.
Ci-dessous : screenshot pris à la fin de la 2eme itération de "For Loop 2" - voir code ReplaceSelf.
B
La copie du XNode est en partie recablée aux I/O du Diagram_scratchpad.
B1-B2
Les Noms des terminaux du sousVI sont à nouveau comme ils doivent être
Le connector pane a été changé.
Les Controls du sousVI sont "en cours" d'être tous ré-assignés aux emplacements du nouveau connector pane
version jointe en LV 2011
Si ce n'est pas trop "votre truc" ... on en parle plus
Si ça vous "branche" ... questions bienvenues (critiques aussi bien évidemment)
voilou,
le 01-02-2014 04:24 PM
Encore bonne année…
Je n’utilise pas de Xnode, tu le sais… mais bravo pour ton travail. Les explications sont très détaillées. Vraiment bravo. Un vrai travail de passionné.
Luc Desruelle | Mon profil | Mon blog LabVIEW |
LabVIEW Architect (CLA) & TestStand Developper (CTD) | LabVIEW Champion
MESULOG | NERYS
01-02-2014 04:26 PM - modifié 01-02-2014 04:27 PM
Merci Luc.
oui, c'est vrai, toutes "ces choses" me passionnent.
Bonne année 2014 également pour toi Luc.