Status und Turn führt zu Softwareendschalter

Hallo,

ich habe ein Problem beim Erzeugen von Programmen für einen KR100-2 HA mit Software V24.3.1/KUKA5.5.

Wir fahren mit LIN-Bewegungen entlang von Punkten, die wir aus einem CAD-Programm heraus generieren lassen. Es handelt sich im Großen und Ganzen um eine "Hin- und Herbewegung", so daß ich davon ausgehe, daß die Rückbewegung grundsätzlich immer möglich sein müßte, wenn die Hinbewegung möglich war.

In der Nähe von Singularitäten tritt es dabei aber relativ häufig auf, daß die A4 sich sehr weit in eine Richtung verdreht. Dabei ändert sich der Turn-Wert von 'B101010' auf 'B010011', der Status-Wert bleibt bei 'B010'. Anschließend kann der Roboter sich auf dem Rückweg noch ein Stückchen weit bewegen, unterbricht aber dann mit der Meldung "Software-Endschalter A4". Das Ziel dieser Bewegung ist dann mit der Stellung, die der Roboter eingenommen hat, nicht mehr erreichbar.

Manchmal funktioniert es, eine PTP-Bewegung einzubauen und für den Zielpunkt den Status- und Turnwert so anzugeben, wie er vor der Umgebung der Singularität war. Der Roboterarm eiert zwar dann ganz seltsam durch die Luft, kommt aber aus der Sackgassenstellung wieder heraus. Heute hatte ich allerdings einen Fall, bei dem das nicht funktioniert hat. Dort ist der Roboter während der PTP-Bewegung stehengeblieben und hat ein Problem mit der A1 gemeldet. Dies kann ich gar nicht verstehen, da die A1 etwa auf 0 war.

Deshalb meine Frage: wie kann man solche "Sackgassenprobleme" zuverlässig vorhersagen? Nur mit KUKA.Sim? Oder gibt es andere Kriterien, an denen man festmachen kann, ob der Roboter in eine Stellung hineinfährt, aus der er nicht mehr herauskommt?

Und mindestens genauso wichtig: wie kann man das vermeiden? Gibt es Tricks, die starke Verdrehung der A4 zu vermeiden? Muß man dazu unbedingt PTP-Bewegungen fahren? Wir würden LIN-Bewegungen bevorzugen, da wir dann im CAD besser abschätzen können, wie die Bahn genau verlaufen wird.

Für jeden Hinweis bin ich sehr dankbar!

Viele Grüße,
Benjamin

Zitat von IrrerPolterer

Was für ein A1 Problem hat er denn gemeldet? Das kann jedenfalls nichts mit der Singularität zu tun haben.

Die Fehlermeldung lautet "Unerreichbarer Punkt Softwareendschalter +A1". Ich habe die Meldung nicht verstanden, aber für die anderen Teilnehmer hier scheint das ja ein Begriff zu sein.

Zitat von IrrerPolterer

Das Vermeiden solcher Probleme muss eigentlich schon in der Konstruktion berücksichtigt werden. Sprich die Position des Werkzeugs am Flansch sollte so angebracht sein, dass solche Verdrehungen nicht auftreten können.

Das klingt aber sehr kompliziert. Ich kann doch gar nicht wissen, wie ich das Werkzeug anders montieren soll, damit die Robotersteuerung keine solchen Aufwickelpfade berechnet, oder?

Zitat von Loelik

Hi,
wenn es möglich ist, würde ich aus dem LIN-Pinkten PTP rausmachen und die Funktion "kue_weg2" benutzen damit die S und T Werte berechnet werden.

Das klingt sehr spannend, aber ich bin mir nicht sicher, ob das klappt.

Ich habe mal folgendes probiert: die Positionen, an denen das Aufwickeln passiert, habe ich nicht mehr als POS über X, Y, Z, A, B, C vorgegeben, sondern als AXIS über A1 bis A6. Die Achswerte habe ich über unsere Software so berechnen lassen, daß dabei kein Turn-Wechsel auftritt. Vermutlich ist das Ergebnis dann dasselbe wie das, was kue_weg2 berechnen würde, oder? AXIS-Angaben kann man scheinbar leider nicht mit LIN-Bewegungen anfahren, also hab ich PTP-Bewegungen dafür genommen. Und tatsächlich findet das Aufwickeln nicht mehr statt. Die A4 dreht sich bei einer Bewegung relativ stark in eine Richtung, bei der nächsten Bewegung dreht sie sich aber wieder zurück, so daß die Stellung wieder die richtige ist.

Leider bewegt sich der TCP nicht mehr geradlinig, so wie bei den LIN-Bewegungen. Er "eiert" herum und zwar genau an einer Stelle, an der voraussichtlich ausschließlich geradlinige Bewegungen erlaubt wären (weil es sonst zu einer Kollision kommt).

