Discussions au sujet de NI LabVIEW

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

Stdin - Stdout (?)

Une question (recherche) assez particulière ...

 

mais la finalité étant du code Labview ... je "risque" (on ne sait jamais ... il y a des "cerveaux" derrière ce forum Smiley heureux )

  

j'explique : (du mieux possible)

 

Les jeux d'échecs "pro" se composent de 2 choses ... un "GUI" (Graphic User Interface) par exemple Arena et un "Moteur" (il y en a des dizaines)

 

Ceci dit, dans mon ChessEngine actuel, j'ai également séparé complètement les deux.

Pour l'instant "mon GUI" dialogue avec "mon moteur" via un canal d'échange composé de 2 Notifiers (questions et réponses), ça tourne tip-top.

 

Pour les jeux "pro" ... GUI et Moteur communiquent via un protocole ... le plus utilisé est le protocole UCI (Universal Chess Interface)

Rien de bien compliqué dans ce protocole, c'est simplement du texte :

 

exemple de dialogue (à l'initialisation) :

Arena : UCI?

Moteur : UCI_ok

Arena : ready?

Moteur : ready_ok

etc

 

C'est le GUI qui "lance" le moteur, c'est donc lui qui prend la main pour le dialogue.

 

Le GUI écrit sur les entrées/sorties "Stdin et Stdout" du moteur.

Le moteur scanne son entrée stdin ... et répond sur sa sortie "stdout".

 

J'ai déjà fait pas mal de recherche ... j'ai trouvé un moteur écrit en C, open source et assez simple. (et qui fonctionne tip top avec Arena)

Le code realtif au dialogue est quasi minimum. Le gars utilise " fgets " pour les messages venant du GUI, et " printf " pour y répondre.

J'ai essayé d'implémenter un "fgets" sous LV via DLL ... sans succès jusqu'à présent.

 

J'ai également lu d'autres choses ... via un pipe (api windows CreatePipe) et ReadFile

Ici on redirige les entrées/sortie "stdin et stdout" vers un pipe ... et on dialogue avec le pipe.

 

J'ai déjà testé pas mal de choses, sans résultats (ceci dit, je me trouve assez loin de mon "terrain de jeux" préféré)

 

Le premier message que je dois recevoir du GUI est le mot : "UCI" ... (il me demande si j'utilise le protocole UCI ... l'autre possibilité étant le protocole Winboard)

 

Question :

 

Je recherche toutes informations qui me permettraient de lire et d'écrire sur l'entrée et la sortie standard stdin et stdout depuis Labview.

(via DLL très certainement) Toutes infos qui me permettraient d'utiliser ' fgets et printf" depuis LV ... ou code équivalent.

Ou n'importe quelles autres infos-idées. Welcome à toutes les suggestions.

Je suis persuadé qu'il y a moyen (Dll, fonctions windows, etc ..) d'implémenter un tel échange depuis LV.

 

Si j'arrive à "capturer" ce 1er message texte "UCI" envoyé par Arena vers mon code LV (exe obligatoire à mon avis) .... c'est Bingo !

C'est la "pierre de rosette" .. le reste sera du légo Smiley heureux

 

merci.

0 Compliments
Message 1 sur 18
5 554 Visites

nuit courte, mais "payante" Smiley heureux

 

fgets vient de msvcrt.dll (c'est une dll dédiée en principe au C, mais qui se trouve (en version de "base") de façon native dans l'OS Windows.

fgets à besoin d'un pointeur vers une "structure fichier" définissant le fichier d'entrée "stdin, stdout et stderr".

La fonction "_p_iob" retourne ce pointeur (c'est sa fonction unique) La fonction "fflush" vide le tempon d'entrée.

 

Le code ci-dessous fonctionne, je capture les messages envoyé par l'interface Arena. 

 

un d'entre vous pourrait-il tester ??

 

un d'entre vous pourrait-il faire tourner ce code (ci-joint en LV2010) sous Windows 7 et/ou  Windows 8 (un test sur les 2 OS serait le top)

Juste faire tourner. Voir si le compteur "cpt" s'incrémente bien, et si le code tourne sans stop/erreur.

Bien entendu, vous n'aurez aucune capture et aucun message dans le string "from arena". (normal puisque arena n'est pas là)

Le but est de tester la portabilité sur windows 7 et 8 (j'ai XP). Normalement, il ne devrait pas y avoir de soucis.

 

Un grand merci.

 

toute remarque sur ce code est bienvenue.

 

SR2.png

 

Xboard : signale qu'il utilise le standard Xboard pour son interface graphique.

uci : il me demande si j'utilise le protocole uci (normalement je dois répondre : uciok)

isready : me demande si le moteur est près. (normalement je dois répondre : readyok)

(je ne réponds pas encore Smiley heureux )

 

0 Compliments
Message 2 sur 18
5 545 Visites

Ici le compteur s'incrémente, et la partie texte reste vide. (LabVIEW 2014 + Windows 7 x64)

______________
Florian Abry
Inside Sales Engineer, NI Germany
Message 3 sur 18
5 526 Visites

Merci Naity.

 

génial !

 

Le compteur s'incrémente :

 

donc la boucle tourne sans erreurs, la dll "msvcrt.dll" existe, et les fonctions s'exécutent sans soucis.

 

Les fonctions utilisées sont en principe des fonctions utilisées directement ou indirectement en C.

Cependant, Windows offre de façon native la plupart des dlls utilisées en C.

Il serait en effet absurde de ne pouvoir faire tourner un code C compilé ... que uniquement sur les machines où le C est installé.

 

La partie texte reste vide :

 

normal. Le code est "à l'écoute" ... et ne reçoit rien.

 

Pour "voir" quelque chose, il faut :

compiler mon code et en faire un "exe".

lancer l'interface graphique Arena (par exemple ... mais il y en a d'autres) ... et faire "engine / install new engine" en ciblant mon_code.exe.

Là, tu verras les messages envoyés par le GUI.

 

Labview 2014 - Windows 7 - x64 :

 

Windows 7 : super ... Windows 8 ne devrait pas poser de soucis (il n'y a pas de raisons)

x64 : ça, c'est l'OS ... mais ici le code est du 32bits et tourne en code machine 32bits.

 

 

Là, je suis déjà plus loin.

Je récois les messages du GUI ... et je lui réponds.

Arena offre une fenêtre "Engine Debug", et je peux voir mes réponses.

 

flèche à droite : question (ou informaton) vers le moteur.

flèche à gauche : réponse du moteur.

 

SR1.png

 

 

encore merci Naity d'avoir pris le temps de faire ce test.

 

 

0 Compliments
Message 4 sur 18
5 521 Visites

 

sans devoir "tout relire"  ...  Smiley heureux

 

 

Si quelqu'un peut  tester ce vi   (joint au 1er message) sour  Windows 8  .... ce serait sympa. (merci)

 

 

simplement regarder si le "compteur" tourne

(sans arrêt de la boucle)

0 Compliments
Message 5 sur 18
5 518 Visites

Toujours plus sympa ton projet !!

Jette un oeil à une des bibliothèques OpenG: oglib_pipe-1.0-1.ogp

 

A+

 


Message 6 sur 18
5 483 Visites

Oui, la biblio OpenG sur les Pipes ...

 

 

(Oui ... j'ai vu, j'ai téléchargé ... j'ai fait quelues "tests" au début ... sans grandes révélations)

 

Je n'aime pas (de façon générale) les codes OpenG.

 

pourquoi ?

Ce sont des boîtes noires ... et en générale ... des machines à gaz.

Je me retrouve à jouer au Mécano ... sans réellement programmer (je n'apprends rien)

Dans le cas précis de cette biblio "oglib_pipe" .. elle fait référence à une DLL "maison" (inconnue, boîte noire absolue)

Impossible pour moi d'utiliser du code qui n'est pas à 200% (1000%?) conforme à "ma" façon de coder (y compris graphiquement, au pixel près)

Donc ... je passe d'abord mon temps à tout comprendre, et à tout ré-écrire Smiley heureux

 

Je préfère 100x le home-made ... pour le moment, j'ai établis le dialogue dans les 2 sens.

Il n'est pas nécessaire de rediriger Stdin-Stdout vers un pipe.

J'utilise des fonctions bien connues de la DLL "msvcrt.dll" (native sous Windows xp,7,8) ... soit : "_p__iob", "setvbuf", "fgets" et "puts".

Fonctions largement documentées (MSDN, divers forums, C, assembleur ...)

Code minimum, je sais exactement "quoi fait quoi et comment" (et ça tourne tip-top)

Pour le moment, je suis satisfait ... au départ, je ne connaissais même pas l'existence de "Stdin-Stdout" (j'ai pas mal appris)

 

Ceci dit,

merci Mathieu pour ton commentaire ... bien sympa aussi.

Une belle journée pour toi Mathieu.

 

 

 

 

 

 

Message 7 sur 18
5 478 Visites

Fais gaffe, tu vas finir par retomber dans de l'assembleur 😉

Personnellement, je n'aurai pas hésité à utiliser les bibliothèques OpenG

 

Chacun voit midi à sa porte!


0 Compliments
Message 8 sur 18
5 469 Visites

Chacun voit midi à sa porte!

 

.... oui, c'est certain (en toutes choses) ... la vérité n'est pas unique.

 

demande à cent peintres de peindre la joie ....

 

 

Fais gaffe, tu vas finir par retomber dans de l'assembleur

j'ai fait une thérapie ... normalement ça devrait aller.   Smiley clignant de l'œil

0 Compliments
Message 9 sur 18
5 464 Visites

C'est mignon cette expression (que je ne connaissais pas)!

Par contre, en ce qui concerne l'ingénierie logicielle c'est assez faux la plupart du temps. Il existe bien un certain nombre de façons de procéder acceptables pour arriver à un résultat, mais dans tous les cas, on cherchera à réutiliser des bibliothèques tiers autant que faire se peut. On n'est pas là pour réinventer la roue mais répondre à un besoin!

Dans un bouquin (que je recommande chaudement), que j'ai lu il y a un an ou deux, intitulé "The Pragmatic Programmer", le premier chapitre débute par "Un code parfait, ça n'existe pas. Ca n'existera pas." Ce postulat est lourd de conséquences, et il est en fait assez lié à cette problématique de fait-maison versus réutilisation...

 

Enfin, pour ce qui est du post original, c'est une excellente idée de vouloir coupler LabVIEW avec d'autres environnements, mais à mon sens ça relève presque de la faisabilité 😉 Tant qu'on ne fait pas d'OpenGL (ou équivalent), LabVIEW reste très puissant pour les interfaces utilisateurs...

 

A+

--Eric

Eric M. - Senior Software Engineer
Certified LabVIEW Architect - Certified LabVIEW Embedded Systems Developer - Certified LabWindows™/CVI Developer
Neosoft Technologies inc.

Message 10 sur 18
5 458 Visites