Beiträge von Robin / Robout

fubini
Danke für den Link!
Würde ich auch genau so übersetzen.

Habe die Beschreibung von Inverse() und Forward() jetzt in der "KUKA System Software 8.7" ab Seite 676 ausfindig gemacht. Die PDF gibts wie du sagst im Kuka MyExpert Portal unter Bedien- und Programmieranleitungen - Suchbegriff "KUKA System Software".

Da ich die die Funktion Forward() als "Diagnose" in mein Programm einbinden will frage ich mich ob mir die Variable err_status auch eine 1 rausgeben würde ( Verletzung Softwareendschalter ) wenn die Achse 4 und Achse 6 weiterhin endlosdrehend eingestellt wären. Sprich wenn die sozusagen >360 bzw. <-360 drehen.
Wohl eher nicht oder ?

Beziehungsweise falls ich die Achse 4 und Achse 6 wieder beschränke...
Wäre es ratsam aus meiner E6AXIS Rückzugsposition mittels Inverse eine E6POS zu berechnen und für den Fall, dass err_status = 1 (SWES Verletzung) meldet "von Hand" den Turn der Achse 4 bzw. Achse 6 anzupassen ?

Also z.B. aus Turn = 35 = "100011"
den Turn = 34 = "100010"
zu basteln ? Gibt es da eventuell eine Funktion die einem das unter Angabe der Achse umrechnet beziehungweise den Turn einer Achse invertiert ?

Zitat von fubini

Eher nein. Ob die Achse links oder rechts rum dreht hat nichts mit dem Status zu tun, sondern ist erstmal ein Turnproblem, d.h. in deinem Problemfall müsstest du das Turnbit für die Problemachse flippen. Nachdem der Turn aber für endlos drehende Achsen keine Bedeutung hat muss du auf alle Fälle erstmal das "endlos drehend" wieder abstellen. Danach kannst du über INVERSE und durch Vorgabe von Status und verschiedenen Turns dir denjenigen Achswinkel raussuchen den du haben willst und dann entsprechend die kartesische Position für den SPTP kommandieren.

Fubini

Hallo Fubini,

danke für den Tipp. Mir gefällt das mit den endlos drehenden Achsen sowieso nicht so wirklich..
Hast du eine Beschreibung zu den Funktionen Forward/Inverse() ? Habe schon in anderen Themen danach gesucht, aber habe keine aktuelle Verlinkung dazu mehr gefunden.

Zitat von Der_Robonaut

Vieleicht hilft es Dir die Achse 6 über Einzelachsbewegung vorzupositionierren:

Z.B.:

PTP {A6 90}

Oder in einer Schleife in mehreren Schritten...

Repeat

E6AXIS.A6 = E6AXIS.A6 - 10

PTP E6AXIS

Until E6AXIS < XY

Eine einfache mechanische Lösung wäre eine schräge Adapterplatte zwischen Roboterflansch und Werkzeug. So bekommst Du dein Singularitätsproblem weg...

Alles anzeigen

Ja die Adapterplatte gibt es sogar schon.. man ist hier nur etwas "gutmütig" rangegangen und hat Sie erstmal weggelassen. Danke für den Hinweis.
Und eine Schleife haben wir bereits drin.. die war nur etwas "unschön" weil Sie den eigentlich Prozess irgendwo etwas verlangsamt.

Zitat von SJX

Gibt es einen speziellen Grund, wieso keine 4 (5)-Achsen-Palettiermechanik hier verwendet wird ?

Palettiermodus würde Dir exakt die Vorteile so einer Mechanik bieten.

Meistens erreichst Du damit auch eine schnellere Zykluszeit, weil Du mehr PTP Bewegungen fahren kannst und eben das gegenseitige Verdrehen Achse 4 / 6 nicht mehr hast.

Würde darum auch Dein Programm sehr vereinfachen. (z.B. Positionen nur noch als Frame handeln)

Ich kann es mir momentan noch nicht genau vorstellen...
Wenn bei der Fahrt nahe der Singularität ab sofort nur noch Achse drehen sollte, dann würde das doch bedeuten, dass das Tool stark vor- und zurück rotieren würde ? Und wenn nun die A6 ständig am drehen ist, dann komme ich doch genau so in Situationen rein bei der nach einer PTP Fahrt auf ein 360°-Modulo Wert statt auf den "Urpsrungswert" gefahren wird, oder sehe ich hier etwas falsch ? Bedeutet $PAL_MODE vorneweg einfach "gemindertes" Drehverhalten ?

