Kuka Roboter Rückpositionierung

  • Hi,


    ich habe ein Problem mit der automatischen Rückpositionierung des Roboters, wenn dieser von der Bahn abkommt.


    Folgendes Szenario:


    - Roboter setzt irgendwo im Programm bei einer Bewegung von Punkt A nach Punkt B mit dem Greifer auf und löst einen Interrupt aus.

    - Im Falle eines Aufsetzens fährt der Roboter automatisch Z LIN REL 300 nach oben.

    - Programm läuft dann an der ursprünglichen Stelle weiter.

    - Roboter setzt dann Quittiermeldung "Rückpositionieren" ab. Wenn man diese quittiert, fährt der Roboter wieder zurück auf seine ursprüngliche Bahn, von der er die Bewegung fortsetzt.


    Es gibt wohl zwei Möglichkeiten damit umzugehen:


    1: Problem ist die Quittierung. Muss das sein oder kann man konkrete Quittierungsnummern vom Quittieren befreien?

    2: Was ich auch versucht habe, ist eine Bewegung LIN $POS_RET am Ende des Interrupt-Programms. Danach geht's dann ohne Quittierung weiter, so wie es sein soll. Problem hier: die Bewegung LIN $POS_RET geschieht im Interrupt-Programm, d.h. die Bewegung selber wird nicht vom Interrupt überwacht.


    PTP POS_ACT/ LIN POS_ACT bringt hier nix.


    Der Roboter soll einfach Punkt B anfahren, ohne das etwas quittiert werden muss. Weiterhin sollen natürlich alle Bewegungen vom Interrupt überwacht werden.


    Habt ihr dafür eine Idee? Es handelt sich um die KRC4.


    Danke und Gruß


    Simon

  • AD
  • Hast du versucht die vorhergehende Bewegung im Interrupt abzubrechen? In einem Suchprogramm breche ich die Bewegung mit

    Code
    INTERRUPT OFF 1
    BRAKE F
    WAIT SEC 0.5

    ab.

    Den Roboter "in seinem Lauf hält weder Ochs noch Esel auf!"

  • Quote

    Hast du versucht die vorhergehende Bewegung im Interrupt abzubrechen?

    Ja. Und zwar genau so, wie du es gepostet hast.


    Vereinfacht sieht mein Interrupt-Programm so aus:

    Der Greifer soll immer ein Stück hochfahren, wenn er aufsetzt. Problematik ist hier die Bewegung LIN $POS_RET, da diese ohne Interrupt-Überwachung gefahren wird. Ich muss sie aber fahren, um keine Quittiermeldung bzgl. der Rückpositionierung zu erhalten.

  • Da sollte man eher mit resume arbeiten, d.h. dann dass die Bewegung wirklich abgebrochen wird, und in das aufrufende Programm zurückgesprungen wird. Da muss man dann allerdings den Abbruch separat behandeln und wieder auf die Zielposition fahren.

    Hier im Forum nach "Resume" suchen, da findet sich sicherlich was.

  • Da sollte man eher mit resume arbeiten, d.h. dann dass die Bewegung wirklich abgebrochen wird, und in das aufrufende Programm zurückgesprungen wird. Da muss man dann allerdings den Abbruch separat behandeln und wieder auf die Zielposition fahren.

    Hier im Forum nach "Resume" suchen, da findet sich sicherlich was.

    Es handelt sich hier um eine Überwachung , dass der Greifer nicht aufsetzt. Diese soll immer aktiv sein und wurde daher als globaler Interrupt deklariert. Somit kein "Resume" möglich.

  • Ich verstehe das so, dass der Robi wieder auf die Position vor dem Interrupt zurück fährt... ansonsten bin ich da leider raus. Ich breche Bewegungen wie oben beschrieben ab und fahre dann nach einem "RESUME" mit einer andern Bewegung weiter. Sry...


    Edith sagt: Ansonsten schreib dir mal 'nen Stop, bzw "HALT" in den Interrupt um dann im SingleStep die Zeilen einzeln zu bearbeiten, um zu sehen wann der Robi was macht...

    Den Roboter "in seinem Lauf hält weder Ochs noch Esel auf!"

    Edited once, last by AtoK09 ().

  • Ich verstehe das so, dass der Robi wieder auf die Position vor dem Interrupt zurück fährt...

    Das ist korrekt. Soll auch so sein. Problem ist, dass die Bewegung LIN $POS_RET im Interrupt-Programm gefahren wird und damit nicht von selbigem Interrupt überwacht wird. Es könnte also zu einem Aufsetzer/Crash während dieser Bewegung kommen.

  • Es handelt sich hier um eine Überwachung , dass der Greifer nicht aufsetzt. Diese soll immer aktiv sein und wurde daher als globaler Interrupt deklariert. Somit kein "Resume" möglich.

    Da handelt es sich m. W. um einen Irrtum. Auch nicht globale Interrupts können immer und überall aktiv sein. Einfach mal ausprobieren. Wir benutzen das seit Jahren so für die Grundstellungsfahrt, Luftdrucküberwachung, Kollosionserkennung.....

    Edit: Allerdings ist mir nicht klar, wie man nach einer Kollision ohne weiteres Zutun einfach wieder auf die selbe Position fahren kann, und die Kollision dann nicht mehr auftreten soll?!

  • ...Allerdings ist mir nicht klar, wie man nach einer Kollision ohne weiteres Zutun einfach wieder auf die selbe Position fahren kann, und die Kollision dann nicht mehr auftreten soll?!

    Hier gehe ich mit! Du brichst die Bewegung durch Interrupt, "BRAKE F" ab, um dann mit PTP $POS_RET wieder auf den Kollisionspunkt zu fahren? Warum?

    Den Roboter "in seinem Lauf hält weder Ochs noch Esel auf!"

  • Hier gehe ich mit! Du brichst die Bewegung durch Interrupt, "BRAKE F" ab, um dann mit PTP $POS_RET wieder auf den Kollisionspunkt zu fahren? Warum?

    Der Interrupt wird ausgelöst wenn der Roboter irgendwo aufsetzt. Das wird zu 99% beim Aufnehmen oder Ablegen des Produkts (hier Kisten) geschehen.


    Roboter setzt auf --> Interrupt löst aus --> Bewegung wird gestoppt --> Bediener bekommt auf SPS Meldung "Wiederholen" oder "Abbruch"


    Wiederholen: Erneuter Versuch die Kisten aufzunehmen. Der Bediener hat die Kisten gradegerückt, besser positioniert, was auch immer, damit der Greifer die Kisten nun aufnehmen kann. Programm geht ganz normal weiter. Erste Fahrt: LIN $POS_RET.


    Abbruch: Kein erneuter Versuch die Kisten aufzunehmen. Programmabbruch, Grundstellung.

  • Bedeutet, nach , bzw. vor POS_RET wird die Situation gerade gerückt, dann ist ja alles gut! Weiter im Text, dann doch mit RESUME.

    Den Roboter "in seinem Lauf hält weder Ochs noch Esel auf!"

  • Ich verstehe ehrlich gesagt nicht richtig, was mir "Resume" bringen soll. Derzeit ist der Interrupt im Hauptprogramm deklariert. Ich möchte aber immer in dem Ablauf weitermachen, in dem ich mich gerade befinde. Durch "Resume" müsste ich mich doch festlegen, wo ich den Interrupt deklariere, oder nicht?

  • Mit dem "RESUME" setzt du das Programm an der Stelle fort, an der der Interrupt ausgelöst hat: du brichst ab, der Bediener greift ein, drückt "wiederholen", POS_RET positioniert den Robbie an die "richtige" Stelle und jetzt möchtest du dein Programm doch wieder in deinem UP weiter abarbeiten!


    Edith sagt: Deklaration des Interrupt im Hauptprogramm, auslösen des Interrupt im Unterprogramm. Der PZ springt in die Interruptroutine macht dann so Interruptdinge und springt mit "RESUME" wieder in das UP wo der Interrupt ausgelöst wurde.

    Den Roboter "in seinem Lauf hält weder Ochs noch Esel auf!"

  • ..

    Das wird zu 99% beim Aufnehmen oder Ablegen des Produkts (hier Kisten) geschehen.

    ...


    Ich verstehe ehrlich gesagt nicht richtig, was mir "Resume" bringen soll. Derzeit ist der Interrupt im Hauptprogramm deklariert. Ich möchte aber immer in dem Ablauf weitermachen, in dem ich mich gerade befinde. Durch "Resume" müsste ich mich doch festlegen, wo ich den Interrupt deklariere, oder nicht?

    Da wird es dann wohl keine universelle Strategie geben.

    Aber was spricht denn dagegen in dem einen Unterprogramm, in dem der genannte Fall zu 99% vorkommen wird einen 'Spezialfall' zu programmieren:

    Den globalen Interrupt ausschalten, einen lokalen deklarieren, den dann im Fall des Falles mit Resume beenden, und die Fehlerbehandlung machen, dann den lokalen abschalten und den globalen wieder einschalten.

    Das Programmiererleben ist halt nicht so einfach wie man sich das manchmal vorstellt.

  • Edith sagt: Deklaration des Interrupt im Hauptprogramm, auslösen des Interrupt im Unterprogramm. Der PZ springt in die Interruptroutine macht dann so Interruptdinge und springt mit "RESUME" wieder in das UP wo der Interrupt ausgelöst wurde.

    Er springt eben mit "RESUME" NICHT wieder in das UP...sondern in das Hauptprogramm, weil er dort deklariert wurde - oder ich versteh was komplett falsch.

  • Da wird es dann wohl keine universelle Strategie geben.

    Aber was spricht denn dagegen in dem einen Unterprogramm, in dem der genannte Fall zu 99% vorkommen wird einen 'Spezialfall' zu programmieren:

    Den globalen Interrupt ausschalten, einen lokalen deklarieren, den dann im Fall des Falles mit Resume beenden, und die Fehlerbehandlung machen, dann den lokalen abschalten und den globalen wieder einschalten.

    Das Programmiererleben ist halt nicht so einfach wie man sich das manchmal vorstellt.

    Das würde wohl gehen. Schade, leider keine 100% Lösung :-)


    Danke an euch alle!

  • Er springt eben mit "RESUME" NICHT wieder in das UP...sondern in das Hauptprogramm, weil er dort deklariert wurde - oder ich versteh was komplett falsch.

    Du hast recht... deshalb Deklariere ich meine Interrupts auch für/ in diversen UP'S. Sorry für die Fehlinformation.

    Den Roboter "in seinem Lauf hält weder Ochs noch Esel auf!"

  • Das würde wohl gehen. Schade, leider keine 100% Lösung :-)


    Danke an euch alle!

    Das ist eine 100% Lösung. Wäre nur keine, wenn es denn gar nicht ginge. Aber mit etwas Aufwand bekommt man 100% der Fälle in den Griff. Sorry, aber wenn es ganz einfach wäre, dann könnte es ja wohl jeder. :)

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now