Das Teach-in bleibt Standardverfahren:

Mikroprozessoren machen Programmierung erst effektiv

14.08.1987

Roboter für den kommerziellen Einsatz gibt es noch nicht sehr lange, aber seit sie existieren, müssen ihre Bewegungsabläufe programmiert werden. Der vorliegende Beitrag von Jürgen Lietz * gibt einen Überblick über die Entwicklung der Programmiertechniken von Industrierobotern bis hin zum heute aktuellen Stand der Technik und informiert über Trends der Zukunft.

Zur Zeit der Entwicklung der ersten Robotersteuerungen (vor zirka 25 Jahren) steckte die Mikroelektronik noch in den Kinderschuhen. Naturgemäß waren somit die Möglichkeiten für Rechenkapazitäten, Verarbeitungsgeschwindigkeiten und Speicherplatz eng begrenzt beziehungsweise noch gar nicht vorhanden. Trotzdem gelang es findigen Ingenieuren, auch ohne Mikroprozessortechnik mit den damals zur Verfügung stehenden Mitteln Steuerungen zu entwickeln, deren Möglichkeiten für viele Einsatzfälle auch heute noch genügen. Auch an der grundsätzlichen Programmiermethode hat sich bis heute nichts Wesentliches geändert.

Das Prinzip ist immer gleich. Dem Roboter wird durch den Programmierer das auszuführende Bewegungsprogramm vorgemacht (Teach-in), welches anschließend durch die Robotersteuerung beliebig oft wiederholt wird. Jedoch kristallisierten sich sehr bald zwei unterschiedliche Verfahren für den Lernprozeß heraus. 1. Das Programmieren mit dem Handprogrammiergerät (HPG)

Hierbei wird durch Tasten die einzelnen Roboterachsen in die gewünschte Konstellation gefahren und anschließend wird durch Betätigung der Programmiertaste die Position gespeichert. Diese Methode hat den Vorteil, daß der Programmierer ohne Zeitdruck die optimale Bewegung durch geschickt gesetzte Raumpunkte ermitteln kann. Auch lassen sich die Positionen beliebig exakt anfahren und Programme sind durch Änderung einzelner Raumpunkte leicht optimier- und änderbar. Nachteil der älteren Robotersteuerung war die fehlende Bahnsteuerung. Hierdurch versucht jede Achse beim Programmmablauf die nächste Position zu erreichen, ohne daß eine koordinierte Bewegung aller Achsen (zum Beispiel eine geradlinige Bewegung) möglich ist. Für viele einfache Handhabungsaufgaben ist dies ausreichend, wo jedoch vorbestimmte Bahnen zu fahren sind, muß man sich durch Programmierung vieler Stützpunkte in geringem Abstand behelfen. Diese Methode erfüllt zwar ihren Zweck, jedoch ist die Programmierung sehr zeitintensiv. 2. Das Führen des Roboterarmes durch den Programmierer

Voraussetzung für diese Programmiermethode ist ein leicht gängiger Roboterarm mit geringen Massen. Dies ist praktisch nur mit hydraulisch betriebenen Geräten erreichbar oder durch Hilfen wie einem separaten Programmierarm. Dieser stellt lediglich eine kinematische Nachbildung des Roboterarms mit den erforderlichen Positionsmeßsystemen, jedoch ohne Getriebe und Antriebe, dar.

Mit dem Hilfsarm sind zwei Programmiermethoden möglich. Man kann direkt mit dem Hilfsarm das Programm erstellen und tauscht diesen zur Programmwiedergabe gegen den Originalarm aus oder man benutzt den Hilfsarm als Fernsteuerung für den Originalarm.

Eine weitere Programmiervariante ist die servounterstützte Armführung. Hierbei wird die durch den Programmierer ausgeübte Bewegungsrichtung durch Meßsysteme erfaßt und durch das robotereigene Servosystem unterstützt. Aus sicherheitstechnischen Erwägungen ist diese Methode jedoch problematisch, denn der Roboterarm steht während der Programmierung unter Last.

Gleich ist bei all diesen Varianten die Art der Programmspeicherung. Während des Programmierens wird in gleichbleibenden Zeitabständen Raumpunkt für Raumpunkt gespeichert. Das typische Zeitraster hierfür (sample-rate) ist 10 bis 50 Positionen pro Sekunde. Bei der Programmwiedergabe werden nun im gleichen Zeitraster die gespeicherten Positionen als Soll-Werte an den Servo-Regelkreis gesendet, wodurch das Bewegungsmuster gleich der Programmierung ausgeführt wird (Abweichungen entstehen durch die Trägheit des Regelkreises).

