Synchronisierte Roboterbewegungen: Wie OLP die Programmierung mehrerer Roboter beherrschbar macht
Mehrroboterzellen können große Bauteile so schweißen, handhaben und umpositionieren, wie es ein einzelner Roboter nicht kann. Mit der Roboter-Offline-Programmierung programmieren Ingenieure das gesamte System an einem Ort und erkennen Probleme bereits vor der Inbetriebnahme.
Ein Schweißroboter hat die Hälfte der Naht geschafft, da beginnt der Positionierer sich zu drehen. Die Naht bewegt sich, der Brenner folgt ihr, und beide Achsgruppen müssen im Gleichschritt bleiben. Jetzt kommt noch ein zweiter Schweißroboter auf der anderen Seite des Bauteils dazu. Eine Programmänderung, die für den einen Roboter harmlos aussieht, kann den anderen auf Kollisionskurs bringen.
Solche Aufbauten können die Zugänglichkeit verbessern und den Prozess am Laufen halten. Gleichzeitig machen sie die Programmierung deutlich schwieriger. Jede bewegte Achse verändert die Geometrie an anderer Stelle. Schon eine kleine Bahnänderung kann sich auf Abstände, Timing und die Bewegung eines anderen Roboters auswirken.
Bei manchen synchronisierten Steuerungen liegen die Programme aller Roboter im System auf einem einzigen Teach Pendant. Das bündelt die Bedienung an einer Stelle, ändert aber nichts an der manuellen Arbeit. Der Programmierer muss weiterhin den richtigen Roboter oder die richtige mechanische Einheit aktivieren und prüfen, welche Maschinen sich bewegen dürfen. Wer die falsche Einheit wählt oder eine andere Maschine aktiv lässt, riskiert eine schwere Kollision.
Mit der Roboter-Offline-Programmierung (OLP) für Mehrrobotersysteme verlagert sich diese Arbeit in eine gemeinsame 3D-Umgebung. Ingenieure können die komplette Zelle programmieren, das Zusammenspiel der Bewegungen testen und steuerungsspezifischen Robotercode erzeugen, noch bevor jemand die Anlage in Betrieb nimmt. Ganz ohne Arbeit vor Ort geht es nicht, aber die Inbetriebnahme beginnt mit einem kalibrierten Modell und getesteten Programmen.
Was synchronisierte Roboterbewegungen wirklich bedeuten
Viele Teams verwenden koordinierte und synchronisierte Bewegung synonym. Dazu kommen die eigenen Begriffe der Roboterhersteller. Eine einzige Definition lässt sich deshalb nicht eins zu eins auf jede Steuerung übertragen.
Koordinierter Betrieb heißt hier: Zwei oder mehr Komponenten arbeiten nach einem festgelegten Plan zusammen. Sie tauschen etwa Signale aus, warten an definierten Punkten oder fahren zeitlich abgestimmte Bahnen, um Konflikte zu vermeiden.
Bei synchronisierter Bewegung ist die Kopplung enger. Mehrere mechanische Einheiten bewegen sich als ein einziges Bewegungssystem, das die Steuerung verwaltet. Die Synchronisation kann zeit- oder wegbasiert sein oder einem anderen Prinzip folgen, das von Roboterkonfiguration und Kommunikationsaufbau unterstützt wird. Ein Roboter kann so einem Zielpunkt folgen, der relativ zu einem Werkstück definiert ist, das ein anderer Roboter oder eine externe Achse bewegt.
Nimm zum Beispiel das Lichtbogenschweißen mit einem Drehpositionierer. Dreht sich der Positionierer, hält dann an und lässt den Roboter eine ruhende Naht schweißen, ist der Ablauf koordiniert. Dreht sich der Positionierer weiter, während der Brenner der Naht folgt, bewegen sich die Achsen synchronisiert. Der Zielpunkt des Roboters ist dann nicht mehr fest im Weltkoordinatensystem verankert.
Typische Konfigurationen sind:
- Ein Roboter mit Dreh- oder Dreh-Kipp-Positionierer
- Zwei oder mehr Roboter, die am selben Werkstück arbeiten
- Ein Roboter, der ein Bauteil hält, während ein anderer es schweißt, schneidet, schleift, beschichtet oder prüft
- Ein Roboter auf einer Bodenfahrachse oder einem Portal
- Mehrere Roboterarme, die sich einen engen Arbeitsraum teilen
Welche Bewegungsbeziehungen das reale System ausführen kann, hängt von der Steuerung und ihren Softwareoptionen ab. OLP kann eine herstellerübergreifende Linie modellieren und die Programmlogik zwischen Zellen koordinieren. Inkompatible Steuerungen bringt OLP aber nicht dazu, eng gekoppelte Bewegungen in Echtzeit auszuführen. Dafür braucht es in der Regel unterstützte Roboter und mechanische Einheiten innerhalb desselben Steuerungsökosystems.
Warum die Programmierung per Teach Pendant in Mehrroboterzellen schwierig wird
Teach Pendants eignen sich gut, um einen Punkt zu prüfen oder eine kleine Korrektur vorzunehmen. Die Gesamtansicht des Systems, die eine 3D-Simulation bietet, liefern sie dem Programmierer aber nicht.
Selbst wenn ein einziges Teach Pendant mehrere Roboter verwaltet, muss der Programmierer genau verfolgen, welcher Roboter, welche mechanischen Einheiten und welche Programm-Task gerade aktiv sind und welche Maschinen sich bewegen dürfen. Dass eine Bewegung für Roboter A sicher ist, heißt noch lange nicht, dass Roboter B frei bleibt, wenn beide gleichzeitig laufen. Wer das auf dem Shopfloor testet, bewegt echte Anlagen und muss dabei mehrere Systeme im Auge behalten.
Eine weitere Herausforderung sind die Koordinatensysteme. Eine Bahn kann relativ zum Werkstück definiert sein, doch das Werkstück bewegt sich womöglich auf einem Positionierer oder im Greifer eines anderen Roboters. Tool Center Points, Werkobjekt- und Basiskoordinatensysteme sowie die Positionen der externen Achsen müssen alle zusammenpassen.
Änderungen wirken sich auf die ganze Zelle aus. Verschiebst du eine Schweißnaht, um die Zugänglichkeit zu verbessern, entsteht auf der anderen Seite womöglich eine Kollision. Ein neuer Winkel des Positionierers löst vielleicht ein Reichweitenproblem, bringt dafür aber einen anderen Roboter nahe an seine Achsgrenze.
Das in der realen Zelle zu klären, ist teuer. Die Programmierung vor Ort blockiert Anlagen und kann die Produktion stoppen. Jedes ungelöste Problem kostet außerdem Zeit, die bei der Inbetriebnahme fehlt.
So funktioniert OLP für Mehrrobotersysteme
OLP bildet alle relevanten beweglichen Komponenten in einem Modell ab. Ein praxistauglicher Workflow umfasst sechs Schritte.
1. Die komplette Zelle aufbauen
Importiere die Geometrie von Werkstück und Vorrichtung. Füge Roboter, Werkzeuge, Positionierer, Fahrachsen, Tische und Sicherheitseinrichtungen hinzu. Lege ihre kinematischen Beziehungen fest.
Geometrie allein reicht nicht. Die virtuelle Zelle muss der realen entsprechen. Bei der Kalibrierung der Roboterzelle vermessen Ingenieure die realen Roboter, Werkzeuge, Vorrichtungen und externen Achsen. Mit diesen Messwerten gleichen sie anschließend das Modell ab.
2. Koordinatensysteme und Bewegungsbeziehungen festlegen
Lege die Werkzeug- und Werkstückkoordinatensysteme fest. Bestimme dann, welche Komponente das Werkstück trägt und welcher Roboter ihm folgt. Bei einem synchronisierten Schweißaufbau bewegt sich das Werkstückkoordinatensystem mit dem Positionierer oder dem Handhabungsroboter mit. Der Schweißroboter hält die erforderliche Bahn und den Brennerwinkel relativ zum Bauteil ein.
Wie genau diese Beziehung aussieht, hängt von der Steuerung ab. Sie kann auf Zeit, Weg, einem Leader-Follower-Prinzip oder einer anderen steuerungsspezifischen Methode beruhen. Der virtuelle Aufbau muss die Methode abbilden, die die reale Steuerung unterstützt.
3. Alle Komponenten in derselben Umgebung programmieren
Erstelle die Prozessbahnen aus der Produktgeometrie. Ergänze dann Anfahr-, Abfahr- und Transferbewegungen. Tools für die automatisierte Programmierung und Bahnberechnung beschleunigen diese Arbeit und können innerhalb eines einzelnen Roboterprogramms einige Kollisionen, Probleme mit Achsgrenzen und Erreichbarkeitsfehler beheben.
Beim Planen von Zugängen und Übergaben hat der Ingenieur alle Programme im Blick. Die Abfolge selbst muss aber weiterhin ein Ingenieur festlegen, der den Prozess versteht.
4. Synchronisation und Signallogik ergänzen
Definiere Startbedingungen, Wartebedingungen, Handshakes, den Zugang zu gemeinsam genutzten Bereichen und steuerungsspezifische Synchronisationspunkte. Setze kontinuierliche Synchronisation nur dort ein, wo der Prozess sie erfordert. Bei vielen Abläufen reicht es, wenn sich die Roboter über Signale und Wartebedingungen zuverlässig abwechseln.
5. Das System simulieren und korrigieren
Lass jede Bahn zuerst einzeln laufen und dann den kompletten Ablauf. Prüfe Kollisionen, Beinahe-Kollisionen, Reichweite, Achsgrenzen, Singularitäten, Prozessorientierung und die Reihenfolge der Arbeitsschritte. Teste auch absehbare Änderungen, etwa eine neue Position der Vorrichtung oder eine geänderte Schweißreihenfolge.
6. Steuerungsspezifische Programme erzeugen
Nutze für jeden Roboter und jede Steuerung den passenden Postprozessor. Visual Components übersetzt die programmierten Abläufe in die jeweils benötigte Steuerungssprache. Wie der erzeugte Code genau aussieht, hängt von Roboterhersteller, Steuerungsgeneration, installierten Technologiepaketen und Zellkonfiguration ab.
Auch der erzeugte Code muss kontrolliert aufgespielt werden. Sichere die Steuerung, prüfe Konfiguration und Koordinatensysteme, teste mit reduzierter Geschwindigkeit und führe die Abnahmeprüfungen an der realen Anlage durch.
Was sich vor der Inbetriebnahme per Simulation prüfen lässt
Ein Mehrrobotermodell sollte praktische Fragen beantworten, bevor die reale Zelle läuft.
| Prüfpunkt | Was der Ingenieur erfährt |
| Erreichbarkeit | Ob jede Prozess- und Transferposition über den gesamten Bewegungsbereich der externen Achsen erreichbar ist |
| Kollisionsfreiheit | Ob Roboter, Werkzeuge, Bauteile, Vorrichtungen, Positionierer und andere bewegliche Anlagenteile während des gesamten Ablaufs kollisionsfrei bleiben |
| Achsgrenzen und Singularitäten | Ob eine gültige kartesische Bahn einen Roboterarm in eine instabile oder unmögliche Achsstellung zwingt |
| Prozessorientierung | Ob Brenner, Pistole, Schneidkopf oder Werkzeug den erforderlichen Winkel halten, während sich das Werkstück bewegt |
| Synchronisationslogik | Ob Roboter in der vorgesehenen Reihenfolge warten, Signale austauschen und gemeinsam genutzte Bereiche befahren |
| Taktzeit | Ob der geplante Ablauf den angestrebten Durchsatz schafft und wo Roboter Wartezeiten haben |
Taktzeitergebnisse brauchen Kontext. Für die Standardschätzung nutzt Visual Components eine generische Bewegungssteuerung. Damit lassen sich Layouts und Abläufe gut vergleichen, aber nicht jede herstellerspezifische Steuerung auf die Millisekunde genau nachbilden. Kommt es auf exaktes Timing an, können Ingenieure Visual Components für eine genauere Prüfung mit unterstützten herstellerspezifischen virtuellen Steuerungen verbinden.
Die Simulation prüft nur, was im Modell steckt. Eine schlechte Kalibrierung kann ein ansonsten sauberes Ergebnis zunichtemachen. Das Gleiche gilt für eine falsche Traglast, ein fehlendes Schlauchpaket oder eine Vorrichtung, die nicht der auf dem Shopfloor entspricht.
Herstellerspezifische Unterstützung für synchronisierte Bewegungen
Der Workflow bleibt bei allen Herstellern gleich. Steuerungskonzepte und erzeugter Code dagegen nicht.
ABB MultiMove
ABB MultiMove koordiniert mehrere Roboter-Tasks und mechanische Einheiten über eine ABB-Steuerung. Visual Components unterstützt MultiMove-Konfigurationen, darunter koordinierte und unabhängige Bewegung, Ereignissynchronisation und Task-Koordination. Der ABB-Postprozessor erzeugt RAPID-Code für das konfigurierte System.
MSK Finland hat diesen Workflow für eine ABB-MultiMove-Schweißzelle mit drei Robotern genutzt. Das Team hat die Zelle offline programmiert, bevor das reale System aufgebaut war. Ein Roboter führt die Vorrichtung als Werkstückpositionierer für zwei Schweißroboter. Außerdem hat MSK ein zweites MultiMove-System mit zwei Robotern, zwei Werkstückpositionierern und einer Bodenfahrachse programmiert.
KUKA, FANUC und Yaskawa
Steuerungen von KUKA, FANUC und Yaskawa koordinieren Roboter und externe Achsen jeweils mit eigenen Methoden. Terminologie, Softwareoptionen, Programmstruktur und Einschränkungen der Steuerung unterscheiden sich. Ein FANUC-Aufbau mit koordinierter Bewegung ist zum Beispiel nicht einfach ABB MultiMove mit anderer Syntax. Das gilt genauso für KUKA- und Yaskawa-Systeme.
Visual Components unterstützt die Modellierung mehrerer Roboter, Signallogik, externe Achsen und steuerungsspezifische Postprozessoren. Dass ein Hersteller unterstützt wird, heißt aber nicht, dass jede Synchronisationsoption auf jeder Steuerungsgeneration gleich funktioniert.
Bevor du dich auf ein Zellendesign festlegst, stimme Robotermodelle, Steuerungsversionen, installierte Softwareoptionen, die Konfiguration der mechanischen Einheiten, den Kommunikationsaufbau und die benötigten Postprozessoren mit dem OLP-Team von Visual Components ab. Diese Prüfung ist vor allem dann wichtig, wenn die Anwendung eng synchronisierte Bewegungen erfordert. Visual Components kann signalkoordinierte, herstellerübergreifende Zellen in einer Umgebung modellieren. Bei kontinuierlich synchronisierter Bewegung ist das anders: Hier setzt die Architektur der realen Steuerung die Grenze.
Wo synchronisierte Bewegungen den größten Nutzen bringen
Schweißen mit Roboter und Positionierer
Bewegt sich der Positionierer kontinuierlich, lässt sich auch eine lange Schweißnaht in einer günstigen Lage und in Reichweite des Roboters halten. Das funktioniert aber nur, wenn Naht, Werkstückkoordinatensystem, Brennerwinkel, Roboterarm und Positioniererbewegung während des gesamten Schweißvorgangs aufeinander abgestimmt bleiben.
Schweißen mit zwei Robotern
Zwei Roboterarme können an verschiedenen Seiten eines großen Bauteils arbeiten, doch ihre sicheren Arbeitsbereiche überschneiden sich unter Umständen. Mit der Simulation planen Ingenieure gleichzeitige Arbeitsschritte, reservieren gemeinsam genutzte Bereiche und prüfen, ob der Brenner oder die Kabelführung des einen Roboters den anderen behindert.
Koordinierte Handhabung und Bearbeitung
Ein Roboter kann ein Bauteil zuführen oder neu ausrichten, während ein anderer es schleift, beschichtet, schneidet oder prüft. Das kann den Bedarf an speziellen Vorrichtungen senken, stellt aber höhere Anforderungen an die Kalibrierung und die Verwaltung der Koordinatensysteme. Der Leitfaden zur Roboterprogrammierung für industrielle Prozesse erklärt Flächenabdeckung, Werkzeugorientierung und Lackierbahnen ausführlicher.
Fahrachsen, Portale und große Werkstücke
Externe Achsen vergrößern die Reichweite, erhöhen aber auch die Zahl möglicher Konfigurationen für jeden Zielpunkt. Mit OLP bewertet der Ingenieur den kombinierten Bewegungsbereich, statt Roboterarm und Fahrachse getrennt zu prüfen.
Programmiere das System, nicht jeden Roboter einzeln
Mehrroboterzellen bündeln viel Bewegung auf engem Raum. Reichweite, Abstände, Timing, Koordinatensysteme und Steuerungslogik hängen zusammen. Änderst du eines davon, verändern sich die anderen womöglich mit.
Mit OLP erkennen Ingenieure diese Wechselwirkungen, bevor sich die erste Produktionsanlage bewegt. Sie können Bewegungen im Kontext programmieren, den kompletten Ablauf durchspielen und Code für jede konfigurierte Steuerung erzeugen.
Kalibrierung, Steuerungswissen und Tests vor Ort bleiben wichtig. Doch der erste komplette Durchlauf sollte nicht das erste Mal sein, dass jemand die Roboter zusammen in Bewegung sieht.
Erfahre mehr über Visual Components Robotics OLP oder buche eine Demo.
Häufig gestellte Fragen
Die Programmierung per Teach Pendant wird schwierig, weil der Programmierer mehrere Roboter, mechanische Einheiten und aktive Tasks im Blick behalten und wissen muss, welche Maschinen sich bewegen dürfen. Eine Bahn, die für einen Roboter sicher aussieht, kann für einen anderen ein Kollisionsrisiko bedeuten. Hinzu kommen bewegte Werkstücke, Koordinatensysteme und externe Achsen: Sie machen es schwerer abzuschätzen, wie sich Änderungen auf die gesamte Zelle auswirken.
Mit OLP programmieren Ingenieure alle Roboter, Positionierer, Fahrachsen und Werkzeuge in einer gemeinsamen 3D-Umgebung. Sie können das Zusammenspiel testen, Bewegungen simulieren, Kollisionen erkennen, die Synchronisation prüfen und steuerungsspezifischen Robotercode erzeugen, bevor die Inbetriebnahme beginnt. Das senkt Risiken, verkürzt die Programmierzeit vor Ort und hilft, Probleme aufzudecken, bevor Produktionsanlagen zum Einsatz kommen.
Die Simulation kann Erreichbarkeit, Kollisionsfreiheit, Achsgrenzen, Singularitäten, Prozessorientierung, Synchronisationslogik und Taktzeiten prüfen. Testen Ingenieure diese Faktoren in einem virtuellen Modell, erkennen sie mögliche Probleme und optimieren das System, bevor die reale Zelle läuft.
Zum Weiterlesen
Neu: FactoryLens macht aus Fabriksimulationen realistische Kundenerlebnisse
Visual Components stellt FactoryLens vor und erweitert damit die Zusammenarbeit mit NVIDIA bei industriellen digitalen Zwillingen. Mit FactoryLens können Systemintegratoren und Maschinenbauer ihre Simulationen aus Visual Components mit realistischen Materialien,...
Fertigungssimulation: Worauf du 2026 achten solltest
Ein objektiver Blick auf Features, Preisüberlegungen und Bewertungskriterien für Simulationssoftware. Erfahre, worauf du achten solltest und wie du die passenden Tools für deine Fertigungsanforderungen findest.
Visual Components 5.1 – Den Shopfloor mühelos im Griff
Simuliere große Fabriken mit intelligenterer mobiler Roboternavigation, zuverlässiger Physik und echter Steuerungslogik. Visual Components 5.1 macht es einfacher, große Fabriken mit mobilen Robotern, präziser Physik und echter Steuerungslogik zu simulieren....