Liebe Leserinnen, liebe Leser,

ich bin glücklich bekannt zu geben, dass ich einen Präsenzkurs für KUKA Industrieroboterarme absolviert habe, der in einem staatlich anerkannten Zertifikat resultiert hat. Der Kurs wurde von professionellen Roboterprogrammierern an einem Firmenstandort gemacht, was bedeutet, dass wir (die Studenten) nicht nur einen umfangreichen theoretischen Hintergrund bekommen haben, sondern auch hatten wir ausreichend genung Gelegenheit, unsere Kentnisse mit einem echten Roboterarm auszuprobieren. Jeder Tag bestand aus zwei Teilen: ein theoretischer Teil, und ein Praxisteil. Der theoretische Teil bestand sowohl aus der Übergabe von neuen Kenntnissen, als auch aus Testfragen, wohingegen während der Praxisteil alle früher gelernte Sachen geübt wurden. Eine derartige Kurstrukturierung gefällt mir sehr viel, besonders wenn man bedenkt, dass jeder Stundent genung Zeit hatte, alle Lernübungen mit einem echten Roboterarm durchzuführen.

Kuka RobotA KUKA robotic arm placing a test object onto a conveyor driven cart

Das Bild oben stellt eine der oben erwähnten Lernübungen dar. Wir mussten ein Steuerungsprogramm für den Roboterarm und das Förderbandsystem schreiben, um Werkstücke aus/in einer/e Lagerkiste auf/aus eine/r Karre in Abhängigkeit von dem Füllstand platzieren zu können. Es war wirklich erstaunlich zu sehen, wie schnell und gleichzeitig wie präzis der Roboterarm arbeitet! Zum Beispiel könnte der Arm die Karre nur in ein paar Sekunden entleeren oder füllen (wenn auch die Kiste jenseits des Roboterarms war), falls die maximale Geschwindigeit angewandt würde (im Lehr/Testumgebungen die Nutzung der maximalen Geschwindigeit ist nicht erlaubt). Das war sogar bei einer zu 30% reduzierten Geschwindigeit sehr schnell.

Weiterhin gab es viele interesstante (und vielleicht erstaunliche) Sachen, die ich über Roboterarmprogrammierung gelernt habe. Eine solche Sache war, dass der kürzeste (gerade) Pfad zwischen zwei Punkte nicht erforderlich der schnellste Pfad in der Roboterwelt ist. In vielen Fällen kann das Roboterwerkzeug einen gebeugten Pfad viel schneller als einen präzisen geraden Pfad durchlaufen, das ein Resultat der Zusammenarbeit der Achsen ist.

Aber endet der Strom der interessanten Sachen hier nicht. Zum Beispiel, der Robotercontroller kann gleichzeitig zwei Programme ausführen. Das erste ist für den Arm, und das zweite ist für andere Zwecke, wie die Steuerung von externen Geräten. Wir hatten die Gelegenheit, dieses Merkmal ein bisschen zu entdecken, und für mich kam die interessanteste Erfahrung (aus dem Gesichtspunkt Programmierung) genau aus dieses Merkmal: Ich habe es herausgefunden, wie schwierig es ist, ein nebenläufiges Programm nur mit Grundfunktionen einer Sprache zu schreiben.

In der obenerwähnten Förderbandübung hat das Robotersteuerprogramm und das Förderbandsteuerprogramm in zwei abgesonderten Ausführungssträngen ausgeführt. Um es ein bisschen komplizierter zu machen, haben die zwei Ausführungsstränge unterschiedliche Zykluszeiten. Das bedeutet, dass wir eine sichere Weise für die Datenübergabe zwischen diesen zwei Ausführungssträngen finden mussten, um die beabsichtigte Zusammenarbeit des Arms und Förderbandsystems zu erreichen. Das ist ganz schwierig, wenn Grundsynchronisationsmerkmale, wie Mutexe, zur Verfügung nicht stehen. Als eine Randbemebrkung möchte ich es sagen, dass diese Erfahrung meine schon große Anerkennung der Arbeit von A. Williams an C++ Nebenläufigkeit weiter erhöht hat. Falls Sie schnell herausfinden wollen, was C++ im Bereich Nebenläufigkeit bieten hat, lesen Sie bitte meine zwei Zusammenfassungen darüber hier und hier.

Natürlich wird das Fehlen von Synchronisationsmerkmalen Programmierung schwieriger als nötig machen, aber, als ich es gelernt habe, die Welt scheint derartige Schwierigkeiten durch die Nutzung von anderen Werkzeuge zu beseitigen, um solche Steuergsysteme bauen zu können. Das auf dem Robotercontroller ausgeführte Steuerungsprogramm wird am meistens möglichst einfach gehalten. Das bedeutet, dass der Roboterarm nur die Funktion eines weiteren hochentwickelten Aktors übernimmt, der, genauso wie eine frequenzumrichterangetriebene Maschine, von einer SPS gesteuert wird. Das ist so wahr, dass auch Fehlerbehandlung scheint von der SPS komplett erledigt zu sein, da im Falle eines Fehlers das Roboterprogramm nur ein Fehlersignal sendet (und vermutlich wird das den Arm auch stoppen), und wird danach die SPS sich entscheiden, was weiter zu tun ist.

Es gab auch einige komische Sachen, wie z.B wie unterschiedlich die Entwicklungswerkzeuge in der Industrie sein können. Beispielweise ist die Entwicklungsumgebung des KUKA-Programmierhandgeräts überhaupt einfach: das unterstüzt weder Syntaxfehlerhervorhebung noch Codeeinrückung. Wenn man solche gängliche Merkmale haben will, muss man ein Desktop-Entwicklungsumgebung von KUKA (die kostenlos zur Verfügung steht) benutzen. Es war auch ganz erstaunlich für mich, dass dieses Werkzeug die Werte von Variablen zur Laufzeit nicht zeigen kann. Stattdessen muss man durch Menüs gehen, um ein weiteres Fenster zu eröffnen, mit dem man das Wert eines Variables herauslesen kann. Ich bin darüber nicht sicher, warum solche einfache Merkmale von dem Programmierhandgerät nicht unterstüzt sind, aber ich vermute, dass dieses Gerät nur für Endprüfungen und kleine Änderungen vorgesehen ist. Oder vielleicht nicht, ich weiß es nicht.

Es gab auch viele andere interessante Sachen, die ich gelernt habe, wie die physicalische Limitationen der Arme, verschieden Armwerkzeuge, industrielle Trends, usw, aber dieser Beitrag ist schon zu lang, also ich werde das jetzt zum Abschluss bringen. Alles in allem, ich war mit diesem Kurs sehr zufrieden, und meiner Meinung nach war die Zeit damit sehr gut verbracht.

Wie immer, vielen Dank fürs Lesen.