Roboter Toshiba TH650 über Ethernet TCP/IP Datenstrings schicken

Hallo,

hat jemand von euch schon mal einen Industrieroboter über Ethernet angebunden? Für mich ist das ganze Neuland.

Grundlegend kann man den Roboterarm über Ethernet anbinden. Dem Roboter Controller kann ich eine IP Adresse ,Port und einen Standard Gateway zuweisen.

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)

num:Number of elements in string. Must be integer between 1-10
x,y,c: Koordinaten für den Roboter
u: Anbindung für eine Bildverarbeitung (erst uninteressant)

Beispiel eines Strings: Data String:

1,100.50,55.3,0.0,0,0,0,CR

Jemand eine Möglichkeit mir dabei zu helfen? Zur Programmierung habe ich mir VS runtergeladen. Ob VB oder C++ ist mir relativ egal da ich mich in beiden Sprachen erst einfinden muss da ich Jahrelang Java programmiert habe.

Zitat:

---

Zitat von MJunker

Hallo,
hat jemand von euch schon mal einen Industrieroboter über Ethernet angebunden?

---

Hallo,

ja, regelmäßig. Toshiba ist allerdings hierzulande ein Exot. Das ist ein 4-Achs Arm (SCARA) oder ?

Zitat:

---

Zitat von MJunker

Ob VB oder C++ ist mir relativ egal da ich mich in beiden Sprachen erst einfinden muss da ich Jahrelang Java programmiert habe.

---

Warum dann nicht C#, das ist Java sehr ähnlich und mittlerweile deutlich verbreiteter als VB. VB ist natürlich auch .net, der Funktionsumfang ist also gleich. Die TcpClient-Klasse hat eigentlich alles, was du brauchst.
https://msdn.microsoft.com/de-de/lib...vs.110%29.aspx

In C++ ist das komplizierter, ohne zusätzliche Library müsste man da auf der nackten Socket-API herumturnen.

Verstehe ich das richtig?

Du willst jetzt PC seitig was programmieren, daß das Datenpacket mit dem String erzeugt?
Also eine Art Telnet Cleint?

Oder geht es um die Controlerseitige Verarbeitung des String mit SCOL?

ich möchte eigendlich säter mit OpenCV eine Bildverarbeitung einbinden. Wenn ich erstaml über TCP/IP Datenstrings an den Toshiba TH650A schicken kann, muss ich halt später nur meine Koordinaten aus der Bildverarbeitung in den String einfügen. Da mir das alles zusammen aber zu viel ist, wollte ich beides erstmal trennen und nur Datenstrings in der form wie oben an den Roboter schicken. Mit Scol will ich dann eigendlich nichts mehr machen. Oder gibt es da was besseres um mein vorhaben zu realisieren?

Zitat:

---

ja, regelmäßig. Toshiba ist allerdings hierzulande ein Exot. Das ist ein 4-Achs Arm (SCARA) oder ?

---

Ja ist ein 4 Achs Scara. Was machst du mit den Robotern? Auch Bildverarbeitung?

Zitat:

---

Zitat von MJunker

Was machst du mit den Robotern?

---

Ich entwickle beruflich Software im Bereich Automatisierungstechnik. Hier im Forum bin ich aber eher mit privaten Basteleien unterwegs und weil ich Arduino und ähnliches bei Schulungen als "neutrale Hardware" verwende.

Mir ging es nur darum festzustellen auf welcher Seite Du was machen willst.
Für die PC Seite gibt es einige Codebeispiele für Telnet.
Bsp.: https://l3net.wordpress.com/2012/12/...telnet-client/

Die kann man erst mal so nehmen und wenn damit die Kommunikation funktioniert, ersetzt man den Teil der das Konsolenfenster realisiert durch einen Teil der Daten aus einer Datei liest und zyklisch den Teil der die TCP/IP Kommunikation durchführt aufruft.

Zitat:

---

Zitat von i_make_it

Die kann man erst mal so nehmen und wenn damit die Kommunikation funktioniert,

---

Ok, dann klink ich mich hier aus. Du scheinst dich ja mit dem Toshiba auszukennen.

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. :o

