partage / transfert de données (entre xcontrol et xnode)

[ouadji]

Une question un peu tordue ... qui implique un xnode   ... je tente le coup (malgré tout)

Eric peut-être ? 

Tout se passe en mode édition.

Sur mon BD j'ai un XControl  ET  un XNode .... le but : monitorer le XNode avec le XControl (capturer le séquencement des abilities)

le XControl

Le code du XControl se termine par un "value signaling", cela me permet de réactiver le XControl en boucle (je suis en mode édition)

J'avais déjà utilisé cette méthode pour créer du polymorphisme en mode édition (sans aucun xnode)  ici  cela fonctionnait très bien.

Donc, de ce côté, tout est ok ... une Led dans mon Event_perso (dans la structure Event du XControl) me montre que le code du XControl boucle sans problème (la Led clignote)

Le XNode

C'est un xnode qui ne génère aucun code ... les abilities sont (presque) vides.

Je peux simplement les déclencher.

Dans chaque ability ... je passe le nom de l'ability dans ... une FGV, une Globale, une Partagée (single-process), ce que l'on veut.

et dans le XControl (dont le code tourne en polling) ... je lis l'objet de transfert.

Le souci

Le soucis est de taille ...

exemple : j'utilise une Globale entre le XControl et le XNode (les résultats sont identiques avec une FGV)

J'écris dans le xnode et je lis dans le XControl. Le soucis est que la lecture dans le XControl ... ne donne rien.

Idem dans l'autre sens, toute écriture dans la Globale contenue dans le xcontrol ... n'arrive pas dans la Globale du xnode (et pourtant, c'est en principe la même !)

Et pour cause, je me suis aperçu que dans le xnode et dans le xcontrol, les instances de la Globale sont différentes (ce n'est pas la même Globale !)

conclusion

Je dépose une Globale dans le xcontrol et dans le xnode (la même Globale) ... mais LV crée 2 objets différents.

idem avec une FGV ... même FGV pour les deux ... mais en réalité, LV crée 2 FGV différentes.

Avec ce comportement ... normal que "l'écriture / lecture" ne fonctionne pas.

XControl et XNode feraient-ils partie de 2 process totalement distincts ?

Comment faire pour créer un réel "objet commun" (écriture-lecture) entre les deux ?

Je m'y casse les dents.

une idée ? (merci à tous)

[TiTou · Accepted solution]

Tu as deux instances de ta globales (ou FGV) parce que tu as deux "context" séparés, le code du Xnode ne s'exécute pas dans le "main LabVIEW instance" mais dans un context séparé donc ça complique un peu la communication.

As tu essayé avec un datasocket? ou du tcp?

Sinon, en passant par du VIServer interprocess ça doit pouvoir passer aussi mais c'est un peu plus de boulot.

Plus d'info sur LAVA

[ouadji]

Bonjour TiTou,

Merci pour ton intervention.

" ... parce que tu as deux "context" séparés, le code du Xnode ne s'exécute pas dans le "main LabVIEW instance" mais dans un context séparé"

J'étais arrivé à une conclusion un peu du même ordre (plutôt une "supposition" en ce qui me concerne) ... tu confirmes dans ce sens, parfait.

datasocket ? ou du tcp ? ... jamais utilisé jusqu'à présent ... donc je vais creuser le sujet et tester.

Merci pour le lien également.

[ouadji]

Dans l'idée de "donner un retour" aux questions que l'on pose.

1) pour la communication TCP.

Perso, je n'y avais jamais touché (jamais eu besoin)

Je suppose que je ne suis peut-être pas le seul (?) ... et que cela peut éventuellement intéresser. (ceux comme moi qui n'y ont jamais touché)

Ce n'est pas très compliqué et c'est génial !.

2) Pour donner un visu de ce que je cherchais à faire. (histoire de concrétiser mes questions "tordues")

Monitorer les séquences internes d'un xnode.

"ça" peut intéresser éventuellement certains aussi. (curiosité intellectuelle)

Pour tester :

- dezipper (c'est dans un dossier)

- 2 VIs ... MONITORING.vi  et  TARGET.vi

- placer le FP de MONITORING.vi à gauche ... et le BD de TARGET.vi à droite (de votre écran)

- lancer MONITORING.vi

- faites un glisser-déposer de TEST.xnode sur le BD de TARGET.vi

- vous avez le séquencement des abilities sur le FP de MONITORING.vi

pour "voir" ... (déjà en "déposant" le xnode vous allez "voir"), ensuite, vous pouvez agir sur le xnode :

redimensionner, déplacer, double-clic-gauche, clic-droit-menu, câbler (il y a une "entrée sur le xnode au dessus à gauche)

A chaque manip, le séquencement des abilities s'affiche.

séquence lors de la dépose + câblage de l'entrée + déplacement

Révélation

Comme dab, les xnodes c'est ... "prohibited use and classified"
Je n'ai pas de licence xnode, j'utilise des xnodes existants que je modifie (comme je peux)

C'est "en interne-stricto-perso", c'est de la curiosité intellectuelle, sans plus.

[Eric.M]

Il faut partir du principe que tout code LabVIEW qui s'exécute pendant l'édition d'un VI tourne dans un contexte différent de celui du VI lui-même (les XCtrls sont différents parce que ce sont des face-avant secondaires). Par exemple, les menus s'exécutent dans un contexte nommé NI.LV.Dialog, et les XNodes dans NI.LV.XNode.

Depuis LV 2009, les contextes sont complètement indépendants d'un point de vue accès mémoire. Cela évite des crashes qui se produisaient quand un petit malin voulait utiliser une file d'attente ou un événement utilisateur pour faire passer des données d'un contexte A vers un contexte B.

Du coup, il faut se cantonner aux mêmes techniques de partage de données que pour 2 exe différents (presque).

A+

--Eric

[ouadji]

Merci Eric pour ce complément d'informations.

TiTou avait donné "la bonne piste" ... (après avoir "cherché" un bon moment ... je me suis douté que le soucis était dans cette direction)

TiTou a confirmé ... et surtout m'a donné des pistes de solution.

Et en effet, avec une Communication TCP, cela fonctionne tip-top.