Discussions au sujet de NI LabVIEW

annuler
Affichage des résultats de 
Rechercher plutôt 
Vouliez-vous dire : 

XControl (question sur l'initialisation)

Bonjour à tous,

 

Un XControl (indicateur).

Quand je le place sur le FP ... il se positionne comme un "controle" ... et apparait aussi comme tel sur le BD.

 

Cela fait 2hrs que je retourne ce pb dans tous les sens.

Le VI "init", le "container state", le code dans Facade/display state change ... rien n'y fait.

 

Existe-t-il un moyen, quand je place mon XControl sur le FP, qu'il se positionne directement en "indicateur" (??)

 

merci à tous.

 

 

0 Compliments
Message 1 sur 12
3 981 Visites

Bonjour,

 

Vous trouverez un exemple ici :

 

https://decibel.ni.com/content/docs/DOC-1180

 

Il s'agit en fait de détecter le dépôt d'un nouveau XControl en jouant sur un flag "Commande / Indicator state" qui va être utilisé dans le VI d'affichage via l'évènement "Changement de direction".

 

Si on a détecté le dépôt d'un nouveau controle, on défini celui-ci en Indicateur via le noeud de propriété qui va bien.

 

Cordialement,

Da Helmut
Voir le profil de Maxime M. sur LinkedIn - View Maxime M.'s profile on LinkedIn
Message 2 sur 12
3 966 Visites

Merci pour votre réponse.

 

J'ai donc ajouté ceci (image ci-dessous) dans "Direction Change" (XControl / structure event)

Cela fonctionne, merci.

 

original5.png

 

mais plusieurs choses ...

 

1) Il me semblait que c'était l'event "Display State Change" (et pas "Direction Change")

    qui correspondait à la détection du dépôt d'une nouvelle instance du XControl (?)

 

Texte présent dans l'Event "Display State Change" :

"Display State changed as a result of dropping a new instance of this XControl ..."

 

2) Dans ce code que j'ai ajouté (dans "Direction Change") ... j'utilise "refnum" provenant de "Container State".

    mais d'où vient cette valeur de "refnum" ?

    où est le code qui dépose cette valeur dans "Container State" ?

 

3) que voulez vous dire par <le flag "Commande / Indicator state">

   Je ne comprends pas ce : "Commande / Indicator State" (?)

 

merci, et désolé pour cette insistance.

 


0 Compliments
Message 3 sur 12
3 958 Visites

Bonjour,

 

 

1) Non c'est le contraire pour moi. Ou avez vous lu ça ? Dans les commentaires du VI sur l'évènement dans la structure ?

 

Moi j'ai ça pour Événement Changement de l'état d'affichage (dans le documentation de LabVIEW) :

 

"Généré sur le VI Façade si l'état d'affichage de la commandeX change suite à l'invocation par l'utilisateur d'une propriété ou d'une méthode sur la commandeX.."

 

Pour Événement Changement de direction (dans le documentation de LabVIEW) :

 

"Généré sur le VI Façade lorsque la direction de la commandeX passe de commande à indicateur ou vice versa."

 

Ce n'est précisé dans aucun des deux évènements pour la documentation.

 

Mais sur le wiki LabVIEW (http://labviewwiki.org/XControl:Abilities:Facade_Ability_VI#Facade_Ability_VI_Events) on a bien ça pour l'évènement de changement de direction : 

 

"The terminal of the XControl is converted from Control to indicator and visa versa. On initial drop of the XControl, or load into memory"

 

2) La valeur de refnum vient du VI d'initialisation du control (xxx-Init.vi) (cluster "État du conteneur" / "Container state"). Ce cluster est "rempli" automatiquement lorsque vous déposez le XControl sur une face-avant / diagramme.

 

3) Le "Flag" est le type de donné défini dans le controle "State.ctl" et utilisé dans quasiment tous les VIs (Init, Facade, etc).

 

Comme sur les images ci-jointes :

 

indic_state.png

 

changement_direction.png

 

Voici le sous VI Led-Ctrl2Ind qui met le flag à 1 une fois que le XControl a été déposé sur la face-avant :

 

changement_direction2.png

 

Cordialement,

Da Helmut
Voir le profil de Maxime M. sur LinkedIn - View Maxime M.'s profile on LinkedIn
Message 4 sur 12
3 940 Visites

Désolé de ne pas avoir répondu plus rapidement. Votre réponse est "dense" et demandait du temps pour y répondre,
ce que je n'avais pas dans l'immédiat.

Bon.

"Ou avez vous lu ça ? Dans les commentaires du VI sur l'évènement dans la structure ?" ... oui.

Quand je crée un nouveau XControl ... New Project / My Computer (clic-droit) / New / XControl
LavVIEW me "donne" un XControl type de "départ".

Première point : Dans le FP de "init", je n'ai pas le "flag" dont vous parlez.
J'ai : Previous Version, Previous State, Current State, Container State, Default Indicator State, Default Control State ... mais aucun "flag".

