KI-Lehrgang für die Industrierobotik · Praxis in Mainburg mit 10 Wochen Online-Begleitung Zum Workshop →

← Wissen

Roboter programmieren: KRL, RAPID und MELFA im Vergleich

Kurz: Wer einen KUKA, einen ABB und einen Mitsubishi programmiert, schreibt dreimal dasselbe in drei Sprachen: KRL, RAPID und MELFA BASIC. Die Befehle heißen anders, die vier Angaben in jeder Bewegungszeile sind identisch: wohin, auf welchem Weg, wie schnell und wie genau. Wer das einmal sieht, liest jede der drei Sprachen — und findet im Handbuch die Stelle, an der der Rest steht.

Drei Namen für dieselbe Bewegung

Ein Industrieroboter kennt genau drei Arten, von A nach B zu kommen. Jeder Hersteller nennt sie anders, und das ist der einzige Grund, warum der Umstieg schwer wirkt.

Was der Roboter tutKUKA (KRL)ABB (RAPID)Mitsubishi (MELFA BASIC)
schnellster Weg, Bahn egalPTPMoveJMov
Gerade im RaumLINMoveLMvs
KreisbogenCIRCMoveCMvr

Das ist die ganze Grundlage. Punkt-zu-Punkt heißt: Die Steuerung fährt alle Achsen gleichzeitig los und ist fertig, wenn die letzte ankommt — das ist der schnellste Weg, aber welche Kurve die Werkzeugspitze dabei durch den Raum beschreibt, weiß niemand vorher genau. Linear heißt: Die Spitze fährt eine Gerade, und die Steuerung rechnet dauernd aus, wie die sechs Achsen dazu stehen müssen.

Die Entscheidung, die wirklich zählt

Punkt-zu-Punkt oder Bahn ist keine Geschmacksfrage, sondern die einzige Entscheidung in dieser Zeile, die Sie teuer zu stehen kommen kann.

  • Punkt-zu-Punkt im freien Raum. Schneller, schont die Mechanik, und die Steuerung sucht sich den bequemsten Weg. Nur: Sie wissen nicht, wo das Werkzeug unterwegs ist. Zwischen zwei Punkten, die beide frei liegen, kann der Bogen mitten durch die Vorrichtung führen.
  • Linear überall dort, wo es eng wird — Einfahren in eine Vorrichtung, Herausziehen aus dem Greifer, alles nah am Werkstück. Hier wollen Sie wissen, wo die Spitze ist, und nicht schneller sein.
  • Kreisbogen, wo die Kontur einer ist. Ein Kreis, den man aus vielen kurzen Geraden zusammensetzt, ist an der Oberfläche sichtbar.

Die häufigste Ursache für eine Kollision, die „aus dem Nichts“ kommt, ist eine Punkt-zu-Punkt-Bewegung an einer Stelle, an der jemand eine Gerade erwartet hat.

Ein Roboter zeichnet mit einem Stift einen Winkel auf Papier — einmal mit scharfer Ecke, einmal überschliffen
Überschleifen in 55 Sekunden, am Papier gezeigt · Der KI & Roboterkanal · öffnet auf YouTube

Vier Angaben stecken in jeder Zeile

Egal in welcher der drei Sprachen: Eine Bewegungszeile beantwortet immer dieselben vier Fragen. Nur die Schreibweise unterscheidet sich.

FrageKUKA (KRL)ABB (RAPID)Mitsubishi (MELFA BASIC)
Wohin?PunktnamerobtargetPositionsvariable
Auf welchem Weg?PTP / LIN / CIRCMoveJ / MoveL / MoveCMov / Mvs / Mvr
Wie schnell?Vel=, $VELspeeddata (v1000)Spd, Ovrd
Wie genau am Punkt?CONT, $APOzonedata (z50, fine)Cnt
Womit? (Werkzeug)TOOL_DATA, $TOOLtooldata (tool0)Tool
Bezogen worauf? (Basis)BASE_DATA, $BASEwobjdata (wobj0)Base

Ein RAPID-Programm schreibt das alles in eine Zeile: Ziel, Geschwindigkeit, Zone, Werkzeug. Bei KUKA verteilt sich dasselbe auf die Bewegungszeile und ein Datenpaket dahinter; wer im Inline-Formular arbeitet, füllt es über eine Maske aus, statt es zu tippen. Bei Mitsubishi stehen Geschwindigkeit und Genauigkeit oft als eigene Zeile vor der Bewegung und gelten dann weiter.

Das ist der eigentliche Unterschied — nicht die Befehlsnamen, sondern wo eine Angabe steht und wie lange sie gilt. Wer von RAPID auf MELFA BASIC wechselt und die Geschwindigkeit weiter in jede Zeile schreiben will, sucht lange.

Überschleifen: die Angabe, die man zuerst falsch macht

Steht der Roboter an jedem Punkt exakt still, wird die Bahn genau — und das Programm langsam und ruckelig. Überschleifen heißt: Er fährt den Punkt gar nicht an, sondern schneidet die Ecke innerhalb einer erlaubten Abweichung.

Bei ABB ist das die zonedata: fine bedeutet Halt auf dem Punkt, z50 bedeutet, dass 50 mm daneben in Ordnung sind. Bei KUKA sind es CONT und die Abstandsangabe dahinter, bei Mitsubishi Cnt.

