Schnellstmöglich abbremsen (KRC2)

  • Ich möchte zwecks Erkennung der Werkstückoberfläche unser Bauteil antasten. Ist hier im Forum auch schon tausend mal erklärt worden. (Interrupt usw.)


    Funktioniert soweit auch alles, nur:


    Wenn ich die Oberfläche erreiche, soll der Roboter natürlich schnellstmöglich anhalten, sonst verbiegt er mir das Werkzeug (Plasmaschneider, Werkstückfindung erfolgt über Kontakt mit der Schneiddüse)


    Die Bewegung halte ich mit BRAKE F an, jedoch würde ich mir ein noch schnelleres Stoppen, bzw. eine sofortige Richtungsumkehr wünschen.
    Geht das noch besser als mit BRAKE F ?


    Ich weiss, das es die Software TOUCH-SENSE gibt, und die habe ich auch verwendet. Problem ist derzeit noch, das sich diese Software in Verbindung mit Spline-Kurven bei uns nach dem 4. Antasten so aufhängt, das man die KRC neu booten muss. Kuka ist aber an der Sache dran.


    Bis diese Sache gelöst ist, würde ich ganz gerne eine ordentliche Zwischenlösung programmieren.


    Touch-Sense funktioniert ja über den Funktionsgenerator, jedoch mit der Klasse $TECH.CLASS=#Touch, die im Handbuch natürlich nicht beschrieben ist. Hat evtl. jemand da neuere Unterlagen?

  • Schritt für Schritt zum Roboterprofi!
  • Hi,


    so viel ich weiß, heißt BRAKE F schon bremsen mit maximalen Bremsrampen. Noch schneller wird dann nur mit Not-Stop unter Einsatz der Bremsen gehen, was aber alles andere als gut für die Mechanik ist.


    Eine Maßnahme wäre, eine klassische Suchfahrt zu realisieren, also mit einem zusätzlichen Sensor die Geschwindigkeit vor erreichen des Bauteils so weit zu reduzieren, dass der Bremsweg beim Auslösen des Tasters noch reicht, das Bauteil nicht zu verformen.


    Gruß ... gooselk

  • Verdammich...


    hab ich mir (leider) auch schon gedacht.


    Der Witz bei der Sache ist nur, das mit dem Touch Sense Optionspaket ein erheblich schnelleres Zurückziehen realisieren lässt. Das machen die, wie gesagt über den Funktionsgenerator. Nur das ist in der Doku (zumindest die mir vorliegt) aber nicht beschrieben.


    Also doch erstmal auf KUKA warten.... :bawling:


    Aber trotzdem danke dafür, dass du den Hiob gespielt hast ;)

  • Hi,


    ich muss zugeben, dass ich mich mit TouchSense nicht wirklich auskenne. Vielleicht gibt es da ja tatsächlich noch was. Ich drück dir die Daumen, dass KUKA da noch mit 'ner Lösung um die Ecke kommt.


    Gruß ... gooselk


  • warum probierst du es denn nicht mit dem Funktionsgenerator


    :grinser043:


    Tja Soma, wenn ich das mal wüsste....


    Nein, aber mal im Ernst. Ich habe die Doku für den Funktionsgenerator, die wahrscheinlich alle aus diesem Forum haben. Die ist von 2000 oder so. (Kann jetzt gerade nicht nachsehen, bin schon zuhause)
    In dieser Doku ist die Funktion, die KUKA für Touchsense verwendet, weder aufgeführt noch dokumentiert. Ich kann natürlich den Code von Touch Sense durchsehen, daher weiss ich ja auch, das der FunkGen verwendet wird. Um aber dann eigene Funktionen zu schreiben, müsste ich doch ein wenig mehr über die Klasse #Touch wissen, um evtl. den Fehler, der bei uns auftritt zu umgehen.


    Und einfach so ins Blaue rein rumzuprobieren macht wahrscheinlich wenig Sinn, zumal das mein erstes Roboterprojekt ist. Aber vielleicht ist ja doch jemand hier, der ein wenig Licht ins Dunkel der #Touch-Klasse bringen kann :hilfe:


    Ansonsten habe ich mir jetzt erstmal mit dem BRAKE F weitergeholfen. Musste dazu die Tastgeschwindigkeit doch drastisch runterfahren, um den Bremsweg auf ein vertretbares Maß zu senken. Jetzt dauert das Antasten zwar dreimal so lang, aber es geht erstmal.


    Ausserdem habe ich ja doch noch Hoffnung, das KUKA das Problem beheben kann, ansonsten :aufsmaul:


    Ich werd mal Rückmeldung geben, wenn die Problemlösung von KUKA eintrifft und von allgemeinem Nutzen sein sollte.

  • Warum programmierst du nicht einfach den entgegesetzten Weg?


    Du must doch nicht mit Brake_F anhalten, wenn du es nicht willst!


    ;Declarierung Interrupts im Falle eines Kontaktes
    INTERRUPT DECL 100 WHEN KONTAKT DO KONTAKT_POS ( )


    $base=base_data[1]
    $tool=tool_data[1]
    BAS (#VEL_CP,2.0)
    LIN Start_Suchen ; Suchposition anfahren
    SUCHEN_1 ( ) ; ins Unterprogramm Suchen springen
    ; HIER erfolg der Einstieg nach RESUME
    INTERRUPT OFF 100
    $ADVANCE=3
    BAS (#VEL_CP,2.0)
    LIN_REL {X -5.0} ; und entgegengesetzt fahren


    ; Suchunterprogramm fahre in Richtung X um das Bauteil zu suchen
    DEF SUCHEN_1 ( )


    $ADVANCE=0
    INTERRUPT ON 100 ; Interrupt Kontakt scharf schalten
    BAS (#VEL_CP,0.2)
    LIN_REL {X 200.0} ; suchen fahren


    END


    DEF KONTAKT_POS ( )


    INTERRUPT OFF 100 ; Interrupt Kontakt aus schalten


    BRAKE
    RESUME ; aus der Bewegung aussteigen


    END

  • Einfach den entgegengestzten Weg programmieren ist ja schön und gut, aber auch hier musst du mal kurz anhalten.
    Ein Brake F ist da sicher schneller(vermute ich zumindest).


    Wenn die Suchfahrt immer gleich ist, dann könntest du ja die Ströme zusätzlich begrenzen um bei evtl. Kollission nichts zu verformen.

  • Hast du das getestet, Handschuh?


    Das mit dem entgegengesetzten Weg habe ich auch schon versucht. Entweder habe ichs falsch gemacht, oder es funktioniert nicht. Anstelle der BRAKE F Anweisung habe ich eine Verfahrbewegung eingetragen, sonst alles gleich. Will er nich, sprich er fährt seine Tastbewegung bis zum bitteren Ende weiter.


    Vermute mal, das eine Bewegung grundsätzlich erst ihr Ziel erreichen muss, oder durch Brake (F) abgebrochen werden muss, bevor eine neue gestartet werden kann. Liege ich da richtig :huh:



    ....
    Wenn die Suchfahrt immer gleich ist, dann könntest du ja die Ströme zusätzlich begrenzen um bei evtl. Kollission nichts zu verformen.


    Es ist so, dass das Plasmaschneidgerät einfach eine 24V Spannung auf die Düse gibt. Wenn die Düse, oder genauer gesagt die Düsenkappe das Werkstück berührt, wird der Stromkreis geschlossen und das Plasma schaltet einen Kontakt auf einen schnellen Eingang vom KUKA. Die Verformung beruht also nur auf dem Bremsweg.


    Aber danke schon mal an alle, die sich hier Gedanken gemacht haben. :blumen:

  • Schau mal in der KUKA Doku nach, da steht irgendwo, dass er seine Bahn fertig fährt und dann erst den neuen Bewegungssatz startet, ausser du hast eine Brake Anweisung.


    Wenn du etwas Geld zur Verfügung hast, könntest du ja eine zusätzliche Sensorik anbringen, sodass beim Annähern die Geschwindigkeit reduziert wird!!

  • Klar, das kann ich natürlich machen. Ich habe aber die Hoffnung, das KUKA das Problem mit der TouchSense Software in den Griff bekommt.


    Im Moment benötige ich zwar nur eine eindimensionale Positionsinfo über mein Bauteil, (die Z-Position der Oberfläche), im nächsten Schritt muss ich aber Bauteile komplett im Raum vermessen. TouchSense berechnet dann aus mehreren gefundenen Positionen die Orientierung im Raum und dreht und verschiebt das Koordinatensystem entsprechend. Ist eigentlich eine feine Sache, das TouchSense Paket :supi:


  • Einfach den entgegengestzten Weg programmieren ist ja schön und gut, aber auch hier musst du mal kurz anhalten.


    Das ist vermutlich der Grund für die Verwendung des Funktionsgenerators. Der kann wohl wie RSI den Roboter im Ipo-Takt bewegen. Und bei Programmen, die die Bewegung im Ipo-Takt steuern, ist der kürzeste Weg auf ein Sensorsignal stehen zu bleiben, ein paar Schritte zurück zu gehen, um das Überschiessen des Roboterarmes zu kompensieren. Wie stark man das machen kann, hängt wohl hauptsächlich von der Größe (Masse) des Roboterarmes ab.



    sodass beim Annähern die Geschwindigkeit reduziert wird


    Das ist die materialschonende Variante, z.B. mit einem Analogsensor, da kann man die Geschwindigkeit mit steigender Annäherung zurücknehmen und auf dem Punkt stehen bleiben.

  • Nur mal so eine Idee! Kommt natürlich darauf an, wie die Armposition des Roboters im Moment des aufsetzens ist.


    Über $TORQUE_AXIS und angepasstem $CURR_RED kann der Roboter ja "Sollposition erreicht" ausgeben wenn er den Wert in $CURR_RED erreicht hat.

  • :denk:


    Wenn du mit deinem Kopf auf das Bauteil fährst und den Stromkreis schliesst,bist du ja schon auf dem Bauteil.Und dann kommt das Bremsen dazu mit seiner Bewegung.Da hilft meiner Meinung nur,entweder langsamer drauf fahren oder mit einem Näherungssensor vorher schon die Geschwindigkeit so verringern, dass die Bewegung so langsam ist, das die Bremsrampe bei Kontakt dein Bauteil nicht verformen kann.


  • ...Da hilft meiner Meinung nur,entweder langsamer drauf fahren oder mit einem Näherungssensor vorher schon die Geschwindigkeit so verringern, dass die Bewegung so langsam ist, das die Bremsrampe bei Kontakt dein Bauteil nicht verformen kann.


    Entweder das, oder die Bremsrampe erhöhen.


    Wenn man sich das TouchSense mal in Aktion ansieht, merkt man förmlich den Ruck, der bei der Richtungsänderung auftritt und die Achse vom Bauteil weggefahren wird. Hexen kann die Software natürlich auch nicht, aber gegenüber meiner Brake F Lösung kann ich mit der TouchSense die Oberfläche dreimal so schnell anfahren ohne das sich etwas verbiegt.


    Nur mal so nebenbei: Wir bearbeiten Rohre mit einer Wandstärke von 3-12mm. Da verbiegt sich erstmal nichts. Der Plasmaschneider selbst sitzt in einem Kollisionsschutz, der erstmal ein paar mm nachgibt, bevor er auslöst. Von daher fahre ich mir im Moment nichts kaputt. Nur jede Antastung dauert jetzt halt doch länger, da ich, wie du schon vorgeschlagen hast, die Antastgeschwindigkeit stark reduziert habe.


  • Wenn man sich das TouchSense mal in Aktion ansieht, merkt man förmlich den Ruck, der bei der Richtungsänderung auftritt und die Achse vom Bauteil weggefahren wird.


    Dann ist es genau so, wie ich oben schon geschrieben habe. Der guckt in jedem Zyklus, ob das Signal schon da ist und beendet die Bewegung dann mit ein paar Schritten in die entgegengesetzte Richtung. Quasi die maximale Bremsrampe, wie bei einer E-Lok: Vollgas zurück, natürlich nur ein paar Millisekunden.


    Geht wohl auch etwas auf die Getriebe, aber vielleicht weniger, als wenn der Roboter irgendwo dran stößt. :denk:

    Einmal editiert, zuletzt von Urmel ()

  • Dann ist es genau so, wie ich oben schon geschrieben habe. Der guckt in jedem Zyklus, ob das Signal schon da ist und beendet die Bewegung dann mit ein paar Schritten in die entgegengesetzte Richtung. Quasi die maximale Bremsrampe, wie bei einer E-Lok: Vollgas zurück, natürlich nur ein paar Millisekunden.


    Fast....


    Die Roboter fährt einen einstellbaren Weg zurück, das könnten theoretisch auch 2m sein. Genauer gesagt fährt der Roboter auf den Startpunkt der Suchbewegung zurück.


  • Die Roboter fährt einen einstellbaren Weg zurück, das könnten theoretisch auch 2m sein. Genauer gesagt fährt der Roboter auf den Startpunkt der Suchbewegung zurück.


    Ok, was man macht, wenn der Punkt gefunden ist, hängt von der Anwendung ab.


    Aber zu deiner Frage zurück, meines Wissens nach ist es beim Kuka ohne Zusatzpakete schwierig so etwas zu realisieren. Da bleibt wohl nur der Funktionsgenerator.


    Bewegungsbefehle, die Bewegungen im Steuerungstakt erlauben, haben eher die Kleinroboter (Denso, Mitsubishi, Stäubli, ...), ausserdem haben die meist einen schnelleren Takt und können deshalb schneller zurückzucken. Trotzdem würde ich auch da einen Sensor, der einen Abstandswert liefert, vorziehen und bei der Richtungsumkehr mit abnehmenden bzw. zunehmenden Schritten fahren, das sieht schon optisch besser aus ...


  • ... Trotzdem würde ich auch da einen Sensor, der einen Abstandswert liefert, vorziehen und bei der Richtungsumkehr mit abnehmenden bzw. zunehmenden Schritten fahren, das sieht schon optisch besser aus ...


    Eigentlich ist die TouchSense hauptsächlich dafür da, mit dem Drahtende einer Schweißpistole das Bauteil anzutasten. So kann man z.B. mit 2 Punkten eine V-förmige Schweißnaht vermessen.


    Das mit dem Abstandssensor ist natürlich immer eine Option, nur müsste der vor dem Schneiden noch weggefahren oder geklappt werden, sonst wirds dem da unten an der Schneiddüse doch ein wenig warm ums Sensorherz.


    Aber egal. Im Moment funktionierts erstmal, und KUKA arbeitet zumindest schon am Problem, wie ich erfahren habe.


    Mal abwarten :D

    Einmal editiert, zuletzt von Grubba ()

  • Hat ein vorpsoter schonmal bemerkt:


    Momentrenbetrieb kann (muss aber nicht) eine Loessung sein.
    Habe damit lange nichts mehr gemacht - hatte damals zumindest die Einschraenkung, dass sich das nur mit den Grunsachsen sicher einsetzen laesst. Ist vermutlich immer noch so wegen Getriebe.


    Gruss Stefan

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