MOV/MXT Kommando - Raum- oder Werkzeugkoordinaten für a/b/c verwenden?

Kann ich dem MOV Kommando (oder einem anderen) sagen, dass die a/b/c Parameter sich nicht auf das Koordinatensystems der Hand beziehen, sondern auf die Weltkoordinaten?
In der Teachbox gibt's da ja zwei verschiedene JOG-Modi. Die suche ich im Melfa-Basic, und vor allem brauche ich das unbedingt im Realtime Protokoll. Auch da wird sich nicht sonderlich groß ausgelassen, auf welches Koordinatensystem sich diese Werte beziehen.

Merci -
Alex.

Um das Problem noch etwas konkreter zu beschreiben:
Ich versuche, die Ausrichtung der Hand (a/b/c) anhand von drei gegebenen Punkten im Raum zu bestimmen.
P1->P2 ist der Richtungsvektor, P3 bestimmt die Drehung um die Vektor-Achse:

P3
|
|
<Hand>P1============>P2

Ich kann jetzt die Winkel a/b/c um die Weltkoordinaten-Achsen damit bestimmen.

Aber der Roboter scheint a/b/c immer als Tool-Koordinaten zu interpretieren. Und das bedeutet, dass wenn ich die a-Achse drehe, die b-Achse nicht mehr parallel zur y-Achse liegt.

Im Handbuch steht, dass die a/b/c Parameter in der Reihenfolge c->b->a abgearbeitet werden, und man deshalb auf die Reihenfolge achten muss.

Bedeutet das, dass ich jetzt die Tool-Transformation auch noch rückwärts rechnen darf?

Schöner fände ich es, wenn man a/b/c _immer_ parallel zu den Weltkoordinaten angeben kann und der Roboter sich seine Rotations-Matrix daraus selber rausrechnet. Mit der Teachbox klappt das ja schliesslich auch.

Argl...

Alex.

OK, ich will das mal ein wenig weiter dokumentieren (Es handelt sich um einen 6-Achser). Folgendes Melfa-Basic Programm fährt eine geteachte Position an und verändert dann hintereinander unabhängig die Parameter a/b/c:

Servo OnOvrd 10''=====================' Veraenderung des a-Parameters'P1=(+400.00,+0.00,+400.00,-90.00,+90.00,-90.00,+0.00,+0.00)(7,0)Mov P1For i = -90 To -60 Step 1 P1.A = Rad(i) Mov P1Next i''=====================' Veraenderung des b-Parameters'P1=(+400.00,+0.00,+400.00,-90.00,+90.00,-90.00,+0.00,+0.00)(7,0)For i = -90 To -60 Step 1 P1.C = Rad(i) Mov P1Next i''=====================' Veraenderung des c-Parameters'P1=(+400.00,+0.00,+400.00,-90.00,+90.00,-90.00,+0.00,+0.00)(7,0)For i = 90 To 60 Step -1 P1.B = Rad(i) Mov P1Next i

Was passiert ist, dass bei der Änderung von a und c sich die Achse J6, die nach unten schaut, einmal rechts-herum ('a') und einmal links herum ('c') dreht.
Beide Parameter a und c sind hier also nicht linear unabhängig, das verwirrt mich ein wenig.
Die Variation des b-Parameters sorgt dafür, dass sich die Hand um die physikalische x-Achse dreht, wobei ja 'b' eigentlich der y-Achse zugeordnet ist.

Meine _Vermutung_ ist, dass das Tool-Koordinatensystem anhand von a/b/c rotiert wird, und zwar in der Reihenfolgen c->b->a, wie im Handbuch angegeben. Wobei aber jeweils das Tool-Koordinatensystem wieder als Ausgangspunkt für die einzelnen Rotationsschritte verwendet wird.

Und weil ich das ja schließlich alles in Realtime programmieren will, helfen mir die Melfa-Basic Tools nur soweit, das ganze zu verstehen.

Jaja, 3D-Matrizenrechnerei am Feiertag ist echt kein Spaß!

Aber ich werde berichten, was ich weiter herausfinde.

Alex.

Danke Hermann und Urmel für eure Infos. Sie decken sich mit dem, was ich inzwischen durch Reverse-Engineering rausgefunden habe.

Die 'Hin-Richtung', d.h. mit gegebenen a/b/c das Tool-Koordinatensystem auszurechnen, geht ja noch relativ einfach.

Aus einem geforderten Tool-Koordinatensystem die a/b/c rauszubekommen, war mein Ziel, und ich glaube jetzt zu wissen, wie es geht.

Ich habe es mit dem 'raumfesten Achsen' Ansatz gelöst. Wichtig dabei ist, erstmal zu wissen, wo die 0 Grad von a/b/c sind.
Es werden die Parameter a, b, c in dieser Reihenfolge abgearbeitet.
'a' dreht um die x-Achse, wobei 0 Grad die z-Achse ist.
Dann: 'b' dreht um die (Welt-)y-Achse, wobei 0 Grad ebenfalls die (Welt-)z-Achse ist.
Dann: 'c' dreht um die (Welt-)z-Achse, wobei 0 Grad die (Welt-)y-Achse ist.
Bei allen drei Parametern schaut man 'von aussen' in Richtung Ursprung auf die Achsen der Welt-Koordinaten.

Um zu einer gegebenen Soll-Orienterung des Tool-Koordinatensystems die a/b/c zu extrahieren, muss man die 3 Schritte rückwärts rechnen, d.h. erst c, dann b und dann a bestimmen, dabei immer das Tool-Koordinatensystem um den jeweiligen Parameter zurückrotieren.
Der 'c' Parameter ist dabei aber nicht einfach der Winkel zwischen den beiden z-Achsen, man muss bedenken, dass das auch einen Einfluss auf die folgenden Rotationen hat. Das bricht einem das Hirn!

In mathematischer Schreibweise sieht das immer ganz elegant aus. Muss man das programmieren, hat man es mit diversen Division/0 Problemen und wie schon erwähnt, Uneindeutigkeiten zu tun.

Interessant dabei war auch zu beobachten, dass die Stellungsmerker (flags1) eine entscheidende Rolle spielen:
In einem Fall, wo die a/b/c hübsch linear von Punkt zu Punkt interpoliert waren, hat sich die J4 + J6 Achse bei jedem Schritt einmal um 360 Grad gedreht, wobei es das garnicht gebraucht hätte. Nachdem ich flags1 von 7 auf 6 gesetzt hatte, war die Bewegung kontinuierlich.

Ich führe jetzt keine weiteren geometrischen Details aus, wen's interssiert kann mich gern kontaktieren.

Alex.