Deshalb nochmals die Frage: wir würden gerne nur LIN-Bewegungen fahren. Einerseits, weil Freiheiten in der Bewegung zu Kollisionen führen könnten. Andererseits, weil wir PTP-Bewegungen (noch) nicht simulieren können. Muß man einfach einen Tod sterben? Also entweder mit LIN-Bewegungen aufwickeln oder mit PTP-Bewegungen gegen Kollisionen kämpfen? Oder gibt es noch eine andere Möglichkeit, ganz geradlinig zu fahren und trotzdem nicht aufzuwickeln?

Herzlichen Dank für die guten Antworten bisher und auch schon im Vorraus für diejenigen, die noch kommen.

Zitat von Loelik

Dann kannst Du Positionen als FRAME deklarieren (ohne S und T), dann sollte es auch funktionieren.
Aber mit Vorsicht benutzen, wenn Du später diesen Punkt als PTP anfahren solltest, kommt es zu einer unvorhersehbaren Roboterbewegung. Kollisionsgefahr!!!

Ich habe die Antwort nicht ganz verstanden. Wir haben bei unseren POS-Deklarationen keine S- und T-Werte angegeben, da diese bei LIN-Bewegungen ja sowieso ignoriert werden. Eine solche POS-Angabe ist doch dann nichts anderes als eine FRAME-Deklaration.

Jedenfalls habe ich gerade versucht, die Bahnpunkte für die LIN-Bewegungen als FRAME zu deklarieren, aber das Ergebnis ist genau dasselbe: es kommt zu dem Aufwickeln, wenn ich die Punkte mit LIN-Bewegungen abfahre. Oder wie hast du das gemeint...?

Zitat von Roland Keller

An den Roboterflansch einfach einen Adapter konstruieren der 30° oder 45° abgewinkelt ist und dein Werkzeug daran befestigen.
Das löst in den meisten Fällen das Problem, da die Achse 5 dann meist eingeknickt ist.

Gibt es so einen Adapter zu kaufen oder muß man da was selber basteln?

Zitat von [wEm

link=topic=11188.msg53609#msg53609 date=1363260881]
Das Aufwickeln bekommst du mit Bahnbewegungen (LIN/CIRC...) nicht in den Griff. Entweder Du stellst Konstruktiv mit Deinem Tool sicher, dass A5 nicht in die Nähe der singularität kommt (daher sind Schweißbrenner auch abgewinkelt), oder Du fährst PTP mit dem Beigeschmack, dass er im Achsraum linear, im Kartesischen Raum eine gekrümmte Bahn fährt.

Und kann man diese kartesische Krümmung der PTP-Bahn in den Griff bekommen? Zum Beispiel, indem man die Bewegung zwischen zwei Punkten durch ganz viele Zwischenpunkte definiert? Oder konzentriert man damit nur die Krümmung, so daß bei einem solchen Zwischenschritt eine ganz große "Ausweich"bewegung stattfindet?

Zitat von hustrac

Hallo,

Nochmal!

Bei LIN -Bewegungen muß die A5 (wenigstens leicht) abgewinkelt sein .
Ansonsten geht es nicht.

Alternativ gibt es bei der KRC2 (neuerer Softwarestand) und bei der KRC4 die Möglichkeit LIN-Punkte als sogenannte Hand-PTP abzuteachen,hier spielt die Handachsen Singularität keine Rolle. Der TCP bleibt auf der Bahn ,es kann sich nur die Orientierung des TCP während der Fahrt leicht ändern.

Alles anzeigen

Das klingt so ähnlich wie die Beschreibung von "$ORI_TYPE = #JOINT", die ich gerade in der Anleitung gefunden habe. Dazu steht hier "Während der Bahnbewegung wird die Orientierung des Werkzeugs kontinuierlich von der Anfangs- zur Endposition geändert. Dies geschieht durch lineare Überführung der Handachswinkel. Die Problematik der Handsingularität kann mit dieser Option vermieden werden, da keine Orientierungsführen durch Drehen und Schwenken um die Werkzeugstoßrichtung stattfindet."

Ist das dasselbe? Oder meintest du, daß man wirklich die Bahnpunkte teachen sollte?

Ich habe $ORI_TYPE = #JOINT mal ausprobiert. Da kam dann leider die Meldung "STOPP wegen Softwareendschalter +A3".

Zitat von hustrac

Bei LIN -Bewegungen muß die A5 (wenigstens leicht) abgewinkelt sein .

Heißt das, daß ich diese Art von Problemstellen immer daran erkennen kann, daß die A5 im Laufe der Bahn das Vorzeichen wechselt?