deuxième point :
voici ce que je lis en commentaires, dans le BD de "facade", pour les events "Display State Change" et "Direction Change"

original5.png

Moi j'ai ça pour Événement Changement de l'état d'affichage (dans le documentation de LabVIEW) :
"Généré sur le VI Façade si l'état d'affichage de la commandeX change suite à l'invocation par l'utilisateur d'une propriété ou d'une méthode sur la commandeX.."

Changement de l'état d'affichage == Display State Change

et pour "Display State Change", moi j'ai ceci (comme sur l'image ci-dessus)
Display State changed as a result of dropping a new instance of this XControl, copying,
undoing an operation or executing a custom property or method on this XControl. Update the appearance accordingly.

On parle "comme pour vous" de "l'invocation par l'utilisateur d'une propriété ou d'une méthode",
mais, de mon côté, on parle en plus de "a result of dropping a new instance of this XControl".

Pour Événement Changement de direction (dans le documentation de LabVIEW) :
"Généré sur le VI Façade lorsque la direction de la commandeX passe de commande à indicateur ou vice versa."

Changement de direction == Direction Change

et pour "Direction Change", j'ai : "The direction of the XControl changed from a control to an indicator or vice versa."
Ce qui est, dans ce cas, la même chose que pour vous.

Donc, petit bilan ...
Concernant le fait de "placer une instance du XControl" sur le FP,
pour moi : cela est géré par l'event "Display Stage Change" .... (dropping a new instance ...)
pour vous: on n'en parle pas ... ni pour un événement, ni pour l'autre.
pour wiki : wiki parle que le "drop" est géré par l'event "Direction Change" ... (soit l'inverse de chez moi)
               Ceci dit (en passant) ... wiki dit que le "load into memory" est géré aussi bien par l'un et par l'autre (??)
               Oui, cela n'a rien avoir ... juste une incohérence qui me fait douter du reste.
               wiki est aussi le seul a parler du drop initial (le 1er ?)

Et si on plaçait un "Breakpoint" dans chaque Event pour "voir" qui intercepte le drop ?
un seul ? les deux ? ... et si "les deux", dans quel ordre ?

Voici le résultat pour un "drop", les 2 events sont sollicités : (multiple tests, résultats identiques)
1er arrêt : Direction Change
2eme arrêt : Display State Change

Il serait donc possible de "réagir" à un drop aussi bien dans un event que dans l'autre.
Mais j'ai remarqué une grosse différence ... voici le code que j'utilise pour placer mon XControl en Indicateur lors du drop.
(oui, la structure condition est inutile ... petit purisme de ma part)

original6.png

Si je place ce code dans "Display State Change"
1) mon XControl se positionne bien en Indicateur lors du drop
2) une fois placé comme indicateur, je peux toujours (par la suite) le faire basculer en Controle, et vis versa.

Si je place ce code dans "Direction Change"
1) mon XControl se positionne bien en Indicateur lors du drop
2) il est verouillé ! plus moyen de le changer en Controle (normal, tous changements fait l'objet d'un "reset" en position indicateur)

L'un et l'autre fonctionne, mais le résultat final est différent.

et pour terminer, un dernier mot sur ce "Flag" (inexistant chez moi lors de la création d'un nouveau XControl)
Le sous VI "Led-Ctrl2Ind" met le flag à 1 une fois que le XControl a été déposé sur la face-avant ...
Je ne vois franchement pas à quoi sert cette mise à "1" de ce Flag  Smiley frustré   ... que je n'ai pas chez moi. (LV 2011)

 

Ceci dit, le canard est toujours vivant, car on ne sait toujours pas entre "Direction Change" et "Display State Change"

lequel des deux est spécialement dédié à la gestion d'un drop. Smiley heureux

 

 

0 Compliments
Message 5 sur 12
3 928 Visites

autre différence entre la doc LV et wiki :

 

wiki :

To enforce this LabVIEW's template XControl has a timeout of  0 ms which finishes the while loop, the XControl can be ended in any of the event cases.

 

LV :

Always terminate the event structure after the timeout. Never terminate the loop in any other case of the event structure.

 

ma compréhension de l'anglais est relative, mais il me semble que ces 2 explications disent l'inverse l'une de l'autre.

 

 

0 Compliments
Message 6 sur 12
3 919 Visites

Bonjour,

 

Je pense qu'il y'a confusion :

 

Les exemples dont je vous parle (flag, copie d'écran, etc) sont issues de l'exemple de XControl dont j'ai fourni le lien dans ma première réponse et non d'un template vide de XControl.

 

Est-ce que vous avez regardé cet exemple ?

 

Le xx-State.ctl est un control dans lequel vous pouvez placer le type de donnée (dans l'exemple d'Aristos Queue (développeur de LabVIEW à Austin) : il est utilisé comme flag du type U64 si je me souviens bien) entier que vous souhaitez.

 

Je ne peux que vous conseiller de pointer ces différences en envoyant un commentaire sur l'exemple que je vous ai donné. Aristos Queue devrait y répondre et vous apporter des réponses plus précises que les miennes qui ne sont issues que de la documentation LabVIEW française et du Wiki.

 

Cordialement,

Da Helmut
Voir le profil de Maxime M. sur LinkedIn - View Maxime M.'s profile on LinkedIn
0 Compliments
Message 7 sur 12
3 908 Visites

Oui, j'ai regardé (de près) l'exemple d'Aristos Queue (AQ)

 

AQ utilise ce Flag uniquement dans "Direction Change / LED-Ctl2Ind.vi"

Ce Flag permet le passage du XControl en Indicateur ... une seule fois, lors du drop.

Ensuite, Flag=1, et le "forçage" en Indicateur n'est plus actif (on peut donc le faire passer en Controle, et vis versa par la suite)

 

Ce "Flag" est nécessaire (pour AQ) parcequ'il a placé le "forçage" en Indicateur dans "Direction Change"

 

j'ai repris l'exemple de AQ et j'ai fait ceci :

 

a) J'ai "vidé" l'event "Direction Change" (plus aucun code)

 

b) J'ai placé le "forçage" en Indicateur dans "Display State Change"

     mais uniquement "Refnum / Property Node / Indicator = True" (plus aucune utilisation de son VI "LED-Ctl2Ind.vi").

 

