Discussions au sujet de NI LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Piloter Face avant en ligne de commande

Highlighted

Bonjour ,
Dans mon projet je veux piloter automatiquement les inputs d'un VI (on l’appellera VI_Main) comme si j'interagissais sur la face avant .
Après plusieurs essais j'ai trouvé la solution d'utiliser un exécutable (que l'on appellera VI_Launcher) lancé grâce à une ligne de commande avec arguments .

Mon VI_Main est un VI s’exécutant en continu et est piloté grâce au VI_Launcher (modification d'entrée booleen , string , num) .
A chaque exécution du VI_Launcher les inputs du VI_Main change sans que celui ci ne s’arrête .

Dans le cas ou :
- j’exécute le VI_Launcher.vi en direct (sans command line et sans le builder) cela fonctionne correctement et cela autant de fois que je le souhaite. Les inputs sont modifiés sans fermer le VI_Main.
Dans ce cas les entrées arguments du VI_Launcher sont remplacés par un tableau 1D.
- je lance le VI_Launcher.vi en ligne de commande en utilisant ("C:\Program Files (x86)\National Instruments\LabVIEW 2019\LabVIEW.exe" "C:\AutomatedTest\Launcher Sniffer cmd.vi" -- False True "C:\AutomatedTest\test.txt" 2 ) et cela fonctionne mais je peux pas relancer une deuxième commande car il faut que labview soit fermé . cela veux dire fermer VI_Main ce que je ne veux pas.
- Je lance le VI_Launcher.exe en ligne de commande en utilisant ("C:\AutomatedTest\Launcher Sniffer cmd.exe" False True "C:\AutomatedTest\test.txt" 2 ) et cela fonctionne mais lorsque je lance une 2eme commande le VI_Main ne le prend pas en compte.

Trouvez ci joint les screenshots de diagramme du VI_Launcher et la face avant et la cmd envoyé .

Merci de m'aider sur ce sujet .
Cordialement ,
Luc

Download All
0 Kudos
Message 1 of 7
(146 Views)
Highlighted

J'ai fais un petit projet pour vous montrer ce que je veux faire .(je n'arrive pas à attacher le lvproj dans le message!)

Apparemment tant que labview est en cours d’exécution je ne peux pas relancé mon exe depuis la ligne de commande .

En fait c'est le même comportement que lorsque l'on lance le VI !

"C:\Temp\builds\LaucherCMD\LaucherCMD.exe" True False donne le même résultat que "C:\labview\labview.exe " "C:\Temp\LaucherCMD.vi" -- True False

Comment faire pour ,dans mon exemple, piloter les 2 LEDS par ligne de commande sans fermer le VI TestCMD ?

 

Merci

 

PS:TestCMD est un peu tordu car je cherchais des soluce 😉

 

Download All
0 Kudos
Message 2 of 7
(93 Views)
Highlighted

C'est un peu tordu tout ça 😉

 

Je n'arrive malheureuseuement pas à ouvrir des VIs 2019 sur mon poste actuel. Mais je suppose, pure supposition, que ce que tu souhaite faire ne fonctionnera pas avec des exécutables. Effectivement ce serait une faille de sécurité si n'importe quel logiciel venait modifier les valeurs des contrôles d'un autre logiciel. En principe pour cela il faut explicitement prévoir une interface avec des accès "public".

 

Si tu ne peux pas modifier le logiciel principal pour X raison, je te conseille de perséverer avec des sondes sur les erreurs. Il doit bien y avoir une erreur décrite qui explique pourquoi cela ne fonctionne pas.

 

Si tu peux le modifier, alors je te conseille d'utiliser une interface. Ce qui me semble adapté et très simple, c'est par exemple l'UDP en utilisant comme adresse "localhost" et le port de ton choix.

 

Désolé de ne pas pouvoir t'aider plus.

0 Kudos
Message 3 of 7
(83 Views)
Highlighted

Bonjour et merci de votre réponse .

Je peux modifier le programme principal donc toutes propositions seraient bonnes.

 

pour votre compréhension l'objectif est de faire ce test :

1- lancer le VI_Main qui lit des trames réseaux TCP.

2- envoyer une nouvelle trame sur le réseau (via un outil externe)

3- stopper le VI_Main qui sauvegarde les trames reçus .

4- Analyser le fichier sauvegarder par le VI_Main (via outil externe)

 

Actuellement j'ai réussi à faire fonctionner mon programme ,comme décrit, en utilisant TestStand .

J'ai fait un Custom Step Type qui pilote mon VI_Main grâce au VI_Launcher (pas d’exécutable seul les VIs sont utilisés) .

Je pense que cela est possible avec teststand car il utilise les VIs comme en mode dev. sur labview .

 

Pour des raisons technique, Teststand ne me permet l'automatisation de certains de mes tests. C'est pour ça que je souhaite faire pareil en encapsulant ces étapes dans un script python .

 

Je cherche juste à piloter un VI grâce à des lignes de commande , ou autres, comme si j'intervenais manuellement sur sa face avant.

Vous dites que je peux faire cela en UDP ? avez vous un exemple ?

 

Merci

0 Kudos
Message 4 of 7
(71 Views)
Highlighted

Bonjour,

 

Difficile de pouvoir vous apporter la meilleure réponse sans avoir une vue globale de votre projet.

Pour ce qui est de passer des arguments en ligne de commande à une application, c'est possible, et si j'ai bien compris vous avez réussi, mais par contre, ces arguments ne sont pris en compte que lors de l'appel de l'exécutable. Une fois démarré, il n'est pas possible de lui repasser des arguments de cette façon là sans fermer l'exécutable.

En fait, si je comprends bien, vous souhaitez pouvoir faire dialoguer des applications de manière asynchrone. C'est possible. Y compris en utilisant TestStand. D'ailleurs qu'est ce que vous n'arrivez pas à faire avec le duo TestStand LabVIEW qui vous oblige à ajouter du Python dans la boucle ?

 

Pour ce qui est de piloter un exécutable, c'est tout à fait possible en utilisant le VI serveur. Il suffit d'ajouter la configuration du VI server dans le .ini de votre application, et du coup vous pouvez contrôler tous les contrôles de votre application ou exécuter des VIs directement de votre exécutable depuis l'extérieur. Je n'ai pas le temps de faire de retrouver des liens mais c'est possible. Cependant, je ne sais pas si c'est la meilleure solution.

 

Peut être aussi que dans votre cas, le plus simple serait de mettre en place une application LabVIEW qui permet de recevoir et d'envoyer des trames Ethernet et de mettre en place une communication TCP IP spécifiquement dédié à cette tâche.

Maxime R.  

  CLA - Certified LabVIEW Architect / Architecte LabVIEW Certifié
  CTA - Certified TestStand Architect / Architecte TestStand Certifié

0 Kudos
Message 5 of 7
(44 Views)
Highlighted

Bonjour Maxime ,

"Difficile de pouvoir vous apporter la meilleure réponse sans avoir une vue globale de votre projet.

Pour ce qui est de passer des arguments en ligne de commande à une application, c'est possible, et si j'ai bien compris vous avez réussi, mais par contre, ces arguments ne sont pris en compte que lors de l'appel de l'exécutable. Une fois démarré, il n'est pas possible de lui repasser des arguments de cette façon là sans fermer l'exécutable."

C'est exactement ça .

 

"En fait, si je comprends bien, vous souhaitez pouvoir faire dialoguer des applications de manière asynchrone. C'est possible. Y compris en utilisant TestStand. "

Sur TestStand cela fonctionne correctement j'ai trouvé comment faire .

"D'ailleurs qu'est ce que vous n'arrivez pas à faire avec le duo TestStand LabVIEW qui vous oblige à ajouter du Python dans la boucle ?"

L'utilisation de certaines API et certaines contraintes due à notre Hardware et Software .

 

"Pour ce qui est de piloter un exécutable, c'est tout à fait possible en utilisant le VI serveur"

Merci de l'info , je vais me renseigner sur ce sujet . si vous avez des exemple je suis preneur 😉 .

 

"Peut être aussi que dans votre cas, le plus simple serait de mettre en place une application LabVIEW qui permet de recevoir et d'envoyer des trames Ethernet et de mettre en place une communication TCP IP spécifiquement dédié à cette tâche."

L'application doit être transparente pour les appareils en test et ne doit pas intervenir sur le réseau .c'est juste un outil et c'est pour cela que je voudrait qu'elle devienne compatible sur n'importe quel techno.

 

Pour l'instant je prend comme contournement de lancer l'application et d'enregistrer les trames au fil de l'eau au lieux de les enregistrer à la fin.

je pense que les performances seront bien moins bonne ,cela m'oblige de fermer et re-ouvrir l'application à chaque changement sur les entrées et donc de gérer plusieurs fichiers de log.

Mais bon au moins ça fonctionne 😉

 

Merci encore

0 Kudos
Message 6 of 7
(39 Views)
Highlighted

Un petit schéma explicatif serait certainement le bienvenue illustrant la place de chaque partion de code. sans préciser en détails les éléments, je ne pense pas que cela pose un problème de confidentialité.

 

Pour la communication de l'application, en VI server, il faut faire des recherches sur google on trouve des choses. Dans les exemples aussi. On peut faire des Get/set Control value de cette façon ou encore executer des VI contenus dans l'exe.

 

La communication TCP/IP évoquée serait uniquement en localhost, donc normalement non perturbante sur le réseau.

 

Cordialement

Maxime R.  

  CLA - Certified LabVIEW Architect / Architecte LabVIEW Certifié
  CTA - Certified TestStand Architect / Architecte TestStand Certifié

0 Kudos
Message 7 of 7
(37 Views)