MoveC: Automatische Orientierung auf Mittelpunkt?

[MOSHzilla]

Ist es bei dem MoveC Befehl möglich, die Ausrichtung immer auf dem Kreismittelpunkt zu halten? Unabhängig von der Orientierung der Punkte des Kreisbogens

[Sven Weyer]

Automatisch denke ich einmal nicht, aber wenn Du die Positionen so teacht das diese Ausgerichtet sind auf den Mittelpunkt sollte das eigentlich auch gehen.

Gruß

Sven

[Z750]

schau mal nach der Instruktion "CirPathMode".
Vielleicht hilft dir das weiter.

Gruß Z

[MOSHzilla]

Das Problem ist, dass ich keine festen Punkte habe. Das Tool muss sich um ein Objekt zu bewegen, wofür ich variable Kugelkoordinaten bekomme.
Die XYZ-Koordinaten berechne ich mir dann hiernach -> http://de.wikipedia.org/wiki/Kugelkoordinaten
Mein Problem ist jetzt die Bestimmung der Ausrichtung für Ziel- und Hilfspunkt des Kreises. Habe mal probiert mit OrientZYX() die Rotation zu berechnen, nur damit stimmt die Ausrichtung nicht immer.

[Z750]

Wenn du nicht mit CircPathMode arbeitest, ergibt sich die orientierung des bogenpunktes standartmäßig durch Start- und Endpunkt . Ist ja für deine Anwendung auch richtig oder? 
Bekommst du dann für deine Berechnung 2 Winkel und beziehen die sich immer auf den exakten Mittelpunkt des Bauteils?

[MOSHzilla]

Wenn du nicht mit CircPathMode arbeitest, ergibt sich die orientierung des bogenpunktes standartmäßig durch Start- und Endpunkt . Ist ja für deine Anwendung auch richtig oder? 
Bekommst du dann für deine Berechnung 2 Winkel und beziehen die sich immer auf den exakten Mittelpunkt des Bauteils?

Ich bekomme ja 2 Winkel gegeben für den Zielpunkt, wie in dem Bild. Diese sind auch gleichzeitig die Ausrichtung des Punktes(Tools) zum Kugelmittelpunkt wenn ich mich nicht irre. Nur hab ich grade Probleme das auf die Ausrichtung des Zielpunktes zu übertragen

[Programmiersklave]

Wenn ich es machen müsste:
Ich würde mir den Ort des Zielpunktes relativ zum diesem Mittelpunkt ansehen. Und dann weiter mit DefFrame(...), wobei P1 der Zielpunkt selbst wäre, P2 der Mittelpunkt der Sphäre und P3 in einer sinnvollen Art senkrecht dazu gelegt wird (berechnet). DefFrame sollte dann direkt in der zurückgegebenen POSE.rot die Orientierung auf den Zielpunkt enthalten, die Position hat man ja schon.

Grüße,
Michael

[högi]

Hmmm,
könnte das nicht mit "MoveC RelTool (.....)" funktionieren?
Da kannst du doch alles eingeben was du brauchst.
Gruß
Högi
 

[MOSHzilla]

Wenn ich es machen müsste:
Ich würde mir den Ort des Zielpunktes relativ zum diesem Mittelpunkt ansehen. Und dann weiter mit DefFrame(...), wobei P1 der Zielpunkt selbst wäre, P2 der Mittelpunkt der Sphäre und P3 in einer sinnvollen Art senkrecht dazu gelegt wird (berechnet). DefFrame sollte dann direkt in der zurückgegebenen POSE.rot die Orientierung auf den Zielpunkt enthalten, die Position hat man ja schon.

Grüße,
Michael

Vielen Dank, so hat es geklappt, bzw. macht er schon annähernd das was er soll
Noch ein wenig Probleme mit der Berechnung des dritten Punktes, aber da muss ich einfach nochmal die Mathebücher aufschlagen
Und die Konfiguration macht mir zu schaffen, weil ich keine festen Punkte habe und die deswegen abstellen musste. Er fährt bei manchen Winkelkombinationen an die Achsgrenzen

[Programmiersklave]

Der dritte Punkt muss ja nur die Drehung um den Strahl fixieren, wo er genau in der Ebene liegt, ist egal. Im einfachsten Fall nimmt man die Koordinaten des P1 und zieht in Welt in Z 100 mm ab, dann hätte man das Werkzeug in dieser Richtung stets parallel zum Roboter. (Anschließende Drehungen um 90° sollten kein Problem sein). Alternativ könnte man auch einen festen Punkt verwenden, der irgendwo über dem Ganzen liegt, auf halbem Wege zwischen Arbeitsbereich und Roboter. Mit etwas Glück und intelligent gewählter Höhe löst diese Anordnung dann vielleicht auch das Problem mit den Achsgrenzen, da das Tool dann nicht starr im Raum liegt, sondern sich um die Zeigerichtung dreht.
Wenn die Drehung um die Stoßrichtung /Zeigerichtung des Werkzeugs nicht egal sein darf, dann ist das natürlich ein Hindernis...

Das mit den Achsgrenzen wird schon etwas schwieriger. Wenn man den Aufwand nicht scheut, könnte man die Bahn virtuell segmentieren, und dann mit CalcJointT gucken, welche Achswinkel an den einzelnen Punkten entstehen. Bei der Berechnung erzeugt der ABB automatisch einen Fehler, wenn das zurückgegebene Jointtarget unmöglich ist. Diesen Fehler kann man in der Fehlerbehandlung abfangen und dann irgendwas Alternatives versuchen, ich benutze das gelegentlich so, allerdings nicht für Kreisbahnen.

Grüße,
Michael