Bewegungsgeschwindigkeit

  • Liebe Community,



    Wir haben Kuka Roboter KR60-3 mit der Steuerung KRC4 .


    Der Roboter macht bei uns Pick & Place Aufgabe. Er wurde seit Jahren programmiert und jetzt wegen einer Erweiterung bei der Linie soll der Roboter schneller fahren um die soll Taktzeit zu erreichen.



    Das Problem ist, der Roboter ist auf 100% eingestellt und alle Joint-Interpolation sind auch auf 100% eingestellt und trotzdem man merkt schon, dass der Roboter gemütlich von A nach B verfährt im Verhältnis mit ändern KUKA Robert, die wir da haben.


    Ich habe die Konfigurationen bei config.dat kontrolliert aber ehrlich zu sagen hat mir nichts aufgefallen.

    Im Anhang befinden sich die config.dat, Bewegungsdatei und ihre DATDatei.


    Ich hoffe, dass ich was übersehen habe und ihr werdet es finden.

  • Schritt für Schritt zum Roboterprofi!
  • Da hätte ich eine Idee gehabt.

    Würde mal die Lastdaten versuchsweise ändern. Z. Bsp. auf Standardwert oder anderes größeres Gewicht eintragen.

    Oder zumindest mal für die Trägheitsmomente von Null verschiedene Werte eintragen (das stimmt ja auf keinen Fall) .

    Hatte auch mal einen Roboter, der bei korrekten Werten schneckengleich in der Gegend rumfuhr, obwohl einzig und allein die Achse 1 bewegt wurde. War aber eine KRC 2.

  • weder werkzeug noch zusatzlast ist reingestellt und mit ILF Bewegungen gewint man kein Rennen da Beschleunigung beschraenkt ist auf DEF_ACC_CP wert (nur 2.3m/s^2). Hauptprogram ist nicht gezeigt, wahrscheinlich taktzeit ist nicht erreicht da vorlauf durch WAIT Befehle gehindert ist. Umstellung auf Spline Stop Condition kann helfen (erfordert Umstellung von PTP/LIN auf SPTP/SLIN)

  • Nein. Das ist was anderes $RED_VEL ist ein Faktor auf den Override $OV_PRO. Man sollte normalerweise nicht direkt am Override drehen sondern eher am $RED_VEL. Machen insbesondere Technologiepakete von KUKA oft so.


    Fubini

  • weder werkzeug noch zusatzlast ist reingestellt und mit ILF Bewegungen gewint man kein Rennen da Beschleunigung beschraenkt ist auf DEF_ACC_CP wert (nur 2.3m/s^2). Hauptprogram ist nicht gezeigt, wahrscheinlich taktzeit ist nicht erreicht da vorlauf durch WAIT Befehle gehindert ist. Umstellung auf Spline Stop Condition kann helfen (erfordert Umstellung von PTP/LIN auf SPTP/SLIN)

    bei Dokus steht bezüglich DEF_ACC_CP nur (

    Je höher der Wert eingestellt wird, um so eher können Überwachungen der Robotersteuerung

    ansprechen. In diesen Fällen wird der Roboter angehalten und eine entsprechende

    Meldung im Meldungsfenster ausgegeben. Verringern Sie in diesem Fall den Wert so weit,

    bis das Programm ohne Fehlermeldungen abläuft

    )


    Ein exakter Wert als max.Wert wurde nicht dargestellt!

    Ich habe bei ändern Roboter bemerkt, DEF_ACC_CP wert wurde auf (3.0) eingestellt.


    Gibt's da irgend eine Gelichung zbs. wie man den passenden Wert rechnen und dann eingeben kann?

    oder wird es wirklich so gerechnet wie in Doku gegeben, dass man den Wert Verringen soll bis keine Fehlermeldung erschein !!

  • Das liegt daran das hinter dem alten LIN und CIRC kein Dynamikmodell steckt. Es wird also gnadenlos mit der Beschleunigung gefahren die du eingibst. Als Folge kommt es dan während der Ausführung zum Zuschlagen von üblicherweise Sollmomentenüberwachungen. Ist das der Fall musst du die Beschleunigung rausnehmen. Im neuen Verfahrbereich (Spline, SLIN, SCIRC) ist das inzwischen anders gelöst. Da ist ein Dynamikmodell in Verwendung und der Roboter reduziert quasi implizit einfach soweit dass es gerade noch fahrbar ist und zur Ausführung keinen Meldungen mehr kommen.


    Fubini

  • Genau! Insofern ist das Dynamikmodell genau die Gleichung, die beschreibt wie der Zusammenhang zwischen Achschleunigung und Momenten ist. Das ist aber keine einfache Gleichung wie s = 1/2 * a t^2 sondern deutlich komplexer. Da spielen Wechselwirkungen einzelner Achsen, aktuelle Last, Reibung, Achsposition, Achsgeschwindigkeit, Achsbeschleunigung, ... mit rein.

  • Gut, in diesem Fall kann ich auch es so verstehen, wenn ich die Bewegungen mit SPLIE statt dem alten LIN/PTP umstellen würde, müsste ich kein Gedanken mehr über den DEF_ACC_CP wert machen, wenn den Wert erhöht werden wird?

  • Im Normalfall nicht. Es kommt zwar sehr vereinzelt noch vor das bei einzelnen Bewegungen Sollmomentenüberwachungen zuschlagen. Hier kann man dann aber lokal nur dort die Beschleunigung (was in dem Fall eigentlich das Achsmoment ist) leicht reduzieren. Aber was du natürlich schon beachten solltest immer korrekte Lastdaten zu setzen.


    Fubini

  • Es wird also gnadenlos mit der Beschleunigung gefahren die du eingibst. Als Folge kommt es dan während der Ausführung zum Zuschlagen von üblicherweise Sollmomentenüberwachungen.

    fubini Sollte doch auch möglich sein, dies zu verhindern bei LIN und CIRC,

    wenn man CP_VEL_TYPE = #VAR_ALL_MODEL hat ?


    DECL CP_VEL_TYPE $CP_VEL_TYPE=#VAR_T1 ;RED. DER CP-GESCHW. BEI UEBERSCHREITUNG DER ACHSGRENZWERTE (#VAR_T1 : NUR IM T1-Betrieb, #VAR_ALL : IMMER, #VAR_ALL_MODEL

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

  • Nein. Bei CP_VEL_TYPE geht es nur um Sollgeschwindigkeiten der Achsen die begrenzt werden bei Singularitäten. Wir reden hier aber von zu hohen Momenten. Ausserdem ist CP_VEL_TYPE eher eine Regelung die während der Ausführung noch versucht zu Retten. Das Dynamikmodell sorgt schon früher dafür, dass es zur Ausführung nichts mehr zu retten gibt. Damit ist das Verhalten deterministisch und nicht wie bei einer Regelung leicht zufällig.


    Fubini

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