KUKA LBR 4+ Rückzugstrategie

Hallo Kollegen,

ich bin neu hier- also bitte nicht gleich in die Offensive, sollte ich unbemerkt irgendwelche Reglen brechen

Ich benötige für einen LBR 4+ eine Rückzugstrategie, die es mir (bzw. dem Bediener) nach einem Fehler am Roboter ermöglicht, aus allen Lagen mit dem Robi in eine sichere Home- Position zu gelangen.
Da der Leichbauroboter noch so eine Art Vorserienmodell ist und es oft zu unerklärlichen Ausfällen kommt, die teilweise von KUKA auch nicht erklärt/beseitigt werden können, benötigen wir solch eine Funktion dringend an unseren produktiven Bestückungs- LBRs.

Ich hab schon mal begonnen, die Strategie in zwei Teile zu gliedern:
Teil 1- der Robi ist in der Vorwärtsbewegung zum Werkstück bzw. zur Anlage, die er bestücken soll
Teil 2- Der Robi ist in der Rückwärtsbewegung zu seiner Ausgangspos. (Home usw...)

So- Teil 2 bereitet mir aber Probleme!

Ich muss ab diesem "Point of no Return" das Programm vorwärts abfahren. Da dieses Programm aber bei einem Fehlerfall abgewählt wird, muss ich nach initialisieren der "SaveReturn" Funktion genau an diesem Punkt im Programm/Unterprogramm fortfahren. Das Auslesen des Caller Stacks ($PRO_IP) gibt mir zwar Hinweise, wo das passiert ist, aber leider kann ich diesen Stack nicht beschreiben- dem Roboter sozusagen vorlügen, er habe alle Funktionen bis dahin beretis abgearbeitet und soll einfach hier weitermachen.
Leider müssen die Funktionen oft händisch ab- und wieder angewählt werden, damit es wieder funktioniert. Ist so eine dumme Eigenheit des LBR. Das Bedienpanel ist in unserer Produktionslinie verbaut/versteckt- die Anlagenbediener sollen keinen Zugriff darauf haben. Die SaveReturn- Funktion wird über eine Visualisierung initiiert.

Hat irgendwer eine Idee, wie ich diese Herausforderung am elegantesten löse. Dabei ist zu beachten, das diese Roboter mobil auf einem Shuttle montiert sind und mehrere, verschiedene Anlagen bestücken. Somit ist eine definition eines Arbeitsraumes oder sonstige Auswertungen der kart. Ist/Sollpositionen leider nicht möglich. Des Weitern sollen zukünftige Robis mit der selben Funktion ausgerüstet werden, also keine speziell für einen Anlagentyp programmierte Funktion. Es soll tatsächlich das unterbrochene Programm an der Unterbrechungsstelle fortgesetzt werden. Aus dem Cell- Programm heraus werden derzeit etwa über hundert Unterprogramme aufgerufen, diese wiederrum rufen globale Funktionen auf (z.B. Greifer öffnen, Greifer drehen, Steifigkeitsregler, usw...). Der Greifer am Robi darf auch nicht in einer x-beliebigen Bahn zurück zum Start, denn es fallen sonst die Teile aus dem "Werkstück" heraus. Deshalb das notwendige Fortsetzten des Programms...

Sollten noch einige Details benötigt werden- bitte einfach drauf los fragen!!

Ich bedanke mich schon mal im Voraus für die kreativen Lösungsansätze!!

LG Stups

Hallo,

danke erstmal für die Antworten!

Uwe: leider funktioniert das Ausmessen des Gewichts am Greifer nicht so, wie es sollte. Da sich bei uns Gewicht und Schwerpunkt der Last ständig ändern, wird es wohl noch ein bisschen dauern, bis ein "grammgenaues" Ausmessen funktionieren wird. Der Bediener sollte dabei auch nur über die Visu eingreifen müssen. Wir haben den LBR schon ausgiebig mit all seinen Möglichkeiten getestet... Sagen wir so- der LBR 4 ist in seiner Gesamtheit für solche Sachen noch zu labil. Der LBR 5 wird das anfang des nächsten Jahres wohl besser machen. Unser Transportgut ist leider extrem teuer, sodass wir mit den (oft nützlichen) Funktionen des LBR in der Produktion noch recht haushalten.

MaBo: das ist sicher eine interessante Variante, leider haben wir in den Anlagen, die wir bestücken, das Problem, dass oft nur ca. 3mm Platzreserve vorhanden ist. Manchmal muss sogar nach so einer Art "Labyrinth" hineingefahren werden- also vor-auf-vor-ab-links-ab-vor... -alles im mm-Bereich. Das ist ja genau das besagte Problem, das ich nach dem Unterbrechen eines Programms genau an der Unterbrechungsstelle fortfahren muss. Das mit dem "klappen" des Robis würde leider auch so nicht funktionieren, da unsere Transportboxen an einer Seite offen sind (nicht die obere Seite :-() und somit das Transportgut leicht herausrutschen könnte.

Stethi: das ist bisjetzt auch die einzige Lösung, die ich mir irgendwie vorstellen könnte. Nur woher weis das Unterprogramm, von welchem "Oberprogramm" es aufgerufen wurde? Leider sind bei uns die Programme recht verschachtelt
Ich spiele noch mit dem Gedanken, den Caller Stack zu beschreiben. Mal sehen was der Robi dann macht. Leider ist das ein Lösungsansatz, von dem jeder Roboterhersteller abrät- aus gutem Grund...

Für weitere Ansätze bin ich sehr dankbar!!!

LG Stups

Hallo Stethi,

danke- klingt vernünftig.
Leider sind unser Programme so aufgebaut, dass es kein Hauptprogramm gibt, sondern für jede Anlage bzw. für jeden "Teilbefehl" ein Programm. Diese wiederrum haben Bewegungssätze und rufen auch Standardprogramme mit ebenfalls Bewegungssätze auf. Wobei einige Positionen abhängig von der Base gerechnet werden und einige fix im Robcore definiert sind. Somit ist z.B. P1012 nicht immer gleich P1012.
Mit deiner Variante wäre es natürlich elegant zu lösen, nur müsste ich das komplette Roboterprogramm neu aufbauen und die Verschachtelungen bzw. Standardfunktionen neu anpassen. Ebenso wäre der Ablauf in der übergelagerten SPS neu zu implementieren- ebenso die Visu. Das alles mal x für x Roboter, die wir schon am laufen haben. Klingt jetzt ziehmlich nach Jammerei , ist aber wirklich ein enormer Aufwand, noch zudem für jeden Teilbereich andere Leute- auch externe und nicht mehr verfügbare Personen, verantwortlich waren.

Die einfachste Variante ist für mich derzeit noch das mit dem Abspeichern der Achswinkel bei Vorwärtsbewegungen und das Abspeichern des Callstacks bei Rückwärtsbewegungen. Nur leider sind KUKA z.Z. ziehmlich ausgelastet und das mit dem Caller Stack ($PRO_IP) ist für die leider auch noch keine Routine- Übung bzw. höre ich da ein gewisses Dagegen-Sein heraus .

Vielleicht gibts jemanden hier, der mit sowas schon Erfahrung sammeln konnte bzw. weiß, wie man den Callerstack "unfallfrei" beschreiben kann?

thx Stups

.