Jedoch erfordert diese Methode große Speicherkapazitäten, die anfangs durch Magnetbänder, später durch Floppy-Disks und neuerdings durch Halbleiterspeicher zur Verfügung gestellt werden.

Kritisch war die Standzeit von Magnetbändern und Floppy-Disks, da diese auch während der Programmierwiedergabe permanent in Betrieb waren. Die Qualität des Ergebnisses ist wesentlich abhängig von der Geschicklichkeit des Programmierers, und eine Optimierung ist nur durch erneute Programmierung des kompletten Zyklus möglich.

Durchgesetzt haben sich beide Programmierungsmethoden, abhängig von der Anwendung. Das Programmieren mit dem HPG wird eingesetzt bei Handhabungs- und Montageaufgaben sowie schwierigen Applikationen mit Bahnverläufen (Schweißen, Kleben etc. ). Das Führen des Roboterarmes hat sich in der Oberflächen-Beschichtungstechnik (Lackieren, Pulvern) durchgesetzt. Natürlich gibt es Ausnahmen von der Regel. So werden einige Lackierroböter mittels HPG und Schweißroboter durch Handführung programmiert. Die Kommunikation mit peripheren Einrichtungen war bei den ersten Steuerungen in der Regel auf einige wenige digitale Signale begrenzt, die an bestimmten Stellen im Anwenderprogramm aktiviert oder abgefragt wurden. Hierdurch war viel Steuerungsaufwand in der Peripherie erforderlich.

Mikros brachten Intelligenz in die Programmierung

Mit den oben beschriebenen Programmiertechniken erschöpften sich lange Zeit die Möglichkeiten. Fortschritte und Verbesserungen wurden nur in einzelnen Details erzielt. Grundlegende Neuerungen ergaben sich erst Ende der siebziger, Anfang der Achtziger Jahre, als die Einführung der Mikroprozessortechnik auf breiter Front Einzug in die Robotersteuerung nahm. Hiervon profitierte in erster Linie die Programmiermethode mittels HPG. Durch die neuen leistungsfähigen Prozessoren konnten neue Funktionen in die Steuerungen integriert werden:

- Bahnsteuerung mit Interpolationsmöglichkeiten für Gerade, Kreisbögen, Langlöcher etc; hierdurch reduziert sich der Programmieraufwand drastisch. Für viele Anwendungen, wie zum Beispiel Schweiß-, Klebe- oder Entgrat-Applikationen, sind nur noch wenige Raumpunkte zu programmieren. Zwischenpunkte für die zu fahrende Bahn werden durch die Steuerung während der Roboterbewegung selbständig berechnet.

- Berechnung von Raumpunkten im Anwenderprogramm; Komplette Palettierprogramme sind durch Programmierung eines einzigen Raumpunktes und Berechnung mittels einfacher mathematischer Funktionen realisierbar.

- Verschiedene Koordinatensysteme, wie Kartesisches Koordinatensystem, Zylinder-Koordinaten oder Tool-Koordinaten (Werkzeug-Koordinaten). bilden eine Hilfe beim Anfahren der zu programmierenden Raumpunkte.

Beim Verfahren des Roboterarmes wird die Werkzeugorientierung durch Interpolation aller Bewegungsachsen beibehalten oder bei Orientierungsänderung des Werkzeugs bleibt die Werkzeugspitze (Tool) konstant in Position. - Einführung von TCPs (Tool-Center-Point). Hierbei werden alle Bewegungsfunktionen auf eine vom Anwender gewünschte Stelle des Werkzeugs (zum Beispiel Drahtspitze des Schweißbrenners) bezogen. Bei allen programmierten Bahnen wird jetzt die Brennspitze exakt geführt, und zwar abhängig von der erforderlichen Geschwindigkeit der einzelnen Roboterachsen.

- Ankopplungsmöglichkeit von Sensoren über digitale, analoge oder serielle Schnittstellen. Hiermit kann während des laufenden Prozesses Einfluß auf die Bewegungsbahn, die Bahngeschwindigkeit oder den Prozeß selbst genommen werden. - Steuerung der kompletten Peripherie über digitale oder serielle Schnittstellen. Zur Programmierung stehen Funktionen wie AND, OR, NAND, NOR oder mathematische Funktionen wie Addition, Subtraktion, Multiplikation, Division, sin, cos, tan, Wurzelzeichen zur Verfügung. Einige Steuerungen erlauben die Peripheriekommunikation unabhängig vom Bewegungsprogramm.