Mich beschäftigt momentan die Frage ob ich bei der Systemvariablen $TARGET_STATUS von #SOURCE auf #BEST potentiell den Fehler wegbekomme. Alternativ würde mich auch interessieren ob ich bei dem Befehl

e6zielpos = FORWARD(axis, err_status)

irgendwo "einbringen" kann dass er sich nicht über den Modulo 360° drehen soll für die berechnete Position.. irgendwo hatte ich gelesen dass err_status IN/OUT Parameter ist.. also Hoffnung wenn ich da z.B. err_status = 2 setze, dass mir das Programm den für mich "richtigen" Turn ausgibt ? Oder welche Variable wird hier ausgegeben falls so ein Modulo Sprung auftritt (Software Endschalter A4 A6 sind ja deaktiviert durch "endlosdrehen".

Zitat von fubini

Nich das Tool sondern der Flansch! Kannst dann eigentlich nicht mehr in die Singularität kommen.

Hallo Fubini,

Danke für deinen Hinweis!
Jetzt ist bei uns das Anlagenlayout tatsächlich knallhart so, dass der Roboter (6-Achs KUKA KR3900 Ultra irgendwas..) auf ner relativ hohen Konsole steht und etwa darunter die Palette liegt, dass der beim Absetzen vorne "überbeugt" und dann eben bei Parallelität von Flansch und Paletten-BASE die Achse 4 und A6 ziemlich genau übereinander liegen Ist eben ein altes vom Kunden so "übernommenes" Layout

Also Singularität bekomme ich nur schwer weg. Macht uns auch erstmal nichts aus solange das Verhalten danach in den Griff zu bekommen wär

Die Variable $Pal_Mode ist mir erstmal neu!

Laut KUKA-Beschreibung:

Zitat

In the case of palletizing robots with 6 axes, palletizing mode is deactivated

by default and must be activated. If palletizing mode is active, axis A4

may be locked at 0° and the mounting flange is held parallel to the floor by

keeping A5 at a suitable angle. For a 6-axis robot, active palletizing mode

is deactivated again after a cold restart of the robot controller.

Also wenn das Tool parallel zum "Floor" gehalten wird und die Achse 4 eventuell "gelockt" wird, dann heisst das für mich die A6 muss noch mehr "Ausgleicharbeit" in der Singularität leisten. Aber würde ich auch mal ausprobieren wollen...

Also Lösungsideen bisher:
- $TARGET_STATUS = #BEST (statt Default mässig #SOURCE)

- Spielen mit den Befehlen FORWARD()/INVERSE(), in etwa sowas wie:

E6POS e6pos_ziel
E6AXIS e6axis_zwischenpos ;die ist quasi im Vorfeld geteacht
FRAME vorpos_setzen       ;die ist berechnet als Frame 
INT err_status


 e6pos_ziel= FORWARD(e6axis_zwischenpos, vorpos_setzen, err_status)


IF (err_status == 0) THEN
 SPTP e6pos_ziel

ENDIF

mit der Erwartung, dass mir die Berechnung mittels FORWARD auch den "gewünschten" Status und Turn ausspuckt, der für alle berechneten vorpos_setzen (sind ja variabel) zum "selben" Rückdrehen führen würde.

- oder eben $PAL_MODE = TRUE


Was könnte hier am zielführendsten/elegantesten sein ?
Das Problem ist wie gesagt das Drehverhalten nach dem Setzen nach der Fahrt auf die Vorpos zurück (genaugenommen die unvorhersehbare Drehung auf die Zwischenposition) - Also nicht die Singularität als solches...

Gruss,

Robin

Hallo Community,

ich habe ein Problem bei einer Palettieranwendung. Und zwar kommt es vor dass der Roboter bei einer PTP Fahrt auf eine E6AXIS manchmal ein "ungewolltes" Drehverhalten zeigt. Genauer gesagt beim Fahren auf die "Zwischen-Position" nach den Absetzvorgängen (etwa bei Absetzvorgang 4-10). Schematisch ist das Programm wie folgt aufgebaut:

E6POS zwischenpos_setzen
E6AXIS mk_zwischenpos_setzen


PTP zwischenpos_setzen
mk_zwischenpos_setzen = $AXIS_ACT  ; merken für spätere Rückfahrt

PTP vorpos_setzen           ; z-Offsetz über der Endposition
LIN endpos_setzen

setzen()

LIN vorpos_setzen           ; lediglich wieder Hochfahren über die Endposition

PTP mk_zwischenpos_setzen       
; gewolltes Zurückfahren in "invertierter Drehrichtung der Achsen 4,6

Bei dem letzten Fahrbefehl bekomme ich manchmal ungewollte Drehungen... dabei möchte ich im Prinzip genau umgekehrtes Drehverhalten wie bei der Fahrt PTP vorpos_setzen
Bin etwas perplex dass da überhaupt Status und Turn bei PTP E6AXIS ne Rolle spielen ? Achse 4 und Achse 6 sind bei dem Roboter endlos drehend eingestellt weil wir starke Singularitätsprobleme bei dem Anlagenlayout hatten.
Kann es denn vorkommen das bei der PTP E6AXIS statt auf A4 = 20° einfach auf A4 = -340° gefahren wird ?
Lässt sich das mit der Variable $TARGET_STATUS irgendwie zu 100% beheben oder sicherstellen ? Oder was sollte ich da tun, dass der Roboter immer auf eine "gleiche" Zwischenposition zurückfährt. Oder mache ich hier eventuell einen Gedankenfehler an ganz anderer Stelle (weil ich selbst fast nicht glaube dass PTP E6AXIS sich so merkwürdig verhält... ?)

Gruss,

Robin

Zitat von Robin / Robout

Setzpos_x1 = {x Setzpos.X, y Setzpos.Y, z Setzpos.Z, 0, 0, 0} : {0, 0, 0, a Korr.A, b Korr.B, c Korr.C}

Setzpos_x2 = Setzpos_x1 : {0, 0, 0, a Setzpos.A, b Setzpos.B, c Setzpos.C}

LIN Setzpos_x2

Habe ich gar nicht mehr getestet.. (führt evtl. auch zum Ziel)

Um das vorherige Wirr-Warr etwas aufzuklären:
Also was ich wollte ist die Drehung des Tools (TCP) gemäß den Winkeln der aktuellen Base..

Bin jetzt zum Ziel gekommen:

mk_setzpos = setzpos
setzpos = winkelkorrektur:setzpos
setzpos.x = mk_setzpos.x
setzpos.y = mk_setzpos.y
setzpos.z = mk_setzpos.z

der geometrische Operator auf der linken Seite führt zum Ziel!! Denn der dreht das Frame gemäss den Base Koordinatenachsen so wie ich das möchte.. Musste jedoch beachten, dass dabei die Translationen der Setzpositionen entsprechend manipuliert werden. Deshalb hier in Zeile 3-5 nochmal das rücksetzen auf die alten Translationswerte..

Grüsse,

Robin

Zitat von Programmiersklave

Ich versteh das Problem immer noch nicht, glaube ich.

- Der Bediener hat ein Koordinatensystem im Kopp, um das er drehen möchte. Dies ist zwar in der Position richtig, aber nicht in der Orientierung, denn im Kopp des Bedieners ist es global?

- Der Bediener möchte das anpassen, aber eben nicht toolbezogen? Toolbezogen wäre aber nötig, um Greiferfehler auszugleichen. Aber egal, er will das global ausgleichen?

Man rechne also die Korrektur darauf, wo man sie haben möchte. Angenommen, man wolle sie gegen die Vernunft jetzt tatsächlich "global" ausgleichen, dann rechnet man eben in mehreren Schritten und macht Lage und Orientierung unabhängig voneinander und schiebt die Korrektur dazwischen:

{xpos,ypos,zpos,0,0,0}: //Position (ohne Orientierung) im Base

{0,0,0,akorr,bkorr,ckorr}: // globale Winkelkorrektur

{0,0,0,apos,bpos,cpos} //und hier dann die Orientierung des Zielpunktes hinten drauf auf die Korrektur.

Wenn man dann noch jedes Zwischenergebnis in eine eigene Variable sichert und nicht nur, weil es cool ist, in einer Zeile rechnet, dann sieht man step by step, was man da macht und kann sogar probehalber hinfahren.

Oder was?

Alles anzeigen

Hallo Programmiersklave,

ja im Prinzip hast du Recht mit deiner Beschreibung: ich möchte um den TCP drehen aber eben in dem Koordinatensystem der Base. Das ist nämlich das was der Bediener noch halbwegs verstehen kann. Ich kann ihm nicht erklären, dass das TCP mal so und mal so orientiert ist für unterschiedliche Setzpositionen mit verschiedenen Winkelwerten.
Es wurden ja jetzt 2 Vorschläge genannt die ich sobald ich kann mal testen werde letzterer wäre ja dann auch dein Vorschlag (nur nicht so ausführlich), nämlich dass ich Hilfs-Frames bastle.

Stelle ich mir momentan so vor:

Setzpos_x1 = {x Setzpos.X, y Setzpos.Y, z Setzpos.Z, 0, 0, 0} : {0, 0, 0, a Korr.A, b Korr.B, c Korr.C}

Setzpos_x2 = Setzpos_x1 : {0, 0, 0, a Setzpos.A, b Setzpos.B, c Setzpos.C}

LIN Setzpos_x2

Für Setpos_x1 werden die Drehungen auch in der "richtigen" Orientierung ausgeführt weil ich das $Tool so angelegt habe dass es für 0-Winkelorientierung genau zur Base orientiert ist...
Und die beiden geom. Operatoren verstehe ich momentan als zwei "hintereinander" ausgeführte Drehungen und sind nich gleichzusetzen mit einer Addition der Werte oder ?
Also nicht:
Setzpos_x2 = {x Setzpos.X, y Setzpos.Y, z Setzpos.Z, a Setzpos.A+Korr.A, b Setzpos.B+Korr.B, c Setzpos.C+Korr.C}

Oder wie bei den anderen Kommentaren angedeutet (also mittels geom. Op auf der linken Seite oder ansatzweise die Idee mit der Vektorberechnung aber da muss ja noch ein Zwischenschritt passieren. Danke schonmal jedenfalls ich glaube ich komme zum Ziel

Zitat von Hermann

LIn_rel ist ja schön und gut, aber da muss der Roboter schon auf der Position stehen. Wenn man jetzt die Anfahrposition VOR dem Zielpunkt anpassen will, dann steht man da im kurzen Hemd.

Da muss man selber rechnen. sowas wie (halber Pseudocode)

Code

; Verschieben des Punkts in den Ursprung des Base
frame1=xOriginal
frame1.x=0
frame1.y=0
frame1.z=0
; Drehung um Z im TCP bezogen auf Base, hier 45 Grad
XZiel={x 0, y 0, z 0, a 45,b 0, c 0}:frame1 
; wieder zurueckschieben
XZiel.x=xOriginal.x
XZiel.y=xOriginal.y
XZiel.z=xOriginal.z

Alles anzeigen

Hallo Herrmann,

ja ist ein 6-Achsroboter aber geht um eine Palettieranwendung. Das werde ich mal testen indem ich "kurz" die Translationen "wegblende".

Zitat von Der_Robonaut

Und wie das Tool in Bezug zur Base orientiert ist kannst Du doch an der Teachposition selbst erkennen. Die Teachposition bezieht sich ja auf die Base.

Anbei ein Beispiel aus einem Palettierprgramm bei dem der Ursprung der Base gleichzeitig Platz 1 der Palette ist.

Pos 1,2 und 6 sind um 179° in A verdreht zur Base.

;Greifpositionen

DECL POS Mag_2_GP[80]

Mag_2_GP[1]={X 0.0,Y 0.0,Z -7.93154764,A 179.193024,B 0.0,C 0.0,S 2,T 10}

Mag_2_GP[2]={X 60.0000,Y 0.0,Z -7.95628166,A 179.193024,B 0.0,C 0.0,S 2,T 10}

Mag_2_GP[3]={X 120.000,Y 0.0,Z -7.98100,A 0.193028510,B 0.0,C 0.0,S 2,T 10}

Mag_2_GP[4]={X 180.000,Y 0.0,Z -8.00573444,A 0.193028510,B 0.0,C 0.0,S 2,T 10}

Mag_2_GP[5]={X 240.000,Y 0.0,Z -8.03046799,A 0.193028510,B 0.0,C 0.0,S 2,T 10}

Mag_2_GP[6]={X 0.0,Y 60.0000,Z -7.92012262,A 179.193024,B 0.0,C 0.0,S 2,T 10}

Alles anzeigen

Natürlich habe ich schon probiert hier kleine Winkeloffsets auf A,B,C draufzurechnen, aber das ist ja mein Problem. Geht nicht.
Manchmal dreht er statt um a um c und das auch stark abhängig von der Winkelorientierung.

Ich fahre eben auch auf FRAME und nicht auf E6POS

Bei den E6POS würde sich ja der Turn ändern je nachdem ob da bei A mal 90° oder zum Beispiel -90° und das ist bei dieser Palettieranwendung eben sehr flexibel

Beim Anfahren meiner Setzpos bin ich natürlich mal hingeganen und hab mir den $Pos_Act Frame mal abgegriffen wenn der Rob die Posi erreicht. Und da gilt eben Setzpos != M_Pos_Act

Zitat von Der_Robonaut

Wie Fubini schon gesagt hat: Dann dreh um.

Drehung um Toolkoordinatensystem:

PTP Setzpos:{x 0, y 0, z 0, a 2, b 0, c 0}

Drehung um Basekoordinatensystem:

PTP {x 0, y 0, z 0, a 2, b 0, c 0}:Setzpos

Alles anzeigen

Das probier ich mal wenn ich wieder dran bin, ich befürchte aber da wird die x,y,z Translationen der Setzpos dann aber in die um a = 2° gedrehten Koordinatenachsen zeigen... Zumindest wenn man der KUKA Abbildung des geom. Operators glaubt.

Hallo,

komme wschl. erst nächste Woche wieder ans System (steht beim Kunden) werde dann ein paar Sachen ausprobieren.

$ROTSYS - "Rotationsbezugssystem bei Relativsätzen im Vorlauf"
Hört sich sehr vielversprechend an... wäre das idealerweise dann:

$ROTSYS = #BASE

damit der Geometrische Operator (siehe mein Beispiel oben) dann um die Base Winkel dreht ?

und die Einstellung

$ROTSYS = #TOOL

so wie ich das momentan als Drehung um das Tool-Koordinatensystem beobachte ?

Oder bezieht sich $ROTSYS leider nur auf Befehle wie LIN_REL oder sonstiges...? Wäre jedenfalls ein Traum wenn ich damit den geometrischen Operator wahlweise auf $Base / $Tool beziehen kann.

Gruss,

Robin

Hallo Fubini,

nach der Beschreibung von KUKA würde ich dann aber bei den Translationen in Setzpos1 (x,y,z) dann auch die Achsen x,y,z rotieren. Ich will aber das Tool in der Setzpositionen um die a,b,c gemäß der Grundbase Orientierung drehen, oder ?

Gruss,

Robin

Hallo Tobbyash,

Also die Base bleibt im Prinzip die ganze Zeit an der Kante der Palette...
Kann das Problem gerne noch etwas näher schildern...
Also ich bekomme die Setzpositionen in Form von x,y,z,a,b,c von dem externen System... (Frame)
Welches ich dann mittels PTP Fahrbefehl anfahre. Ist auch alles gut soweit...
Das merkwürdige passiert dann wenn ich zum Beispiel hingehe und die Winkel leicht korrigieren möchte...
Also statt z.B. Setzpos1 = {x 100 , y 100 ,z 250 , a 0, b 90, c 0)

das Frame Setzpos1_korr = = {x 100 , y 100 ,z 250 , a 2, b 90, c 0)

anfahre.. mit der Intention den Greifer leicht um +2° in a Winkelrichtung (gemäß Base) zu korrigieren.

Tut es eben nicht... woraufhin ich hingegangen bin und das per geometrischem Operator hinkriegen wollte. Nämlich:

PTP Setzpos1 : {x 0, y 0, z 0, a 2, b 0, c 0}

Da ist aber auch eine Varianz drin in Abhängigkeit von den a,b,c Winkeln der Setzpos1, beziehungsweise eben von der Stellung des Tools in Bezug zur Base. Also wenn ich z.b. wüsste dass die x-Koordinate des Tools in z-Richtung der Base schaut, dann könnte ich hingehen und den Korrekturwert um den Winkel a der Base im Operator an die Stelle c schreiben, sprich:

PTP Setzpos1 : {x 0, y 0, z 0, a 0, b 0, c 2}

Nach meinem jetzigen Verständnis dreht der geometrische Operator das Tool nicht um die Base sondern um das eigene $Tool System wenn ich das so pauschal sagen kann ? Bräuchte aber die Drehung um die Base
Ist eine Anwendung bei der sich die Winkel oft ändern beim Setzen.

Danke für den Hinweis zu dem Relativbefehl (da müsste ich dann ja die Tool Orientierung konstant halten, was ich eventuell vermeiden wollte)
Das mit der Vektorabfrage kann ich eventuell an anderer Stelle gebrauchen(!?)

Gruss,

Robin

Hallo,

für einen Palettierroboter möchte ich eine Art "Nachkorrigieren" von Setzpositionen realisieren.
Heisst so viel wie: der Roboter bekommt seine Palettierpositionen von einem externen System (in idealer Hinsicht) fertig bereitgestellt.
Nun soll man aber die Möglichkeit zum "Feinkorrigieren" von Winkeln bekommen in Folge eines leichten "Verzugs" des Greifer oder Ähnlichem. Sprich ich möchte auf die ideale Position noch allgemein ein Winkel von z.B. 0,5° für A,B,C "dazumachen".

Da habe ich dann mittels geometrischem Operator etwas programmiert das folgendermaßen aussieht:

PTP XSetzposition : Winkelkorrekturen

Das funktioniert aber nicht so wie ich mir das vorgestellt hatte, da die Winkel a,b,c im Operator nicht den Winkeln a,b,c des Basesystems entsprechen (in dem ich als Bediener "denke")
Es kommt hinzu: wenn sich Setzpositionen grundlegend in ihren Winkeln ändern, habe ich auch eine andere "Orientierung des Tools bezüglich zur Base" und die Winkelkorrekturen A,B,C (die man in Bezug zur Base erwartet) sind dann nochmals anders.

D.h. ich wäre im Prinzip an einer "allgemeingültigen Orientierung des Tools in Bezug zur $Base in Abhängigkeit der anzufahrenden Setzposition" interessiert. Mir fällt es gerade sehr schwer eine solche Beziehung aus den $Tool Winkeln und den Winkeln der Fahrposition herzuleiten. Denke ich da zu kompliziert und sollte da einfacher rangehen ? Oder gibt es eine Kuka Systemvariable die mir die Orientierung des Tools in Bezug zur Base verrät ?

Eine kleine Hilfestellung begrüsse ich sehr.

Viele Grüsse,

Robin

Wir hatten auch ein paar Einrichtungsschwierigkeiten zur Fernwartung. Wie weiter oben beschrieben musste unsere Profinet/Profisafe IP auf die gleiche IP gelegt werden wie das "Public Network/ Öffentliches Netzwerk" und auf den WAN Port.
Das alleine reichte jedoch noch nicht aus um auf die Steuerung über Netzwerk zugreifen zu können ...
Ich musste mich nochmals (mithilfe des Service-Ports) mit der Steuerung verbinden und links im "Browser" Fenster mittels Rechtsklick auf die aktive Steuerung unter "Netzwerk Einstellungen" erneut die IP zuweisen.
Dabei ging komischerweise im ABB Projekt die IP Idresse des Profinets verloren ( die hat sich automatisch auf 0.0.0.0) gesetzt. Das könnte auch ein Bug in meiner RobotStudio Version gewesen sein (Version 21.2.9526.0)
Nach erneutem Zuweisen der IP des Profinets und einem Neustart der Steuerung gab es dann nur noch eine kleine Hürde zu meistern
Jetzt muss man nämlich noch einmal in dem Menü "Steuerung Hinzufügen" die IP Adresse "Hinzufügen". Dort ist die deutsche Übersetzung "Steuerung in anderem Subnet" etwas entartet. Das Feld darunter dient nämlich auch eben zum Hinzufügen der "eigentlichen" IP.
Danach konnte ich problemlos (auch von verschiedenen PCs aus) über Netzwerk oder auch Fernwartungsrouter zugreifen.

Grüße,

Robin