Ansteuerung über LabVIEW

[vogster]

Hallo zusammen!

Ich beabsichtige, einen Mitsubishi Roboter über LabVIEW anzusteuern.
Ich habe leider keine Erfahrung in diesem Bereich und bin gerade in der Einarbeitung.
Hat jemand Erfahrungen zu diesem Thema und kann mir einen kurzen Ablauf der
Programmiernung und Ansteuerung schildern? Eine grobe Beschreibung reicht aus!

Welche der möglichen Schnittstellen (RS232, CC-Link, Ethernet) eignet sich?
Am liebsten würde ich Ethernet verwenden.

Vielen Dank für Eure Hilfe
Vogster

[Urmel]

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

[vogster]

Hallo Urmel,
vielen Dank für die schnelle Antwort.

Folgende Variante würde mir am besten gefallen:

1. Der Roboter wird über das Handmodul geteached, der Bewegungsablauf besteht aus ca. 5-6 Schritten.

2. Die schrittweise Steuerung des geteachten Bewegungsablaufes soll dann über Labview Schritt für Schritt abgearbeitet werden. Nach jedem Schritt soll ein Sensor die korrekte Durchführung bestätigen, dann folgt der nächste Schritt.

Ist das im Prinzip so möglich, oder gibt es Einschränkungen?

Vielen Dank für die Mühe!
Vogster