- Dialog der Steuerung mit dem Anlagenbediener durch kundenspezifisch entwickelte Menüs. Der Bediener wird durch Meldungen und Hinweise im Klartext über die Situation informiert und kann durch Quittierungen oder Dateneingabe direkt Einfluß auf die Produktion nehmen, ohne notwendigerweise Programmierspezialist zu sein.

- Durch hochentwickelte Programmiersprachen sind auch schwierige Funktionen komfortabel und übersichtlich zu gestalten.

Diese Entwicklung ist nicht zuletzt auf die Forderungen des Marktes nach universeller Einsetzbarkeit von Industrierobotern zurückzuführen. Anwender wollen keine Vielzahl von Geräten, sondern Standardprodukte, mit denen möglichst viel Anwendungen gelöst werden können.

Durch diese Entwicklung sind jedoch die Bediener von Roboteranlagen mit der Programmierung oder Entwicklung der Anwenderprogramme häufig überfordert, das heißt, der Anwender muß diese Arbeiten seitens des Roboterlieferanten ausführen lassen oder selbst Personal ausbilden. Optimale Programmiertechniken lassen sich allerdings nicht durch einmalige Schulungen, sondern nur durch Übung erlernen. Welches Unternehmen ist jedoch in der Lage, permanent Übungs- und Testmöglichkeiten anzubieten ? Die vorhandenen Roboteranlagen sind teuer und sollen möglichst rund um die Uhr produzieren. Bei Umrüstung der Anlage sollen Stillstandzeiten so gering wie möglich gehalten werden. Voruntersuchungen für neue Anwendungen sollen vor der Investition möglichst sichere Fakten sowohl über die optimale Arbeitsplatzgestaltung als auch die voraussichtliche Produktivität ermitteln. Zur Reduzierung der Inbetriebnahmezeiten sollen die Anwenderprogramme bereits vorher entwickelt und getestet sein.

Der Schlüssel zur Lösung all dieser Forderungen heißt "Offline-Programmierung". Einige Anbieter von Industrierobotern sind heute schon in der Lage, hierzu fertige Systeme anzubieten. Ein beispielhaftes Konzept, bei dem der Kunde seinen Erfordernissen entsprechend aus verschiedenen Paketen auswählen kann, ist folgendes:

Dieses Softwarepaket bietet dem Anwender die Möglichkeit der Entwicklung der Roboterprogramme, unabhängig von der Fabrikhalle auf einem Personal Computer. Der Generator verfügt über sämtliche Befehle der Robotersprache. Eingabefehler werden erkannt (Syntax-Check) und nach Fertigstellung kann das neue Roboterprogramm auf Minidisketten gespeichert und direkt in die Robotersteuerung geladen werden.

Der Emulator verfügt über die gleichen Möglichkeiten der Offline-Programmierung, jedoch kann das erstellte Programm komplett ausgetestet werden. Komplette Programme können simuliert und auf Fehler überprüft werden.

In Verbindung mit dem IBM-CAD-System "Catia" lassen sich komplette Roboterzellen entwickeln und testen. Der Catval-Postprozessor übersetzt die im Catia- System eingegebenen Roboterbefehle und Bewegungen in die Robotersprache, die dann mit PCval direkt in den Speicher des Roboters geladen werden.

Umfangreiche Untersuchungen und Entwicklungen sind am Bildschirm möglich. Bewegungsabläufe, Layouts und Funktionen lassen sich ohne Peripherie analysieren und optimieren. Bei einem derart ausgetesteten System reduzieren sich Optimierungsarbeiten auf die Feinkorrektur einiger weniger Raumpunkte bei der Inbetriebnahme.

Die zuletzt dargestellten Programmiermöglichkeiten repräsentieren den augenblicklichen und auch zukünftigen Stand der Technik. Die Systeme werden sicherlich noch in Details weiterentwickelt, Neuheiten sind jedoch für die nächsten Jahre nicht zu erwarten.

Gleiches gilt für die Robotersteuerungen. Die heutigen Systeme bieten alle Möglichkeiten, so daß sich die Entwicklung auf die Pflege und Detailverbesserung beschränken wird. Für lange Zeit wird die gebräuchlichste Programmiermethode das Teach- in bleiben.

Ing. (grad. ) Jürgen Lietz ist Leiter der Roboterapplikation bei der Unimation/Westinghouse GmbH in Heusenstamm.