Hallo,
im Prinzip ist die Steuerung über RS232 und Ethernet identisch. Die Datenübertragung erfolgt in der Regel zeilenweise in Textform.
Es gibt drei verschiedene Arten der Kommunikation.
1. Datenaustausch zwischen einem PC-Programm und einem Roboterprogramm. Das ist im Programmierhandbuch und im Handbuch für die Ethernet-Schnittstelle beschrieben.
2. Übertragen von Positionen, Programmen usw. vom PC auf den Roboter, Starten von Programmen, kurz alles was Programme wie Cosirop machen. Das ist in den allgemeinen Handbüchern nicht dokumentiert. Dafür muss man Mitsubishi kontaktieren und um entsprechende Unterlagen bitten.
3. Echtzeitsteuerung des Roboters vom PC aus. Der Roboter wird in einem festen Zeittakt von 7.1 Millisekunden direkt von einem PC-Programm bewegt. Das geht selbstverständich nur über Ethernet (Binärdaten über UDP) und nur auf Robotern mit 4 oder 6 Achsen (plus maximal 2 Zusatzachsen). Infos dazu gibt es im Handbuch der Ethernetkarte. Offiziell unterstützt wird nur (Visual-) C++.
CC-Link ist so eine Art japanischer Profibus und spielt nur bei SPSsen eine Rolle. Kannst du für PC-Anwendungen vergessen.
Grüße
Urmel
Hallo vogster,
ja das ist so möglich. Es gibt sogar verschiedene Varianten wie man das machen kann.
Ich fange mal mit was einfachen an ... 
Also du teachst deine Positionen mit der Teachbox. Dann benutzt du ein Programm wie Cosirop oder die PC-Support Software um ein Roboterprogramm zu schreiben.
Angenommen du hast die Positionen P1, P2 und P3 geteacht und willst sie nacheinander anfahren, jeweils mit einer Bestätigung vom PC dazwischen. Das könnte dann z.B. so aussehen:
10 OPEN "COM1:" AS #1
20 MOV P1
30 INPUT #1,MX
40 MOV P2
50 INPUT #1,MX
60 MOV P3
70 ENDMit INPUT wird der Inhalt der Variable MX, in diesem Fall über die serielle Schnittstelle, eingelesen. Mit der
Variable wird zwar nichts gemacht, aber da der Befehl auf Daten vom PC wartet, ergibt sich die Pause von selbst.
Man kann das natürlich erweitern, indem man z.B. mit einen IF THEN den Inhalt von MX auswertet und bei Bedarf ans Programmende springt.
Will man etwas flexibler in seinen Abläufen sein, kann man z.B. mit Cosirop die Positionen vom Roboter auf den PC übertragen. Dort werden sie in einer Textdatei gespeichert, die ungefähr so aussieht:
Achtung Fantasiewerte, nur zur Demonstration !
P1=(100.00,200.00,300.00,90.0,45.0,60.0)
P2=(....
P3=(...Da stehen dann die Koordinaten der Positionen drin, als Name=(X,Y,Z,A,B,C).
Wenn du jetzt ein Roboterprogramm schreibst das ungefähr so aussieht
10 OPEN "COM1:" AS #1
20 INPUT #1,PNEXT
30 MOV PNEXT
40 GOTO 20kannst du an beliebige Positionen fahren, die du aus der Textdatei ausliest. Du schickst jeweils nur den Teil nach dem Gleichheitszeichen, also z.B. (100.0,200.0,300.0,90.0,45.0,60.0)<CR> . Wobei <CR> für ein "Carriage Return"-Zeichen steht.
[Edit]
Je nach Einstellung der Schnittstelle kommt da noch ein "PRN" davor, damit die Daten nicht als Kommandozeilenbefehl mißverstanden werden.
[\Edit]
So kannst du die Positionen in beliebiger Reihenfolge abfahren. Wobei du natürlich aufpassen musst, das der Weg dahin frei ist. 
Eleganter geht diese Methode mit der von mir beschriebenen Kommunikationsart 2, wo man quasi auf die Kommandozeile des Roboterbetriebssystems zugreift und Befehle direkt ausführen kann, ohne Roboterprogramm.
Ich hoffe das hilft dir weiter.
Grüße
Urmel
Hallo,
Syntax "\r" musste dahinter, das habe ich zufällig bemerkt. Hat jemand eine Erklärung dafür!
\r ist die in C++ übliche Schreibweise für das Steuerzeichen "Carriage Return". Ist wohl auch in LabView so.
Über TCP/IP läuft das ganze irgendwie nicht.
Was genau läuft nicht ? Hast du das Visual Basic Beispiel im Handbuch angesehen ?
Hast du die Roboterparameter entsprechend eingestellt ?
Hat jemand evtl. ein kleines Tool (Freeware) zum Empfangen und Senden von Nachrichten via TCP/IP parat?
Das geht in jeder aktuellen Programmiersprache mit ein paar Zeilen. Von LabView habe ich keine Ahnung.
[Edit]
Für die aktuellen Microsoft-Sprachen gibt es hier ein Beispiel für eine einfache TCP-Verbindung.
Muss man dann nur noch für den Roboter anpassen.
http://msdn.microsoft.com/libr…tstcpclientclasstopic.asp
Zum Ausprobieren kannst du z.B. je nach Geschmack die kostenlose Express Version von Visual Basic oder C# herunterladen.
[/Edit]
Grüße
Urmel
Hallo,
Die ganze Geschichte mit Labview funktioniert nun echt gut! Parameteraustauch etc. klappt wie gewünscht!
Na, das ist doch schön. 
Zu Cosirop kann ich leider nicht viel sagen. Das letzte das ich gesehen habe war 1.6. Seitdem setzen wir nur noch unsere eigene Software ein.
Erstmal zur Info: Die Methode die Cosirop vermutlich zur Positionsabfrage verwendet, ist das was ich weiter
oben als Kommunikationsart 2 bezeichnet habe. Das man da 10 Millisekunden erreichen kann, halte ich für ein Gerücht.
Edit: Auf den neueren Steuerungen mit Melfa Basic 5 sieht es etwas besser aus, die Rechenleistung soll 4 bis 5 mal höher sein.
Die Zeiten, die Du gemessen hast klingen schon realistisch. Vermutlich kann man, wenn man es selber programmiert, unter 100 ms kommen, eventuell unter 50, aber mit gelegentlichen Aussetzern muss man dabei leben.
Wenn Du z.B. Sensorwerte und Roboterposition zeitlich exakt synchronisieren willst, kommst Du um die Echteitsteuerung nicht herum. Die 7 Millisekunden sind dabei sehr statil, die Abweichungen liegen bei unserer Software etwa bei +/- 300 Mikrosekunden. Schrittfehler (d.h. ein Zyklus wird übersprungen) kommen nur alle paar Millionen Zyklen mal vor, z.B. wenn nebenbei intensiv auf die Festplatte zugegriffen wird.
Allerdings ist die Programmierung nicht trivial und setzt fortgeschrittene C++-Kenntnisse voraus. (Oder man nimmt eine fertige Software.) Der Roboter kümmert sich halt nur noch darum, was im nächsten Interpolationszyklus passiert, alles andere wie Beschleunigen, Bremsen und Bahnplanung muss man selbst auf dem PC machen.
Grüße
Urmel
Hallo vogster,
Leider ist aber in dieser Version nicht berücksichtigt, dass ab und an mal Nachrichten auf dem Weg vom Robbi zum Rechner (und umgekehrt) verloren gehen können. Dieses passiert leider auch in der Relaität sporadisch.
Das darf bei TCP/IP eigentlich nicht passieren. TCP stellt sicher, dass alle Daten in der richtigen Reihenfolge bei der Gegenseite ankommen.
Du hast entweder einen Bug in deinem PC- oder Roboterprogramm, oder ein Problem mit dem Netzwerk.
Unsere Systeme laufen in Produktionsanlagen im 24 Stunden-Betrieb. Da geht normalerweise nichts verloren.
Wir haben nur schon mal Netzwerkfehler bei neueren Robotern beobachtet, wenn man diese mit einem gekreuzten Kabel direkt mit dem PC verbunden hat. Wenn man einen Ethernet-Switch dazwischen hängt, sind die Probleme weg. Mitsubishi konnte bisher nicht erklären woran das liegt.
Deine Beschreibung klingt aber eher nach einem Bug.
Grüße
Urmel
Mir ist noch nicht so ganz klar, wie dein Programm aufgebaut ist.
Benutzt du nur "Data Link"-Kommunikation, also PRINT und INPUT auf der Roboterseite, oder verwendest du auch das R3-Protokoll (oben als Kommunikationsart 2 bezeichnet) ?
Ich verwende in der Regel mindestens zwei TCP-Verbindungen zum Roboter. Eine zum Programm starten und überwachen mit dem R3-Protokoll und eine zweite mit ausgeschaltetem Protokoll für die PRINT/INPUT-Datenübertragung.
Für jede Verbindung gilt in der Regel: Eine Seite sendet eine Anfrage und erhält darauf eine Antwort. Die Gegenseite fängt nicht unangefragt an selber zu senden. Die anfordernde Seite sendet erst wieder, wenn sie eine Antwort auf ihre vorherige Antwort erhalten hat.
Insbesondere stehen in Melfa Basic bei mir nie mehrere PRINTs oder INPUTs beisammen, sondern es gibt immer ein Wechselspiel aus Senden und Empfangen, also auf ein PRINT folgt im Programmablauf ein INPUT oder umgekehrt.
So geht auch nix verloren.
Hallo Vogster,
das klingt schon ganz ok, so wie du das machst.
Ich nehme an, der Roboter bleibt in der Zeile mit dem INPUT stehen und wartet ?
(Man kann mit der "CHNG DISP"-Taste auf dem Controller die Zeilennummer anzeigen
lassen.)
Man könnte in der Tat ein paralleles Programm verwenden, das ständig mit dem PC
kommuniziert und die Datenübertragung ins Hauptprogramm über globale Variablen machen.
Wirf mal einen Blick auf XLOAD, XRUN, usw.
Grüße
Urmel
Da fällt mir noch gerade was ein:
Was für eine Betriebssystemversion hat den dein Roboter ?
Eventuell hilft ein Update ...
Hallo vogster,
danke für Deine Rückmeldung. 
Das sieht doch gut aus. Es ist zwar von der Struktur her anders als meine Programme,
aber ich denke ich verstehe, wie es funktioniert.
Gut finde ich die Aufteilung in mehrere Programme, dass hält das ganze übersichtlich.
In Melfa Basic kann man ja schnell mal den Überblick verlieren. 
Das ist der Grund warum ich meine Programme immer möglichst klein halte und viel mit dem Steuerungsprotokoll oder der Echtzeitsteuerung arbeite. 
Zu Deiner Frage wegen dem SERVO OFF. Das gibt wahrscheinlich einen Fehler, weil der Task der die Servos ausschalten will, nicht der ist, der die Bewegungen ausführt. Eventuell ist der ERROR Befehl eher das geeignete, damit kann man benutzerdefinierte Fehlermeldungen erzeugen. Abhängig von der Fehlernummer werden auch die Servos ausgeschaltet.
Schönes Wochenende
Urmel
Hole den thread nochmal raus weil ich zu folgendem Zitat ne Frage hab:
"Ich verwende in der Regel mindestens zwei TCP-Verbindungen zum Roboter. Eine zum Programm starten und überwachen mit dem R3-Protokoll und eine zweite mit ausgeschaltetem Protokoll für die PRINT/INPUT-Datenübertragung."
Wie müssen die zwei Verbindungen genau konfiguriert sein? Wir verwenden nämlich bisher fürs Starten des Programms und für Data Link die selbe Leitung (IP), nur haben wir oftmals Probleme damit, deshalb frag ich. Die IP des Roboters ist z.b. 192.168.0.1. und die des PC's 192.168.0.2. Wenn ich jetzt ne extra Leitung nur fürs Starten des MB-Programms einrichten will, müsste die doch auch im 0er Netz sein oder?
Du musst ein Benutzerkonto haben um einen Kommentar hinterlassen zu können
