Beiträge von fubini

    Hallo Damson,


    die Basenamen stehen doch in der $config.dat unter
    DECL CHAR BASE_NAME[32,24]
    BASE_NAME[1,]="Flansch_an_R2"
    BASE_NAME[2,]=" "
    BASE_NAME[3,]=" "
    BASE_NAME[4,]=" "
    BASE_NAME[5,]=" "
    ...


    Insbesondere kannst du also den Basenamen direkt in KRL lesen. Somit könntest du doch einfach deinen String der Reihe nach gegen die in BASE_NAME[,] vergleichen (siehe StrComp). Die gesuchte Basenummer ist dann einfach der BASE_NAME[]-Index bei dem der Vergleich nicht schief geht.


    Fubini

    Hallo RainerH,


    für Verschiebungen sollte man immer den Doppelpunktoperator ":" (manchmal auch geometrischer Operator genannt) verwenden. Sonst wirds spätestens wenn noch Orientierungen dazu kommen nicht mehr richtig. Aber das nur am Rande. Zu deinem eigentlichen Problem: Ist der Roboter sauber justiert?


    Fubini

    Hallo,


    zur Orientierungsführung über Drehen und Schwenken:
    angenommen das Roboterforum macht eine gemeinsame virtuelle Flugreise von "München" nach "New York", dann entspricht "München" der Startorientierung und "New York" der Zielorientierung. Auf einer 2 dimensionalen Weltkarte kann man das auch über die beiden Werte für Längen- und Breitengrad ausdrücken, d.h. man muss Startlängengrad und Startbreitengrad bei München in Ziellängengrad und Zielbreitengrad bei New York überführen. Insbesondere braucht es nur zwei Freiheitsgrade um die Orientierungen ineinander überzuführen.


    Geht man dann wieder ins dreidimensionale dann wird aus der Weltkarte ein Globus und Start sowie Zielorientierung sind einfach Punkte auf der Kugeloberfläche. Alle möglichen anderen Orientierungen liegen dann auch wieder auf der Kugeloberfläche. Stellt man sich nun vor man zeigt mit dem Finger auf "München", dann ist die Frage wie muss ich den Globus unter meinem Finger wegdrehen um auf "New York" zu zeigen. Insbesondere kann mann dann die notwendige Änderung im "Breitengrad" als "Schwenken" bezeichnen und die Änderung im "Längengrad" als "Drehen".


    Jetzt ist noch die Frage wo spukt hier die ausgezeichnte Werkzeugstossrichtung "x" rein. Das ist aber auch ganz einfach, dass ist nämlich die Verbindungsgerade von einem "Ort" auf der Kugeloberfläche zum Kugelmittelpunkt. Hält man dann gedanklich die Verbindungsgerade im Kugelmittelpunkt fest, dann entspricht eine Bewegung der Verbindungsgeraden auf der Kugeloberfläche entlang eines Längengrads gerade dem "Drehen" und eine Bewegung der Verbindungsgeraden auf der Kugeloberfläche entlang eines Breitengrads dem "Schwenken".


    Als letztes möchte ich noch die Frage zur Eulersingularität mit einer Gegenfrage beantworten: Welchen Längen- und Breitengrad haben Nord- und Südpol? Man sieht da wird es etwas schwammig.


    Das hatte jetzt alles noch nichts direkt mit den A,B und C Winkeln zu tun, sondern die Orientierungsdarstellung über "Drehen" und "Schwenken" bzw. Längen- und Breitengrad ist nichts anderes als eine andere Form um Orientierungen im Raum darzustellen.


    Fubini

    Hallo,


    das geht leider nicht, da der Override zum Bewegungsausführungszeitpunkt wirkt, während der Ruck bereits von der Bewegungsplanung eingerechnet wird. Ich weis nicht mehr wer, aber irgendjemand hat hier mal den schönen Vergleich angestellt, dass der Override sowas ist wie der Lautstärkeregler an einerStereoanlage. Wird ein Lied abgespielt ist es bereits vollständig inklusive aller Lautstärken in Relation zueinander fertig aufgenommen (geplant) und durch das Abspielen (Ausführung) kann nur noch das ganze komplett skaliert werden.


    Fubini

    Hallo,


    du solltest dir im klaren sein, das verschiedene Eulerwinkel Triple die gleiche Orientierung darstellen. In Wirklichkeit sind die Eulerwinkel nur eine einfache Darstellung einer orthonormalen 3x3 Orientierungsmatrix über drei Parameter, d.h. verschiedene Werte von A,B und C führen (u.a. wegen den dahinterliegenden Sinusen und Cosinusen) zum gleichen Ergebnis:


    http://www.roboterforum.de/rob…erator/msg13666/#msg13666


    Insbesondere bei B ungefähr +90 oder -90 bekommst du es noch zusätzlich mit der Eulersingularität (im Englischen auch gerne als Gimbal-Lock bezeichnet) zu tun. In diesem Fall sind A und C nicht mehr eindeutig sondern nur deren Summe. Das ganze ist schon zigmal hier im Forum diskutiert worden, so dass du über die Stichwortsuche mit "Eulersingularität", "Eulerwinkel", "homogene Koordinaten" einges finden solltest.


    Ferner solltest du dir mal anschauen wie der KUKA die Orientierungsführung macht. Die eigentlich drei vorhandenen Freiheitsgrade werden nämlich auf zwei reduziert (Drehen und Schwenken, daher immer die ORI1 und ORI2 in z.B. $VEL und $ACC). Das ist möglich weil man immer um eine feste Koordinaten Achse dreht und schwenkt, wobei bei KUKA die ausgezeichnete feste Achse die x-Achse des Werkzeugkoordinatensystems ist (Hinweis: für Spline gilt das so nicht mehr!). Das steht auch meines Wissens nach so in der Doku.


    Fubini

    Hallo Grubba,


    bei der KRC4 gibt es meines Wissens nach $RAISE_TIME[] in der R1/$machine.dat nicht mehr. Du musst stattdessen auf RampUpTimeUnderLoad in E<n>.xml schauen (n aus {1,...6} je nachdem welche Achse deine Asynchrone Zusatzachse ist).


    Fubini

    Hallo MSTEP,


    ja das kann sein bedingt durch den längeren Hebel der Achse 3. Hast du denn mal die R1/$machine.dat und die $Robcor.dat gegeneinander verglichen. Was sind dann die Unterschiede? Bei meiner V5.6 habe ich z.B. unterschiedliche Achshochlaufzeiten $RAISE_TIME[] gefunden, d.h. die Achsen beschleunigen anders. Was jetzt bei deiner KSS Version die genauen Unterschiede sind kannst du am besten selber durch einen Diff entscheiden.


    Fubini

    Normalerweise liegt nach der Installation der komplette Maschinendaten-Baum auf der D Partition. Dort musst du nur die passende Maschine finden und dann entweder bei laufender Steuerung über die KUKA-Oberfläche im Expertenmodus über die "falsche" drüberkopieren. Fallst die Steuerung nicht läuft kannst du das auch dierekt über den Windows-Explorer machen. Und wie du gerade gelernt hast ist wichtig: Vor Änderungen bitte vorher immer sichern und archivieren!!!


    Fubini

    Hallo,


    PTP VorKarton C_PTP C_DIS
    LIN Vorpunkt C_DIS
    und
    PTP VorKarton C_PTP
    LIN Vorpunkt C_DIS
    sind absolut das gleiche, da auf CP-Seite C_DIS immer der Default ist. Mischen von Kriterien ist auch möglich, so dass es auch nicht daran liegen kann, dass du von C_PTP aud C_DIS wechselst.


    Ist der Roboter absolutgenau? Findet ein Lastwechsel zwischen den Punkten statt? Funktioniert das Überschleifen in T2 bei kleinem Override? Gibt es zusätzliche Meldungen, falls du $STOPNOAPROX aktivierst und das Programm dann in T2 abfährst? Müssen auf CP-Seite irgendwelche Achsen reversieren?


    http://www.roboterforum.de/rob…en/9644/msg46291#msg46291


    http://www.roboterforum.de/rob…oglich/msg21924/#msg21924


    Fubini

    Zitat

    was ich persönlich immer noch nicht verstehe wieso das standardmässig von Kuka so gegeben ist


    Das kommt noch aus Zeiten als man Industrieroboter nur über achsspezifische PTP-Bewegungen steuern konnte und das somit noch keine Rolle spielte. Im Laufe der Zeit haben sich die Leute dann einfach daran gewöhnt. Würde man das jetzt noch ändern würden einen die ganzen alten Hasen wohl dafür steinigen weil man nicht mehr abwärtskompatibel ist. Zugegeben jeder der neu anfangt denkt sich natürlich was für ein Sch... .


    Fubini

    Zitat

    dass er mir jetzt die A4 beginnt zu drehen,


    Wenn die Achse 4 unerwartet viel dreht ist das meist ein Zeichen für die Alpha-5-Singularität. Kann es sein das der Achse 5 Winkel nahezu Null ist, wenn die A4 soviel dreht?


    Zitat

    Kann mir momentan nicht vorstellen das ich so effizient programmieren kann, wenn ich jedesmal noch die einzelnen Bit's für S und T setzen muss


    Normalerweise erreicht man das gewünschte Verhalten am leichtesten in dem man noch Zwischenpunkte auf dem Weg vom Start zum Zielpunkt setzt. Ansonsten programmiert man ja meistens über Inlineformulare und die setzen Status und Turn immer mit.

    Hast du dabei auch Status und Turn der kartesischen Zielposition beachtet? Ohne Turn fährt der Roboter immer auf kürzesten Achsweg vom Start zum Zielpunkt und muss dabei eventuell über einen Endschalter drüber. Wahrscheinlich ist der Punkt nur über den langen Achsweg einer Achse erreichbar und im Handverfahren bist du über den langen Weg zu dem Punkt gelangt. Bei (achsspezifischen) Relativbewegungen spielt das keine Rolle solange weniger als 180 Grad programmiert sind.


    http://www.robot-forum.com/rob…-(-s-)/msg33654/#msg33654


    Fubini

    Hallo,


    Zitat

    Habe mal kurz Versucht ein im OrangeEdit erstellte Routine auf die KRC4 zu laden und auszuführen, doch beim ersten Bewegungssatz läuft der Robi mir in einen Softwareendschalter, obwohl er sich keinen Millimeter von der Home-Position bewegt hat.


    Das ist normal sofern du eine PTP-Bewegung programmiert hast. Liegt die Zielposition deiner programmierten Bewegung hinter den Softwareendschaltern fährt der Roboter gar nicht erst los.


    Fubini