Umorienteirung in CIRC-Bewegungen

  • Hallo an alle,


    der Roboter, mit dem ich arbeite ist ein KR30HA. Der machine.dat habe ich die Versionsmummer 8.3 entnommen.

    Ich arbeite mit einer CAM-Software, welche Programme in KRL-Syntax ausgiebt.

    Bei dem folgenden Programm führt der Roboter in der zweiten CIRC-Bewegung eine sehr ungesunde Umorientierung des Werzeuges aus.

    Wenn ich die Werte des Hilfspunktes der zweiten CIRC-Bewegung auf die glatten Werte X 10.0 und Y 10.0 ändere findet keine Änderung der Orientierung statt. Genauso bewegt sich der Roboter wie erwartet ohne Umorientierung, wenn ich die Zeile mit CIRC_TYPE=PATH auskommentiere.


    Hat jemand eine Idee, was genau das unerwartete Verhalten auslösen könnte und wie man überprüfen kann, dass so etwas nicht auftritt. Die Programme, die über die CAM-Software generiert werden haben eine recht lange Laufdauer und müssen für die Optmierung in mehrere Schritten geringfügig angepasst werden. Diese jedes Mal im Testmodus Probe zu fahren wäre mit einem nicht unerheblichem Zeitaufwand verbunden.


    Über eure Antworten freue ich mich sehr.

    AHZG

  • Schritt für Schritt zum Roboterprofi!
  • Hallo Hermann, vielen Dank für deine Antwort. Das ist auch die Übergangslösung, die ich aktuell verwende. Allerdings gibt es auch Programme, bei denen die pfadbezogene Interpolation der Werkzeugorientierung wichtig ist. Daher hoffe ich, dass jemand die tatsächlich Ursache für das Verhalten kennt.

  • Es ist gefährlich, mit Offline-Programmierung exakte 180°-Winkel zu erzeugen. In Deinem Code entsteht ein Kreisbogen mit 3mm Durchmesser, aber eben um exakt 180°, während alle anderen Winkel 0 sind. Die pfadbezogene Orientierungsführung kommt da am Ende undefiniert raus und muss wieder "richtig" gedreht werden, und es ist dem Roboter nicht ganz klar, wie herum nun eigentlich.

    Durch winzige Änderungen des Zwischenpunktes machst Du den Kreis flacher (<180°) oder bauchiger (>180°), das hat dann die beobachtete Auswirkung. Es spielen auch Überschleifparameter noch hinein, soweit ich weiß.


    Im Prinzip schaffst Du Dir mit dieser Art der Programmierung einen gefährlichen Zufallsgenerator, wie ich auch schon leidvoll feststellen musste. Wenn es die Applikation zulässt, solltest Du die Winkel künstlich "verschmutzen", oder den Folgepunkt in einer naheliegenden Orientierung anfahren, wenn die bahnbezogene Orientierung tatsächlich erwünscht ist.


    Grüße,

    Michael

  • Martin Huber: Die Verwendung von ori_type=joint wollte ich eigentlich vermeiden, da dort die Anstellung des Werkzeuges zur Bahn nicht klar definiert interpoliert wird.


    fubini: Der Roboter befindet sich während der Bewegung weit weg von Singularitäten. Mit Ungesund meine ich, dass der Roboter während der CIRC-Bewegung das Werkzeug um 180° um die Stoßrichtung drehen und dabei sogar in den Endschalter fahren will. Das ganze dann mit maximaler Geschwindigkeit und Beschleunigung wenn diese nicht durch den Testmodus begrenzt sind ...


    Programmiersklave: Viele Dank für den Hinweis. Ich werde das mit der "Bauchigkeit" testen. In unserer Applikation haben wir die Möglichkeit den maximalen Winkel von Kreisbewegungen zu begrenzen, sodass größere Winkel dann durch mehrere Kreisbewegungen zusammengesetzt werden. Das sollte das Problem dann hoffentlich vermeiden.

  • In unserer Applikation haben wir die Möglichkeit den maximalen Winkel von Kreisbewegungen zu begrenzen, sodass größere Winkel dann durch mehrere Kreisbewegungen zusammengesetzt werden. Das sollte das Problem dann hoffentlich vermeiden.

    Ich denke nicht, dass das "Problem" innerhalb der Kreisbewegung auftritt. Es dürfte an der Stelle kommen, wenn der TCP den Kreis verlässt. Er kommt aus dem Bogen mit {a 180} raus und muss LIN wieder auf den nächsten Punkt mit {a 0}. Und jetzt kommt es eben darauf an, ob die Realität 179.99 lautet oder -179,99 - bei LIN interessieren ihn S und T nicht, er will gleichmäßig und kurz zum Ziel interpolieren. Du müsstest vielmehr auf der Strecke zwischen dem Ausgang des Kreises und dem nächsten LIN-Punkt einen Zwischenpunkt mit definierter Orientierung haben, um das zu vermeiden.


    Es ist wie beim Totpunkt einer Dampfmaschine, es ist eine Form der Singularität. Orientierungen aufeinander folgender Punkte in LIN, die sich exakt gegenüberliegen, sind böse, Du musst Dein Offline-Programmiersystem dazu erziehen, solche nicht zuzulassen.


    Grüße,

    Michael

  • In diesem Programm ist der Winkel A an allen Positionen 0. Es gibt keine Punkte mit gegenüberliegender Orientierung. Es soll eine Umorientierung relativ zur Bahn, aber nicht relativ zum Werkstückkoordinatensystem geschehen. Die ungewollte Umorientierung beginnt auch mit Beginn der CIRC-Bewegung und nicht nach Abschluss der CIRC-Bewegung.


    Grüße

    AHZG

Erstelle ein Benutzerkonto oder melde dich an um zu kommentieren

Du musst ein Benutzerkonto haben um einen Kommentar hinterlassen zu können

Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen. Geht einfach!
Neues Benutzerkonto erstellen
Anmelden
Du hast bereits ein Benutzerkonto? Melde dich hier an.
Jetzt anmelden