c) Dans "LED-State.ctl", j'ai remplacé son U64 par un booléen, et j'ai supprimé du Projet le VI "LED-Ctl2Ind.vi"

   Juste pour montrer que "Flag" était utilisé uniquement dans " Direction Change / LED-Ctl2Ind.vi",

   et que "flag" et "LED-Ctl2Ind.vi" sont devenu inutile.)

 

Après cette modification, le XControl de AQ fonctionne parfaitement.

Il se place en Indicateur lors du drop et le passage en Controle est possible ensuite (comme avant)

Et si je lance son VI Read_Me.vi (programme de test), tout est ok.

 

0 Compliments
Message 8 sur 12
3 893 Visites

Placer le code dans "l'init" fonctionne tout à fait bien également. (pour un drop, comme pour un chargement en mémoire)

Cela permet d'utiliser "Default Indicator State" dès le départ.

Ceci dit, j'aime moins, car je dois modifier le code de la routine "init".

 

 

original5.png

0 Compliments
Message 9 sur 12
3 868 Visites

Je me permets de reprendre la discussion pour apporter mon point de vue en espérant ne pas trop ajouter de confusion.

 

Pour la problématique de départ, forcer un XControl à être un indicateur lors d'un drop. Personnellement, je modifierai le code dans init.vi. Cet "ability" est fait pour ça. Cependant, il faut bien remarquer que si l'on fait cette modification on forcera le passage du XControl en indicateur à chaque chargement, ce qui peut être très perturbant pour l'utilisateur du XControl qui est souvent une personne différente du développeur de ce XControl. Si l'utilisateur du XControl décide, après drop du XControl sur le FP de changer ce dernier en indicateur, sa modification sera perdue au prochain chargement avec pour conséquences :

  1. de l'étonnement
  2. une sauvegarde intempestive du vi ouvert sans modification volontaire apparente
  3. plus grave, une modification du code pouvant entrainer des fils brisés

Si l'on veut juste forcer le passage en indicateur au drop il faut mettre le code dans le cas 0.0.0.0 de la structure condition. Ce cas n'étant appelé que lors du drop du XControl et non au moment du load.

 


ouadji a écrit :

 

Ceci dit, j'aime moins, car je dois modifier le code de la routine "init".

 


Le code du init.vi est fait pour être modifié (très utile pour la gestion des versions du XControl, mais c'est un autre sujet), il n'y a pas de raison de ne pas aimer le faire 😉

 

 

Pour ce qui est des événements spécifiques au XControl : DisplayState change, Data change, ExecState Change et Direction change il faut comprendre les choses suivantes :

  1. ExecState Change et Direction change sont là pour permettre au développeur de modifier le comportement du XControl sur des événements d'édition du VI appelant le XControl. Par exemple modification de l'aspect du XControl en fonction du mode, exécution ou édition, du VI appelant.
  2. DisplayState change, Data change sont là pour gérer les changements intervenus respectivement sur state.ctl et sur data.ctl. Réponse à une modification via noeud de propriété ou méthode pour le DisplayState change ou modification de la valeur du XControl via le terminal ou une variable locale ou le noeud de propriété "valeur"

Ce qui rend puissant et complexe le XControl, c'est que le facade.vi s'exécute dès qu'une instance du XControl est en mémoire.

 

 

Espérant avoir été utile et pas trop redondant avec les messages précédents.

 

Cordialement,


Olivier Jourdan

Wovalab founder | DQMH Consortium board member | LinkedIn |

Stop writing your LabVIEW code documentation, use Antidoc!
Message 10 sur 12
3 851 Visites