Roboter "überfährt" Position bei Geschwindigkeiten > 70%

  • Hallo zusammen,


    Ich habe derzeit ein Problem, zu dem ich bisher im Forum keine Infos finden konnte...

    Eckdaten Roboter:

    KR10 R1420

    KRC4 KSS 8.6.7


    Der Roboter steht bereits beim Kunden und ist auch bereits seit einem Jahr in Betrieb.

    Die Aufgaben des Roboters bestehen aus simplen Pick&Place Aufgaben mit einer Leiterplatte.

    Aufgrund der Taktzeit konnte der Roboter bisher mit einer entspannten Geschwindigkeit von 40-60% fahren.

    Da die Taktzeit nun verringert wurde, wurden die Roboter schneller gestellt, wodurch es plötzlich zu einem mir unbegreiflichen Verhalten des Roboters kam.

    Auf einmal wurden bestimmte Positionen nicht mehr genau angefahren, sondern "überfahren", wodurch der Greifer mit der Leiterplattenzuführung kollidiert.

    Setzt man die Geschwindigkeit wieder runter (OV_PRO < 70%), werden die Positionen wieder genau angefahren.


    Die Bewegung, die der Roboter ausführen muss ist keine komplizierte. Er muss lediglich seinen Arm leicht nach unten ausstrecken, die Achsen A4 + A6 bleiben größtenteils gleich, A5 bewegt sich leicht mit, um den Greifer parallel zum Boden/Station zu halten.

    Der Roboter kommt von einer E6AXIS-Position.

    Die Position, die nicht genau angefahren oder Überfahren wird, ist die gXCX_SP_LOAD_Ent_LP. Hierbei handelt es sich um einen "Stoßpunkt" direkt über der Entnahmeposition (mittig über der Leiterplatte).

    Im Programmbeispiel wurde die Geschwindigkeit für den Fahrbefehl bereits auf VEL = 30% reduziert. Vor der Änderung wurde der Punkt mit VEL = 75% angefahren.


    Meine größte Verwirrung kommt daher, das bei der Inbetriebnahme und Endabnahme beim Kunden der Roboter schon auf 100% gelaufen sind. Und das ohne Crash! :nocheck:

    Die Lastdaten sind nach CAD-Werten eingetragen.

    Ich hatte ein ähnliches Verhalten bei einem anderen Roboter. Hier wurde jedoch eine relative große Achsbewegung (A6 ca. 90°) innerhalb einer kurzen Fahrdistanz von ca. 20cm durchgeführt .

    Auch hier war die Abhilfe, die Anfahrgeschwindigkeit des Punktes runter auf 30% zu setzen.


    Meine Frage wäre, ob jemand eine Vermutung hat, woher das Fahrverhalten kommt? :kopfkratz:

    Ist es der Sprung von einem E6-Axis zu einer E6Pos? Ist es der PTP-Fahrbefehl, der plötzlich einen wesentlich größeren Radius benötigt aufgrund der hohen Geschwindigkeit?


    Der KUKA-Support meinte, ich soll einfach das Überschleifen der E6Axis-Position ausschalten. Das löst eventuell das Problem, aber die Ursache kenne ich trotzdem noch nicht.

    Vielleicht kann hier hier jemand Licht ins Dunkel bringen


    Mit freundlichem Gruß

    Sheep

  • Schritt für Schritt zum Roboterprofi!
  • Du hast da ein Überschleifen von PTP auf PTP. Da gibt es keine Garantien wo der Roboter kartesisch lang fährt. Das eigentliche Überschleifen findet beim PTP im Achskoordinatenraum statt. Du überführst Startachswinkel in Zielachswinkel. Wenn du kartesische Bahnverfolgung brauchst musst du LINs oder CIRCs verwenden. Nachdem das in der Regel langsamer ist als PTPs würde ich sogar SLIN und SCIRC empfehlen.


    Fubini

  • Da gibt es keine Garantien wo der Roboter kartesisch lang fährt.

    Allerdings galt m. W. immer der heilige und unverletzliche Grundsatz, dass der Kuka bei allen Overrides GLEICH fährt - das heisst, keine andere Bahn fährt, wenn man lediglich den Override ändert.


    Wenn man nun feststellt, dass sich der Roboter geschwindigkeitsabhängig "verfährt", lässt das doch eigentlich nur den Schluß zu, dass die Bahnplanung überlastet ist oder die Mechanik nicht mit den Annahmen der Steuerung übereinstimmt (Lastverhältnisse).


    Die Stimmgabel am Greifer impliziert, dass SafeOperation im Spiel ist, um so unverständlicher. Denn die sollte ja merken, dass der Robbi nicht auf der Bahn ist.


    Wäre gespannt zu erfahren, wie das bei Euch aufgelöst wird...

  • Ach die haben nur am Override gedreht. Hab ich glatt überlesen. Ich dachte über vel_axis.


    Override kann höchstens Auswirkung haben ob er einmal Überschleifen kann oder nicht. Kommt denn irgendeine Überschleifen nicht möglich Meldung? Was sagt das System bei Stopnoaprox?


    Fubini

  • Moin ,


    $Stopnoapprox ist ja eigentlich nur für das Meldungshandling da - siehe Doku:


    Meldungstyp bei "Überschleifen nicht möglich"

    In den Betriebsarten T1 und T2 bestimmt $STOPNOAPROX den Meldungstyp für die Meldungen 1123, 1442 und 2920:

    • Entweder nicht stoppende Hinweismeldung
    • Oder stoppende Quittiermeldung

    In den Betriebsarten AUT (KR C), AUT EXT (KR C) und EXT (VKR C) sind diese Meldungen immer Hinweismeldungen. Diese Hinweismeldungen werden in den Automatikbetriebsarten standardmäßig von der smartHMI herausgefiltert und nicht angezeigt (konfigurierbar in C:\KRC\USER\SmartHMI.User.config).



    Ich denke interessanter wäre wie hoch die Überschleifdistanz beim PTP bzw. Lin verfahren eingestellt ist.

    Die Abnahme von GOTO Anweisungen verhält sich reziprok zur Qualität einer Programmierung

  • Trace auf verhalten Schleppfehler wäre hier wirklich interessant.

    Haben wir wirklich auch eine Regelabweichung oder nicht. ( Wenn er sagt, es lief schon mit 100%)

    Was für Lastdaten sind wirklich aktiv und wo stehen wir in KUKA-Load damit dito.

    Manche Maenner bemuehen sich lebenslang, das Wesen einer Frau zu verstehen. Andere befassen sich mit weniger schwierigen Dingen z.B. der Relativitaetstheorie.

  • Vielen Dank für die vielen Antworten :danke:


    Das es vermutlich am Fahrbefehl von PTP zu PTP liegt, war auch mein erster Gedanke.


    Das Überschleifen hatte ich bei der Inbetriebnahme weitesgehend so optimiert, das fast alle Hinweismeldungen auf nicht durchführbare Überschleifungen nicht mehr aufgetreten sind.

    Aber die Anlage steht da auch schon über ein Jahr und der Kunde fingert leider auch gerne an den Positionen rum. Das werde ich mir nochmal genauer anschauen bei Gelegenheit.

    Der E6Axis Punkt wird mit Default-Werten angefahren, also DEF_APO_CPTP = 50; PTP-Approximation [%].


    Der KUKA Support kam noch mit einem weiteren Lösungsvorschlag, welche die Aussage vom Programmiersklave eventuell unterstützen würde.


    Leider bin ich momentan nicht vor Ort, um mir die Daten auszulesen oder Tests fahren zu können. Sobald ich weitere Informationen habe, werde ich sie hier reinschreiben.


    VG

    Wo ein Weg ist, sollte kein Sofa in der Nähe sein.

  • Hallo zusammen,


    wenn man die "alten" Verfahrbefehle (PTP und LIN) verwendet, wird der gewünschte Punkte beim Überschleifen in Abhängigkeit von der Geschwindigkeit (auch Override) angefahren. Das ist hier der Fall.


    Bei den "neuen" Verfahrbefehlen (SLIN und SPTP) werden die Punkte immer gleich, unabhängig von der Geschwindigkeit, angefahren. Grund dafür ist die Berechnung der Bahn mittels Spline. Aber bitte beachte, dass die "neuen" Verfahrbefehle ggf. langsamer sein können als die alten.


    Trotzdem würde ich dir empfehlen die neuen Verfahrbefehle in diesem Fall zu verwenden. Damit sollte sich das Problem auflösen ;)

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