Beiträge von EricH

    Die Verrechnung passiert nun in Eulerischne Winkeln und wird dann in Quotienten umgerechnet.

    Laut Doku sollt die Berechnung um den Drehpunkt des Wenders drehen aber in einem Grenzbereich um 0.5, 0.5, -0.5, 0.5 habe ich dann Sprünge von 0°,-90,90 auf -90°, -90°, -180° und meine Berechnung funktioniert nicht mehr richtig. gehe ich auf z.B. 0°, -91°, 91° Funktioniert alles wie es soll.


    nur sagen wir um ca. 0,5° um diese Sonderstelle nicht.

    Meinst du Quaternionen? Was für Quotienten? Check mal hier: https://quaternions.online/


    Da kannst du sehen, dass beide Euler-Orientierungen exakt gleich sind, die du hier beschrieben hast. Deswegen werden auch Quaternionen verwendet um solche Sprünge zu vermeiden.

    Nun, da es Euler-Winkel sind, können die bei Abweichungen gerne mal springen.


    Mit welcher Methode hast du vermessen?


    Zur zweiten Frage: Ich würde mal vermuten, das kannst du einstellen um was du drehst. Aus den Punkten deiner Bilder kann man nicht die Relation zur Wendeachse erkennen.


    Die Wendeachse selbst ist um Z laut dem Bild. Rein von der Logik her sollte also um die Achse dann alles drehen, was an der Achse mitfährt.

    Ich glaub', da gibts Sachen, die Du auch für Geld gar nicht kennen willst. Ich hatte seinerzeit eine der letzten KRC2 mit einem beim Rüsten ankoppelbaren(!) A6-Übersetzungsgetriebe 1:5, aber synchron, sowohl an- als auch abgekoppelt. Da haste schon wieder vergessen wie das geht, bevor die Anlage abgenommen ist.

    Ja kommt immer auf die Anforderungen an, wenn es koppelbar sein soll, wirds nochmal interessanter.

    Es ist natürlich immer eine gewisse Prise Vernunft ganz gut.

    Theta ist der Winkel, welcher in der Rotationsmatrix eingegeben wird. Also in dem Fall die Drehung um die Achse der Rotationsmatrix.


    Dieses RU ist eine spezielle Rotation um eine benutzerdefinierte Achse. Hat mit deinem Problem eigentlich nix zu tun.


    Nochmal zum Verständis, die 3 Rotationsmatrizen sind jeweils für die Rotation einmal um X, einmal um Y und einmal um Z. Du willst ja die Berechnung Rückwärts. Also nach Theta auflösen.

    Also ich gehe mal davon aus, dass Stäubli ZYX Euler-Winkel hat. Falls das nicht der Fall ist, gilt diese Lösung nicht.


    Erstmal müsstest du für deinen Vektor festlegen, welche Achse des Koordinatensystems dieser repräsentieren soll (meistens Z). Den normalisierst du, dann brauchst du noch 2 Vektoren die X und Y repräsentieren, entweder wählst du die frei( beachte dass diese nach rechter Hand-Regel gewählt werden) oder legst einen fest, woraus sich der andere automatisch berechnet.


    Jetzt hast du ein Koordinatensystem mit 3 Einheitsvektoren. Diese bilden eine 3x3 Matrix (X,Y,Z) = R.


    Die Winkel berechnen sich nun folgendermaßen:



    Z-Winkel = arctan2(R21,R11)

    Y-Winkel = arcsin(-R31)

    X-Winkel = arctan2(R32,R33)

    Was du willst sind Rotationsmatrizen in diesem Fall. Damit kannst du das Problem lösen. Natürlich musst du dann nach den Winkeln auflösen. Die Formeln hab ich bei mir rumliegen, kann ich dir bei Gelegenheit mal hier posten.

    Da gibts eine Instruktion:

    ReadCfgData - Reads attribute of a system parameter


    Möglich ist auch das schreiben von System-Parametern.Traglast ist allerdings an zwei Stellen definiert. Einmal im Programm für Traglasten auf der 6. Achse und dann die Armlasten der restlichen Achsen in den Parametern.

    Also als halber Informatiker kann ich sagen, dass Roboguide schon ziemlich auf altbackenen Strukturen steht. Dass da Probleme mit Microsoft entstehen muss zwangsläufig passieren, da Microsoft nicht auf Rückwärtskompabilität klarkommt. FANUC müsste hier seine ganzen Funktionalitäten auf ein höheres Framework umsatteln und ich glaube der Aufwand lohnt sich aktuell nicht.

    Ist bei FANUC ein bekanntes Thema. Es muss vorher Revision T drauf. Dann kann eine neuere drüber. Fehlermeldungen kommen trotzdem, aber zumindest lässt sich das Programm dann starten.


    Komischerweise wird Rev T nicht gleich mit rausgegeben :/