Zwei Fehler passieren fast jedem einmal. Der erste: großzügig überschleifen und sich wundern, dass der Roboter das Werkstück streift — die Zone ist eine Kugel um den Punkt, und in einer engen Vorrichtung ist sie zu groß. Der zweite: an einer Stelle Halt erzwingen, an der es niemanden stört, und dafür bei jedem Takt eine halbe Sekunde bezahlen.

Ohne Werkzeug und Basis stimmt keine Zeile

Alle drei Sprachen beziehen jede Bewegung auf zwei Koordinatensysteme: das Werkzeug — also den Tool Center Point, den Punkt an der Werkzeugspitze — und die Basis, das Bezugssystem des Werkstücks.

Stimmt das Werkzeug nicht, ist jede Linear- und Kreisbewegung falsch, weil die Steuerung sie für den falschen Punkt ausrechnet. Stimmt die Basis nicht, verschiebt sich das ganze Programm. Beides ist kein Programmierfehler und wird trotzdem im Programm gesucht — oft stundenlang. Wie man den Tool Center Point vermisst und warum vorher justiert werden muss, steht im zweiten Beitrag dieser Reihe: TCP vermessen: den Tool Center Point richtig einmessen.

Der praktische Nutzen der Basis wird oft übersehen: Wird die Vorrichtung versetzt, muss man nicht jeden Punkt neu teachen. Es reicht, die Basis neu zu vermessen — alle darauf bezogenen Punkte wandern mit.

Was sich nicht übersetzen lässt

Die Bewegungen sind austauschbar, der Rest ist es nicht. Wer ein Programm von einem Hersteller zum anderen trägt, kommt genau hier ins Stocken:

  • Ein- und Ausgänge werden völlig verschieden angesprochen und hängen an der Anlage, nicht an der Sprache.
  • Sicherheit. Schutzräume, sichere Geschwindigkeit, Zustimmtaster — das ist bei jedem Hersteller ein eigenes System und gehört nicht in eine Vergleichstabelle.
  • Achskonfiguration. Dieselbe Position im Raum ist mit mehreren Achsstellungen erreichbar. Wie man festlegt, welche gemeint ist, löst jeder Hersteller anders — und genau daran scheitern übertragene Programme, obwohl alle Punkte stimmen.
  • Interrupts und Fehlerbehandlung. Was passiert, wenn mitten in der Bewegung ein Signal kommt? Die Antworten unterscheiden sich grundlegend.

Wenn Sie ein Sprachmodell fragen

KRL, RAPID und MELFA BASIC sind gut dokumentiert, und ein Sprachmodell kann Ihnen den Aufbau einer Bewegungszeile richtig erklären. Bei den Feinheiten wird es unzuverlässig — und zwar auf die unangenehme Art: Es erfindet Befehle, die es nicht gibt, und schreibt sie in derselben ruhigen Sicherheit hin wie die richtigen.

Deshalb dieselbe Regel wie im ersten Beitrag dieser Reihe: Fragen Sie gegen Ihre eigenen Handbücher, nicht gegen das Weltwissen. Wenn die Antwort mit der Fundstelle im Handbuch kommt, können Sie sie in zehn Sekunden prüfen — und die Steuerungsgeneration stimmt dann auch. Wie das geht, steht hier: Roboter-Handbuch durchsuchbar machen.

Und die Probe bleibt dieselbe wie an der echten Anlage: im Einrichtbetrieb, reduzierte Geschwindigkeit, Schritt für Schritt. Kein Programm geht ungeprüft in den Automatikbetrieb, egal wer es geschrieben hat.

Häufige Fragen

Welche Sprache soll ich zuerst lernen?

Die des Roboters, der in Ihrem Betrieb steht. Der Übergang zur zweiten kostet danach Tage, nicht Monate — weil die Konzepte dieselben sind und nur die Wortwahl wechselt.

Brauche ich Programmierkenntnisse?

Nein. Wer aus der Instandhaltung oder der Fertigung kommt, hat es sogar leichter: Der schwierige Teil ist nicht die Syntax, sondern die räumliche Vorstellung — Koordinatensysteme, Orientierung, Achskonfiguration. Wer Maschinen kennt, bringt das mit.

Was ist der Unterschied zwischen Inline-Formular und Textprogrammierung?

Dasselbe Ergebnis, zwei Wege dorthin. Das Formular führt über Masken und verhindert Tippfehler; im Text sehen Sie, was wirklich in der Zeile steht. Für die Fehlersuche ist der Text unschlagbar — deshalb lohnt es sich, ihn lesen zu können, auch wenn man mit Masken arbeitet.

Und Offline-Programmierung?

Am Rechner erzeugte Programme sparen Stillstand, ändern aber nichts an diesem Beitrag: Am Ende steht KRL, RAPID oder MELFA BASIC auf der Steuerung, und Werkzeug und Basis müssen an der echten Anlage stimmen. Ohne saubere Vermessung passt kein offline erzeugtes Programm.

Wenn Sie es an echten Anlagen üben wollen

Im Praxis-Workshop in Mainburg programmieren Sie an Anlagen von ABB, KUKA, Mitsubishi und NACHI — dieselbe Aufgabe an verschiedenen Steuerungen, damit der Unterschied zwischen „andere Sprache“ und „anderes Konzept“ nicht Theorie bleibt. Drei Tage als Basis, fünf Tage mit mehr Zeit für die Umsetzung.

Vertrag widerrufen