@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.

Das ist ja interessant. Ich arbeite auch (1 Woche) in der Automatisierungstechnik und soll mich nun mit dem Scara beschäftigen. Was hättest du noch für eine Idee den Roboter steuern zu können? Dieses Scol finde ich recht uninteressant, da man dort ja auch keine x,y,z Koordinaten aus einer Bildverarbeitung beziehen kann oder?! Bei 1500 Seiten Englischer Betriebsanleitung dauert das mit dem verstehen manchmal auch länger :-) .
Hast du mit Bildverarbeitung bzw. OpenCV schon mal was gemacht? Hast du irgendwelche Tipps, Beispiel Programme oder ähnliches nützliches für mich? Bei der neuen Firma kann ich nämlich niemanden fragen, weil sich dort keiner damit auskennt :)

- - - Aktualisiert - - -

mit dem Telnet werde ich mal ausprobieren... danke dafür...

Also Toshiba sind in Deutschland wirkliche Exoten ich kenne die nur von der Messe.

Beruflich habe ich unter anderem mit Mitsubishi zu tun. Die haben zumindest auch dieses Format von Strings, die mit CR abgeschlossen sind. (Und meine Zweifel an der Funktion von Telnet dafür). Mit Bildverarbeitung habe ich nur indirekt zu tun, ich stelle nur den Kollegen die Infrastruktur in unserer Software zur Verfügung.

Wie man Roboter über Ethernet steuern kann, ist von Hersteller zu Hersteller sehr unterschiedlich. Bei manchen (z.B. Stäubli) stellt das Betriebsystem nur die Funktion bereit beliebige Binärdaten über TCP zu senden/empfangen, was man damit macht ist ganz dem Anwender und seinem Programm überlassen. Bei Mitsubishi gibt es mehrere Möglichkeiten. Die Programmiersprache ist ein Basic, damit kann man Strings über Print/Input über TCP austauschen. Dann gibt es ein Steuerprotokoll um den Roboter komplett von außen fernzusteuern (da müsste man wissen, ob Toshiba da ein Äquivalent hat). Außerdem kann man den Roboter in C++ in Echtzeit über UDP von außen steuern, das hat der Toshiba ziemlich sicher nicht.

Zum Problem:

Erst mal wirst du mit der Doku kämpfen müssen, um zu sehen was da geht. Im schlimmsten Fall kannst du nur irgendwie welche Variablen ändern und musst in einem Roboterprogramm darauf reagieren. Die Zeit mich da selber einzuarbeiten habe ich nicht, da kann ich nur Tipps geben.

Dann wäre noch die Wahl der Programmiersprache. C# ist im Moment die Mainstream Windows Programmiersprache, die meiste aktuelle Doku ist dazu. VB ist heute das gleiche, nur andere Syntax, für alte Männer, die das schon immer so gemacht haben. C++ ist so eine Sache, für alle High Performance Anwendungen inkl. Bildverarbeitung, CAD, Spiele sicher das Mittel der Wahl. Aber niemand, der das ernsthaft macht, arbeitet da noch in nacktem C im Petzold Style (Buch). Normalerweise verwendet man da Bibliotheken oder C# für die Oberfläche.

Ein gleichzeitiger Einstieg in Visual C++, irgendeine GUI-LIB, Netzwerkprogrammierung und den Roboter ist schon hart. Das würde ich versuchen aufzuteilen.

Wenn man sich den Waschzettel von Toshiba zum TH650A ansieht,
http://www.condoras.com/TH650A.pdf
steht da das der Controller der TS2100 ist.
Und bei dem steht:
Programming language - SCOL (proprietary, similar to BASIC)
External inputs/outputs (general) - 31+7 inputs / 22+10 outputs (7/10 can be switchable with system)
External operation signals(exclusive) - Inputs: Cycle operation start, stop, reset, etc. Outputs: Servo-On status, emergency stop, ready for operation, malfunction alarm, etc.
Serial communication port - RS-232C: 2ports
Other functions - Torque control, Interruptive functions, self-diagnosis, I/O control and communications during motion, Coordinate calculations, etc
PC software (optional) - TSPC...Program editor, Teaching, remote operation, etc.
Options - I/O extension, field-network connection, Conveyor synchronization, etc.

