TXT Controller WLAN Kommunikation

[TheMotivation]

Hallo zusammen,

ich möchte aus einem .NET Programm heraus per WLAN mit dem TXT Controller kommunizieren.
Eine Verbindung konnte ich bereits schon aufbauen durch einen TCPClient auf Port 65000 (ich hoffe das ist der richtige?).
tcpClient.Connect("192.168.8.2", 65000);

Das Programm auf dem Controller wartet einfach nur in einer Endlosschleife bis ein "=" empfangen wird.

Mein Problem besteht nun darin, dass ich zwar eine TCP-Verbindung aufbauen kann und auch Packete an den Controller senden kann, allerdings erkennt er mein "=" nicht als "=",
bzw. zumindest wird die Bedingung in der Endlosschleife nie erfüllt.
Daher meine Frage:
Wird bei der Kommunikation ein spezielles Encoding verwendet und ist es nötig weitere Informationen vorauszuschicken, wie z.B. Startbits?

Über Hilfe würde ich mich sehr freuen.


Vielen Dank bereits im Voraus,
The Motivation

[odie]

Ich gehe mal davon aus, dass bei Nachrichten zusätzlich noch eine Geräte-ID enthalten sein muss (siehe Einstellungsmöglichkeiten bei der Bluetooth-Kommunikation). Ist aber nur eine Vermutung, ich habe noch nie etwas in die Richtung ausprobiert. Hast du versucht, mit Wireshark die Pakete eines funktionierenden Programms mitzuschneiden?

Dass es am Encoding liegt, kann ich mir beim "="-Zeichen nicht vorstellen, da das Zeichen in ASCII enthalten ist (0x3D) und somit in allen anderen Encodings an der gleichen Stelle stehen sollte.

[TheMotivation]

Über Wireshark versuche ich aktuell Muster zu erkennen. Hilfreich wäre es allerdings, wenn ich eine Nachricht vom Controller aus senden könnte, damit ich mir das Paket herleiten könnte.
Gibt es irgendeine Möglichkeit den Sender zum Laufen zu bekommen? Bei mir kommt da ständig "Die Kommunikation ist im TXT Controller noch nicht enthalten".

Wäre cool wenn irgendwo die Elemente und deren Reihenfolge einer funktionierenden Kommunikation einzusehen wären.
Ich kann zwar mitschneiden, was der Controller von sich gibt, wenn ich ein Programm rüber schiebe etc., aber was genau passieren muss, dass er im Empfänger eine Zeichenkette erkennt, lässt sich daraus nur schwer ableiten.

[odie]

"Die Kommunikation ist im TXT Controller noch nicht enthalten"

=> Höchstwahrscheinlich geht die Kommunikation also noch nicht, da nicht freigeschaltet

Wenn ich es noch richtig im Kopf habe, läuft die Datenübertragung im Online-Modus von ROBOPro über eine "Transfer Zone". Damit setzt der PC ein Bitmuster für die Ausgänge und bekommt ein Bitmuster der Eingänge vom Controller zurück. Diese Pakete werden x-mal pro Sekunde hin und her geschickt - so könntest du also direkt aus .NET heraus auf die I/Os deines Controllers zugreifen. Da bei Ethernet die minimale Paketlänge 60 Bytes beträgt, wird der Rest dann vermutlich mit Nullen aufgefüllt (Padding). Zu sehen ist das in Wireshark mit dem Interface-Test in ROBOPro.

Bei Programmen, die in den Flash-Speicher geladen werden, wird der Code vorher kompiliert; was du dann in Wireshark siehst, ist Maschinencode.

[Defiant]

Wenn die USB-Kommunikation funktioniert könntest du auch die mitschneiden. Bluetooth/W-Lan wird hoffe ich doch nicht viel anders sein.

[Ad2]

The messaging between controllers was already present in the RoboInterface. If I remember correctly it did consist of 7 bytes, a lead byte, HW byte, Subcode byte, command word and parameter word. The '=' you would like to send was encoded in the command word. Normally the command word contained a base 40 encoded version of 3 characters. The robopro commands like '+', '=', etc. were however special and had their own code (numbers close to 0xFFFF). In the TX the entire message was further packaged into "BEEF" messages which were exchanged over Bluetooth between TX controllers. The BEEF messages (so called because they started with 0xBE and 0xEF) could be longer than 7 bytes but this was only available using the C-API. It could be that the TXT uses a similar format for its Bluetooth and WLAN communication but it could also be completely different.