FA complète + FA épurée

[cecileAiro]

Bonjour,

Je suis en train de développer une interface qui devra être affichée sur deux écrans de PC de la manière suivante :

- un premier écran affichera l'interface complète, à des fins de tests et maintenance ;

- un deuxième écran affichera une interface similaire mais épurée de toutes les commandes et indicateurs qui ne sont pas utiles pour l'utilisation de base de l'IHM.

Par exemple :

- le bouton "Stop Application" se retrouvera sur l'interface complète ET sur l'interface déportée ;

- le bouton "Start Test" se trouvera uniquement sur l'interface complète et ne devra pas être visible dans l'interface déportée.

Ce que je voudrais éviter, c'est dédoubler les commandes et indicateurs (ça ne sert à rien d'avoir 2 boutons "Stop Application") pour ne pas surcharger le diagramme.

J'ai pensé à une solution toute simple : customiser chaque commande qui doit être déportée, en dédoublant l'image du bouton de sorte à ce qu'elle apparaisse 2 fois sur la face-avant, mais 1 fois sur l'écran principal et 1 fois sur l'écran déporté.

J'aimerais savoir si c'est le meilleur moyen de faire cela, ou s'il y a un autre moyen de "déporter" ou "doubler" la FA, sans doubler le diagramme ?

Merci de vos retours,

Cordialement,

cecileAiro

[Romain_Duval]

Bonjour Cecile,

Tout dépend de ce que tu entends par Ecran déporté?

Est ce un écran relié à la même unité centrale où s'exécute le programme?

Si tel est le cas voici je t'ai fait un exemple en pièce jointe de ce que tu peux utiliser. le seul inconvénient de ma méthode c'est d'utiliser un "VI launcher" cad un programme qui va lancer les deux IHMs pour toi.

Si c'est un deuxième écran possèdant sa propre Unité Centrale je pense qu'il serait plus judicieux de créer deux versions du programme mode cliet/server.

Dans le programme principal (celui avec le plus de fonctionnalité), serait codé un server TCP/IP qui recevrait des commandes à distance du deuxième PC.

Cordialement,

[cecileAiro]

Bonjour Romain et merci de votre retour,

Il n'y aura qu'une seule unité centrale, et deux écrans.

Je pense que dédoubler le programme en "un programme principal + un programme épuré" serait lourd, d'autant plus que toutes les infos doivent être affichées en même temps sur les deux écrans.

Par exemple, si l'état d'un bouton change sur un des deux écrans, il faut qu'il change également sur l'autre.

Pour le moment, la solution que j'ai utilisé est de dédoubler les commandes qui se trouvent sur l'écran déporté, et de "communiquer" chaque action aux commandes de l'écran principal (et inversement de l'écran principal vers l'écran déporté). Je trouve cela encore trop lourd.

Par conséquent, je me demandais s'il n'existait pas un moyen de créer, sur la même FA, deux "images" d'un objet qui correspondent à une même variable.

Pour résumer : sur la FA, je voudrais faire référence (sur l'écran déporté) à un bouton (de l'écran principal) ; tout doit être sur le même VI et le même PC. Y a-t-il moyen de faire cela ?

Cordialement,

cecileAiro

[Romain_Duval · Accepted solution]

Cécile, j'ai modifié mon post précédent et ai rajouté un code d'exemple qui fait ce que tu veux 😉

Il faut que ton programme soit en mode "réentrant" avec préallocation des ressources pour éviter de partager la mémoire mais tu peux aussi la partager si tu veux. Il faut en effet créer deux instances clones d'un même programme, d'où le main.vi qui va lancer ces deux instances.

Cordialement

[cecileAiro]

Bonjour et merci de votre exemple,

je vais tester cette solution ; j'avoue que je préférais éviter ce type de solution car il faut alors faire particulièrement attention à l'accès aux éléments pilotables du banc, à l'accès simultané de deux opérateurs (un sur chaque écran) et à la mémoire utilisée par l'état "réentrant" du VI (le programme doit déjà gérer plusieurs images très lourdes).

