Ok, dann klink ich mich hier aus. Du scheinst dich ja mit dem Toshiba auszukennen.Zitat von i_make_it
Meine Roboter würden die Steuerzeichen einer Telnet-Verbindung nicht auf dem TCP-Port mögen. Außerdem ist der C-Code in dem Link für Linux und eben waren wir noch bei Visual Studio. Da halt ich mich lieber raus.
@Mxt: Das ist ein Beispiel das verdeutlicht, das man mit etwas Suchmaschine leicht was finden kann.
(ich habe einfach den ersten Treffer von über 20 Seiten genommen, deshalb vorne dran bewust "Bsp.:")
die Anforderung war es einen ASCII String zu übertragen.
"1,100.50,55.3,0.0,0,0,0,CR"
Genau dafür wurde Telnet 1969 geschaffen.
Bei dem TS2100 Controller für den TH650 ist TCP/IP optional, von daher habe ich außer dem Eingangs geschriebenen keine Infos.
Allerdings passen diese halt zu 100% auf Telnet.
Von daher dürfte eine Telnet Implementation am schnellsten zu einem Ergebniss führen,
bzw. für einen ersten Test kann man auch einfach einen Telnet Client öffnen, eine Verbindung zum Controller aufbauen, einen entsprechend formatierten ASCII String von der Konsle aus senden und sehen wie der Controller reagiert. Das SCOL Programm auf dem Controller muß ja auch den String entgegennehmen und verarbeiten.
Damit das ein Koordinatenset an die Steuerung gesand wird, weis der Arm ja noch nicht was er damit machen soll.
Auf Verdacht würde ich mir mal den Befehl TRANS ansehen, da ist ja auch ein Beispiel dazu im Handbuch.
Telnet ist sowas wie eine Konsolenverbindung. Es benutzt TCP/IP. Das bedeutet im Umkehrschluss nicht, dass alle Clients oder Server die TCP/IP sprechen auch Telnet sprechen.
Man kann mit einem Telnet Client testen, ob da einer drangeht. Aber in einer echten Telnet Verbindung kann man z.B. mit der Delete-Taste seine Eingaben löschen. Ein dummer TCP-Client wird da aber nur das alte Zeichen, das Delete-Steuerzeichen und das neue Zeichen sehen und sagen "Ist nicht das Stringformat was ich brauche" und entweder eine Fehlermeldung von sich geben oder gar nix tun.
Auch meine ich mich zu erinnern, dass bei Telnet die Terminals Dinge miteinander aushandeln. In dem verlinkten C-Code gibt es außerdem diese Negotiation, da würden meine Roboter aber was husten. Aber ich werde da nicht weiter diskutieren.
Bei TCP gibt es im Gegensatz zu UDP immer eine Aushandlung.
Deshalb ist TCP auch verbindungsorientiert und nicht verbindungslos wie Broadcasts.
Ich habe mich nur an den Vorgaben orientiert.
Protocol = TCP/IP
Format = ASCII
Data format: Must use the following data string format.
Aufbau des Datenstrings: (num, x1, y1, c1, u11, u21, u31, … , CR)
Aus RFC97 zum Telnet Protocol:
the user can generate all 128 ASCII character codes as input to the network
Damit steht auch Carriage Return (CR) zur Verfügung.
Wie ich ja vorher schon schrieb, kann man bei der Implementierung den Teil der die Console realisiert weglassen und sich einfach nur den Kommunikationsteil nehmen.
So wie es z.B. auch bei den RS232 over TCP/IP gemacht wird (ist im RFC2217 definiert).
Die meisten sind sich gar nicht darüber im klaren wie viele Protokolle schlußendlich im Hintergrund einfach nur Telnet laufen haben.
Es wäre natürlich schöner wenn man wüsste was auf der Steuerung genau Implementiert ist.
Berechtigungen
Zitieren
Lesezeichen