Hallo zusammen!
Für ein Studienprojekt sollen wir zu dritt einen Mühle-spielenden Roboter bauen. Die Hardware steht soweit und auch die Ansteuerung in Labview und die Spielerkennung durch eine Webcam funktionieren gut.
Jetzt sind wir dabei die Spiellogik zu bearbeiten. Aufgrund von Zeitmangel ist geplant, einen fertigen Programmcode mit Labview zu steuern, um einen Gegenzug auf den Spielzug des Menschen zu errechnen. (Minimax Algorithmus)
Das Programm, das wir
hier gefunden haben, ist ein Komandozeilenprogramm. Laut Recherche lassen sich solche Programme auch mit Labview öffnen. Im Anhang mein erster Versuch.
Ich schaffe es allerdings nicht, das exe-Komandozeilenprogramm mit Befehlen zu füttern, geschweige denn am Laufen zu halten um nur die gemachten züge und nicht die gesamte Spielsituation übergeben zu müssen.
Für die Ausgabe müsste der C++ Code natürlich noch angepasst werden.
Was meint ihr? Ist das machbar? Oder sollten wir damit keine Zeit verschwenden und den Code (irdendwie) in Labview implementieren. (Unsere Aufgabenstellung sieht keine 100%tig gute Spiellogig vor, die Setzphase des Mühlespiels würde reichen)
Ich danke euch fürs Lesen und freue mich auf Antworten!
Gruß
Thomas
Hi,
meines Wissens kannst du zwar das Programm starten etc. aber ohne eine Routine die über TCP/IP oder irgendeine andere ausgehende "Kommunikation" verfügt nur nach Beendigung die Ausgabe prüfen. (Wie du also sagtest - jedesmal komplette Spielsituation berechnen und dann eine Zug ausgebene lassen, verarbeiten aktualisieren, neuen Zug berechnen lassen etc.)
Das was du geschrieben hast macht ja nix weiter als das programm aufrufen, warten bis die Kommandozeile beendet wird und dann die ausgabe auswerfen. Du müsstest aber live in der Kommandozeile weiterarbeiten, was meines wissens nicht geht.
Soweit ich auf der Seite gesehen habe liegt das programm ja als Visual Studio Project vor - theoretisch könnte ihr das Programm also auch so anpassen dass es eine Kommunikationsschnittstelle anbietet auf die Labview zugreifen kann. Das einfachste wäre vermutlich TCP IP über den lokalen host. Dann lasst ihr das Programm jeweils warten bis die neue Zuginfo kommt und dann anschließend nen Zug zurückgeben etc. So könnt ihr während das läuft mit arbeiten (Starten natürlich so wie von dir gezeigt parralel zu eurem restlichen code (sprich ohne Datenabhängigkeit).
Ansonsten bleibt dir wie gesagt nichts übrig als den jeweils nur einen Zug aus der konkreten Spielsituation errechnen zu lassen und auszugeben (das tut er ja schon soweit ich dich verstanden habe). Da Labview ja sowieso jederzeit die Spielsituation kennt / kennen muss ist das ja an sich auch kein Problem, es wirkt nur nicht so elegant - aber man kommt wohl ohne das Kommandozeilenprogramm anzupassen nicht drumherum.
Vielen Dank für deine Antwort!
Ich recherchiere noch ein bisschen, frage meine Teamkollegen und melde mich, sollte es Probleme geben.
(15.05.2013 15:15 )Spezifisch schrieb: [ -> ]Vielen Dank für deine Antwort!
Ich recherchiere noch ein bisschen, frage meine Teamkollegen und melde mich, sollte es Probleme geben.
Es gibt da schon eine Möglichkeit. Die heisst OpenG Pipe Library. Das ist eine VI library mit dazupassender DLL, die sogenannte Pipes zur Verfügung stellt und auch ein System Exec Replacment VI das die sogenannten Standard IO Kanäle des Commandline Programmes als Pipes zur Verfügung stellt.
Hier is ein Post auf den NI Servern der auch ein OpenG Package enthält mit der Library.
Danke rolfk!
Uns hat das ein ganzes Stück weitergebracht und wir glauben, dass wir damit unser Problem lösen können.
Wir haben allerdings noch nicht geschafft, das Komandozeilenprogramm zuverlässig mit Daten zu füttern und die Ausgabe wieder auszulesen.
Wir haben dein Beispielprogramm (
System Command (cmd.exe) Test.vi)aus dem NI Forum versucht anzupassen.
Im Anhang ist außerdem das angepasste Komandozeilenprogramm aus obiger Quelle.
Wir wollen abwechseln eine Komandozeile (als string) eingeben und das Ergebnis wieder (als string) einlesen.
Bsp:
1. Programmstart
2. Auf Ausgabe warten
3. aus CMD einlesen z.B. D2
4. Eingabe unsererseits
5. z.B. D1
6. Auf Ausgabe warten
7. Ausgabe aus CMD wieder einlesen
...
Das angepasste VI lasse ich weg, da das nur verwirren würde.
Wenn du uns ein einfaches Beispielprogramm zukommen lässt wären wir dir sehr verbunden.
Gruß
Thomas und Kollegen
(23.05.2013 15:57 )Spezifisch schrieb: [ -> ]Das angepasste VI lasse ich weg, da das nur verwirren würde.
Wenn du uns ein einfaches Beispielprogramm zukommen lässt wären wir dir sehr verbunden.U
Und warum würde ein angepasstes VI verwirren?
Zudem hast Du schon ein Beispielprogramm mit der Library. Funktioniert das so?
Wenn nein, dann weiss ich auch nicht warum nicht, wenn ja dann hilft Dir ein weiteres Beispielprogramm auch nicht.
Oder erwartest Du dass ich Dein VI für Dich schreibe?