Zum Thema Field Network findet man hier:
http://www.toshiba-machine.co.jp/doc...th_all_eng.pdf

Field Networks (optional)
Various field network protocols are available, for high-speed communication and resulting in reductions in wiring.
For the Ethernet (not supported by TS1000), CC-Link, DeviceNet and Profibus, please request for detailed manuals.

Man muß sich also das entsprechende Handbuch zum Field Network einzeln bestellen falls man es noch nicht hat.
Somit sind die Informationen nicht allgemein verfügbar.

Zum Thema Vision Controll findet man aber im selben pdf noch.
Anhang 31226
Daraus kann man schon den Programmtechnischen Ablauf erahnen.
Das SCOL programm läuft bis an den Punkt wo es auf das Triggersignal an einem der IOs wartet und übernimmt dann über LAN einen Koordinatensatz, der als variable Position im Program die nächste Fahranweisung bedient.

Bei dem Modell wird kein Weg an SCOL vorbeiführen. Ist halt wie bei vielen Robotern eine Propritäre Sprache des Herstellers.
Das ist eine Erfahrung die ich in über 20 Jahren bei den meisten Kleinrobotern machen musste.
Und es ist der Grund warum man damals versuchte IRData als Hersteller unabhängigen Standart einzuführen.

Übrigens an englische Dokumetationen und Literatur sollte man sich in der Automatisierungstechnik gewöhnen.
Ist noch besser wie über 1500 Seiten in chinesisch, wie ich es vor 9 Jahren bei einem Projekt einmal hatte.

Zitat:

---

Zitat von i_make_it

Zum Thema Field Network findet man hier:
http://www.toshiba-machine.co.jp/doc...th_all_eng.pdf

---

Die gelbe Farbe des "Vision Sensors" dort auf Seite 18 könnte auf eine Cognex Kamera hindeuten. Die gibt es als Spezialversionen für mehrere Roboterhersteller. So eine Kamera wird über eine PC-Software (bei anderen Herstellern über eine Webseite) parametriert und kann dann direkt mit der Robotersteuerung reden.

Das ist für viele Scara Anwendungen heutzutage die einfachste Bildverarbeitung. Um die Kommunikation braucht man sich dann gar nicht weiter kümmern. (Bis auf IP-Adresse usw.)

also von print und input hab ich das was gelesen, das muss ich mir aber noch genauer anschauen. "Print IP1,"REQ",CR" , Input IP1,N , Kann ich zur Zeit noch garnix mit anfangen. So wie ich das verstanden habe, kann ich damit rogramme in Scol schreiben aber woher kommen dann die koordinaten von der bildverarbeitung. die müssen doch irgendwo übergeben werden.

Vermutung:

Ein

Code:

---

Input IP1,N

---

liest über die TCP-Verbindung 1 (die noch irgendwo konfiguriert und geöffnet wird) in die Variable N.

Der Computer schickt z.B.

Zitat:

---

42<CR>

---

und N hat danach den Wert 42. (<CR> für das Steuerzeichen 13)

Scheint so als sei INPUT nur für die COM Schnittstellen und das Teach panel.

The INPUT command reads in data from a specified communications channel.
INPUT[{COM0 | COM1 | TP},] <variable> [, <variable>]…
INPUT K1, K2, K3
INPUT COM1, K
The INPUT command is used to read in data from a communication channel. This data may be either real or integer numbers.
Specify one (1) communication channel from COM0, COM1, and TP. COM0 and TP are channels used solely for the teach pendant. COM1 corresponds to controller COM1 communication channel.
If you do not specify a communication channel in your INPUT statement, data will be read in from the teach pendant communication channel.
When an INPUT command is executed, the program will wait until the data is read in from the communication channel.
Data which has been read in will be placed in the assigned variable(s). If there is more data than there are variables,
excess data will be ignored. If there is less data than there are variables, the program will wait until the remaining data comes in.
When inputting data from the teach pendant, keep real numbers separate with commas. When you are done entering the numbers, push the EXE key.