Cordialement,

cecileAiro

[Romain_Duval]

Bonjour Cécile,

Effectivement il y aura plusieurs chose auquel il faut faire attention mais ça ne me semble pas être une mauvaise solution.

Un programme propre consisterait à lire un fichier de configuration et actualiser la face-avant en fonction de cela (rendre visible/invisible des contrôles par exemple).

ça ne me semble par vraiment difficile à mettre en place.

Cordialement,

[cecileAiro]

Re-bonjour,

Je teste actuellement une solution basée sur la vôtre, mais j'ai ajouté deux entrées à IHM_VI.vi.

Ces entrées sont les références des deux VI ouverts dans main.vi.

Je fais ceci pour accéder aux propriétés des commandes de l'un à partir d'une action sur une commande de l'autre.

Je commence avec une IHM simple : un bouton OK et un bouton Stop.

Main.vi m'ouvre donc deux copies de IHM_VI.vi.

Je souhaite donc que, lorsque je clique sur le bouton "OK" de la première copie, les boutons "Stop" des deux copies se grisent.

Je rencontre deux problèmes :

- je pensais que chaque copie avait une référence différente ; ce n'est pas le cas, elles ont la même référence. Par conséquent, comment puis-je faire référence à la deuxième copie lorsque je fais une action sur la première copie ?

- je tente d'accéder à la commande "Stop" d'une copie par les noeuds "FA" puis "Cmdes[]" mais le tableau de Cmdes est vide, je ne comprends pas pourquoi.

C'est la première fois que je fais ce genre d'appel simultané, pouvez-vous à nouveau m'aider sur ce sujet?

Pour ce test j'ai un peu modifié votre exemple forum.zip, je peux en faire des copies d'écran si vous le souhaitez ?

Encore merci,

cecileAiro

[Romain_Duval]

Cecile,

Pour accéder à une copie (un clone) le mieux est de stocker leur référence dans une variable global fonctionnelle (le cas échéant une variable global).

Pour obtenir une référence vous devez utiliser ce code:

En effet si vous regarder la barre de titre des fenêtre clone vous verrez: <nom du VI>: x avec x l'index du clone (donc 1, 2.... suivant le nombre de clones créés)

Cordialement

[cecileAiro]

Bonjour et merci de votre solution, cela fonctionne très bien.

Je n'ai pas eu besoin de recourir aux variables gobales, je les plugue directement en entrée de mon IHM. Y a-t-il un avantage à utiliser des variables globales comme vous le suggérez plutôt dans ce cas-là ?

Grâce à votre exemple j'ai pu obtenir la référence des clones sans problème.

J'ai simplement ajouté un petit timer dans le main pour que les clones s'ouvrent correctement (le main fermait les références avant les clones aient eu le temps de s'ouvrir, du coup ça me posait quelques problèmes à l'exécution).

Encore merci,

cecileAiro

[Romain_Duval]

Non au contraire Cécile,

Les FGV (functional Global variable) sont selon moi bien meilleur car elles vous permettent de créer un moteur d'action (code dans chaque état) et aussi d'éviter les situations de compétition.

Cependant dans votre cas il suffit de récupérer la référence d'un clone. Etant donné que c'est juste de la lecture, une variable globale suffit amplement.

Pour être sûr que l'on se synchronise sur le terme de FGV voici deux liens:

http://forums.ni.com/t5/LabVIEW/Community-Nugget-4-08-2007-Action-Engines/td-p/503801

http://www.ni.com/white-paper/7517/en

et le meilleur pour la fin:  http://zone.ni.com/devzone/cda/epd/p/id/6375

Cordialement,

http://forums.ni.com/t5/LabVIEW/Community-Nugget-4-08-2007-Action-Engines/td-p/503801