[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:

Code:

10 OPEN "COM1:" AS #1
20 MOV P1
30 INPUT #1,MX
40 MOV P2
50 INPUT #1,MX
60 MOV P3
70 END

Mit 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 !

Code:

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

Code:

10 OPEN "COM1:" AS #1
20 INPUT #1,PNEXT
30 MOV PNEXT
40 GOTO 20

kannst 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

[vogster]

Hallo Urmel,

vielen Dank für Deine ausführlichen Bemühungen!
Ich werde das in den kommenden Tagen (oder Wochen) austesten.
Dann melde ich mich bei Dir!

Wie gesagt, vielen Dank!
Vogster

[vogster]

Hallo Urmel, hallo Forum!

Die oben beschriebene Möglichkeit hat über die RS232 Schnittstelle gut funktioniert.
Wenn ich in über Labview die Daten "1\r" gesendet habe, hat der Robbi den nächsten Punkt angefahren. Der Syntax "\r" musste dahinter, das habe ich zufällig bemerkt. Hat jemand eine Erklärung dafür! Kann ich den Inhalt der Variablen MX (siehe oben) auslesen?

Über TCP/IP läuft das ganze irgendwie nicht. Hat jemand da schon Erfahrungen.
Muss beim generieren der Nachricht etwas beachtet werden? Hat jemand evtl. ein kleines Tool (Freeware) zum Empfangen und Senden von Nachrichten via TCP/IP parat?

Vielen Dank für Eure Mühe und ein schönes Wochenende!
Vogster

[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/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemnetsocketstcpclientclasstopic.asp

Zum Ausprobieren kannst du z.B. je nach Geschmack die kostenlose Express Version von Visual Basic oder C# herunterladen.
[/Edit]

Grüße
  Urmel

[vogster]

Hallo zusammen!

Die ganze Geschichte mit Labview funktioniert nun echt gut! Parameteraustauch etc. klappt wie gewünscht!

Nun habe ich aber ein kleines Problem mit den Monitorfunktionen von Cosirop. Hier möchte ich versuchsweise im Aufnahmemodus die Daten wie z.B. Positionen oder Geschwindigkeiten in eine Datei schreiben lassen. Hier sind (laut der Hilfe) bei einer Ethernetverbindung Taktzeiten von 10ms möglich! Davon bin ich aber leider weit entfernt. 270ms (+/- 10ms) sind die Regel, auch bei einer 10ms Einstellung. Auch werden die Daten nicht in gleichbleibenden Zeitabständen aufgenommen. Auch bei 1000ms schwanken die Aufzeichnungsabstände. Woran könnte das liegen? Meine Aufzeichnung habe ich bei einem stehenden Roboter gemacht, ohne dass ein Programm gestartet war. Die Verbindung wurde über Ethernet hergestellt.

Vielen Dank für Eure Mühe!
mfg
Vogster

[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

[vogster]

Hallo Urmel, hallo Forum!

Wie zwei Beiträge zuvor beschrieben funktioniert das System "echt gut". Das ist auch prinzipiell noch der Fall. 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.

Meine Idee ist nun,  Nachrichten vom Robbi zyklisch zu versenden. Solange er einen Schritt ausführt soll er z.B. "Arbeite" senden (alls 500ms), wenn er dann wieder auf Arbeit wartet soll er "Warte" senden (auch alle 500ms). Zwischendurch mal Bestätigungen wie "Ende", "Start" (jeweils 3 Mal, 500ms Zyklus). Das ganze soll auch der dauerhaften Überwachung dienen. Bleiben dann beispielsweise für mehr als 2 Sekunden die Nachrichten aus, dann stimmt was nicht -> Notaus oder so! Wenn der Robbi auch mal 2 Sekunden keine Daten empfängt sollte gleiches passieren!

Meine Idee: Eine globale Variabale bekommt vom Hauptprogramm den aktuellen Roboterzustand (Warten, Start, Arbeiten, Ende, ...) zugewiesen. Ein parallel zum Hauptprogramm laufendes Programm übernimmt die Kommunikation entsprechend der globalen Variable, also Senden, Empfangen, Auswerten, ...

Meine Fragen daher:
Ist diese Idee ersten überhaupt machbar und zweitens sinnvoll? Hat jemand selbiges Problem so oder anders gelöst und Erfahrungen?

Vielen Dank für die Hilfe!
Vogster

[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

[vogster]

Hallo Urmel,

ich bin zunächst auch von einem Hardware oder Softwareproblem vom PC ausgegangen. Da ich dort leider auch nicht weitergekommen bin, habe ich im LabVIEW - Forum einen Eintrag geschrieben.

siehe hier: http://www.labviewforum.de/Kommunikation-von-externen-Geraeten-ueber-TCP-IP-t8230.html

Aufgrund des Verlaufs des Beitrags bin ich nun davon ausgegangen, dass meine Art der Datenübertragung (einmaliges Senden) zu unsicher ist.

Nichts desto trotz möchte ich die Kommunikation (besonders aus Gründen der Überwachung) auf zyklische Sendungen umstellen. Vielleicht sind die anderen Probleme damit dann auch behoben. Ist die von mir beschriebene Methode umsetzbar und sinnvoll?

Vielen Dank für die Mühe!
Vogster

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

[vogster]

Hallo Urmel,

ich benutze den Data-Link Modus.

Zum Hauptprogramm auf dem Roboter:
Hier sind ca. 10 mögliche Arbeitsschritte hinterlegt. Jeder Schritt enthält verschiedene
Anweisungen. Die Beschleunigungen und Geschwindigkeiten, mit denen ein Schritt ausgeführt werden soll, werden zusammen mit der Nummer des Schritts von LabVIEW an den Roboter gesendet. Ganz oben im Hauptprogramm steht eine if-Auswahl, diese wertet die empfangenen Daten (Schritt-Nr.) aus und springt dann in die entsprechende Zeile. Ist der Schritt abgearbeitet erfolgt ein Rücksprung zum Anfang mit der Auswahl. Dort wird solange gewartet, bis Daten empfangen werden. Die Sendung der Daten (Schritt, Geschw., Beschl.) erfolgt nur 1 Mal. Dann sendet der Robbi 1 Mal eine Startnachricht und wenn er fertig ist eine Stoppnachricht.

Wir sind uns sehr sicher, dass LabVIEW die Daten sendet, dass diese aber beim Robbi
nicht ankommen und zwischendurch "verloren" gehen. Somit steht die Anlage still!

Die Daten sollen nun zyklisch gesendet werden, um evtl. verlorene Nachrichten zu kompensieren. (Und für die Sicherheit!)


Daher folgender Plan:

Nachdem der Roboter gestartet wurde sendet er zyklisch "idle". Solange der PC dieses auch zyklisch empfängt, kann er eine Beauftragung an den Roboter senden. Bleibt dieser Empfang am PC für mind. 3 Nachrichten aus, dann besteht ein generelles Verbindungsproblem.

Die Beauftragung (Schritt, Geschw., Beschl.) wird auch zyklisch gesendet bis der Robbi sie dem PC bestätigt. Zur Sicherheit sendet der Robbi die Nachricht auch 3 Mal.

Während der Abarbeitung des Schritts sendet der Robbi auch wieder zyklisch "Arbeite" als Bestätigung. Bleibt diese beim PC für mehr als 3 Nachrichten aus, besteht wieder ein Verbindungsproblem. Gleichzeitig soll der PC dem Roboter auch senden, dass er weiter arbeiten soll. Bleibt diese Nachricht auch für mehr als 3 Nachrichten aus, muss der Roboter sofort in den Notaus gehen, da die Verbindung zum PC fehlt.

Ist der Schritt dann abgearbeitet sendet der Robbi 3 Mal "ENDE", dann soll er wieder in den "Idle" - Modus wechseln. Dann können wieder neue Aufgaben empfangen werden.

Um diesen ganzen Datenverkehr zu realisieren möchte ich mit einem Unterprogramm arbeiten welches die Kommunikation übernimmt. Oder wären 2 Unterprogramme sinnvoll, eines zum Senden und eines für den Empfang? Das Unterprogramm (oder die Unterprogramme) sollen die empfangenen Daten in globalen Variaben speichern oder
die zu sendenden Daten aus globalen Variablen entnehmen. Das Hauptprogramm wertet dann die Variaben aus oder verändert den Inhalt für Sendungen.

Das ist meine Idee! Würde das so funktionieren?

Vielen Dank für Deine Mühe!
Vogster

[Urmel]

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