Beiträge von 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

    Hallo,


    um welche Stossrichtung soll es denn gehen? Leider ist Stossrichtung nicht eindeutig und ein Begriff der mehrfach für unterschiedliche Dinge verwendet wird:


    [list type=decimal]

    • $TOOL_DIRECTION in der $custom.dat: Diese Richtung wird beim Spline für das bahnbegleitende Dreibein (siehe auch $TSYS) eingesetzt, das sich aus Bahntangente, der Achse gemäß $TOOL_DIRECTION und der daraus automatisch resultierenden dritten Achse ergibt. Das so entstehende Dreibein, kann dann z.B. beim Pendeln verwendet werden. Im alten Verfahrbereich ohne Spline gab es diese Wahlmöglichkeit nicht, sondern es ist wie in der dort verwendteten Orientierungsführung immer die x-Achse als ausgezeichnete Achse im bahnbegleitenten Dreibein verwendet worden.

    • Die Stossrichtung in der Werkzeugvermessung über die Registry-Files: Hier geht es darum ein Werkzeug, dass durch seine spezielle Konstruktion eine ausgezeichnte Richtung vorgibt, dieser ausgezeichnten Richtung eine spezielle Achse zuzuweisen. D.h. über die registry-Files kann man angeben ob die ausgezeichntete Achse im $TOOL (bzw. TOOL_DATA[]) die x, y oder z-Achse sein soll.
    [/list]


    Fubini

    Es ist zwar nicht zwingend notwendig, aber selbst innerhalb einer Steuerungsversion wird von KUKA dringend empfohlen auch dieselbe Version der Software auf allen beteiligten Steuerungen laufen zu haben. Man sollte also nicht mal z.B. eine V8.3.10 mit einer V8.3.11 kombinieren.


    Fubini

    Hallo,


    Hast du auch $SR_VEL_RED und $SR_WORKSPACE_RED in der STEU/$custom.dat auf false gesetzt. Ansonsten verhindert ja die nicht sichere Steuerung gerade das Zuschlagen der Safe-Überwachungen indem sie rechtzeitig langsam macht.


    Ansonsten: was sagt den $VEL_ACT wenn du dein Programm abfährst? Werden die 1000 mm/s überhaupt gerissen?


    Fubini

    Hallo,


    was sicher nicht geht ist ein flüssiger Übergang zwischen Spline und nicht Splinebewegungen, d.h


    Spline
    ...
    EndSpline c_spl
    Lin / Circ


    führt zu einem Genauhalt. Es geht also nur
    Spline
    ...
    EndSpline c_spl
    sLin / sCirc



    Gruß
    Fubini

    Hallo,


    in deinem Testcode steht nur $APO.CPTP = 95. Schau doch mal nach auf welchen Werten $APO.CDIS (ich glaube der default laut bas.src ist nur 3 mm) steht. Beim Spline ist es immer so dass alle Kriterien ausgewertet werden und das das zum kleinsten Überschleifradius führt gewinnt.


    Beim CP-Spline sind also immer $APO.CDIS, $APO.CORI und falls Zusatzachsen vorhanden sind auch $APO.CPTP relevant. Beim PTP-Spline sind immer $APO.CPTP und $APO.CDIS relevant. Das ist auch der Grund warum man syntaktisch extra neben dem C_DIS inzwischen das neue Synonym C_SPL eingeführt hat um Überschleifen zu kennzeichnen. Es ist halt nicht mehr so das man wie im alten Verfahrbereich über die Überschleifkennung ein Kriterium aus $APO auswählt.


    Ferner kannst du nie mehr überschleifen als das letzte Segment im Splineblock, d.h. hier hat sich die Bedeutung von $APO.CPTP im Vergleich zum alten PTP geändert. $APO.CPTP=100 heisst das das Überschleifen fühestens am Startpunkt des letzten Splinesegments beginnt und spätestens am Endpunkt des ersten Segments im nachfolgenden Spline endet (zusätzlich wird auch noch der Achsweg symmetrisiert, dass du nur auf einer Seite genau die Grenze des Segments siehst). Besteht der Spline aus nur einem Segment ist man zusätzlich auf die Mitte der beteiligten Segmente beschränkt um überlappende Überschleifbereiche zu verhindern.


    Ist das letzte Segment sehr kurz muss der Roboter schon bremsen um am Genauhalt zum stehen kommen zu können, d.h. er ist schon auf der Bremsrampe um stehen bleiben zu können wenn Überschleifen beginnt. Gleiches gilt natürlich symmetrisch für das Beschleunigen im nachfolgenden Satz. Die aufgrund dieser Tatsache entstehenden Geschwindigkeitseinbrüche sind übrigens einer der Gründe warum man Splineblöcke eingeführt hat, da dann die Bewegungsplanung schon die komplette Bewegung sieht und in einem Zug den ganzen Block durchplanen kann und erst am letzten geteachten Punkt im Block anhalten vorsehen muss. Man ist also unabhängig vom Vorlauf und kann innerhalb des Blocks immer Vollgas geben.


    Gruß
    Fubini

    hallo,


    am besten alle Folds aufmachen, alle programme sichtbar machen (ist ein Flag in den Dateieigenschaften) und dann $stopnoaprox in Anzeige -> Variable -> Einzeln auf true setzen. Fährt man jetzt das Programm in T2 ab, stoppt der Roboter immer wenn nicht überschliffen werden kann und der Programm zeiger steht an der entsprechenden Anweisung und man sieht gleichden Verursacher.


    Fubini

    Und nicht vergessen: die Softwareendschalter $SOFTN/P_END[] passen dann nicht mehr. Bei A6 wahrscheinlich harmlos, da man die auch endlos drehend betreiben kann - zumindest ohne sich aufwickelndes Schlauchpaket.


    Fubini

    Hallo,


    ändere


    AXIS SATZ0={A1 -83.5464783,A2 -61.8951874,A3 84.2500839,A4 24.0699196,A5 -25.0256786,A6 -203.570251}


    in


    E6AXIS SATZ0={A1 -83.5464783,A2 -61.8951874,A3 84.2500839,A4 24.0699196,A5 -25.0256786,A6 -203.570251, E1 <was auch immer du willst>}


    Der Typ "AXIS" besteht nur aus 6 Achsen A1-A6. Der Typ "E3AXIS" hat dann drei Zusatzachsen dabei, der Typ "E6AXIS" sechs Zusatzachsen.


    Fubini

    Hallo,


    ich würde mal auf ein Statusproblem tippen. Was sind die Datentypen die du dem ":"-Operator übergibst? E6POS oder POS oder Frame. Was für einen Status hat die Zielposition des Ergebnisses vom ":" Operator im Vergleich zur geteachten Pose?


    Gruß
    Fubini

    Hallo Tobby,


    habt ihr mal versucht $TOOL über INV_POS($TFLWP) in den Handwurzelpunkt zu legen. Da es sich ja um eine Zentralhand handelt machen normalerweise die drei Grundachsen die kartesische Bewegung und die Handachsen sind dann alleine für die Orientierung zuständig.


    Eine andere Möglichkeit wäre $ORI_TYPE=#JOINT zu nutzen. Da wird auch benutzt, dass man weiterhin die kartesissche Bahn wie programmiert halten soll und die Handachsen werden PTP verfahren. Eigentlich dient das ja dazu die Alpha 5 Singularität zu umgehen. Aber das sorgt auch dafür das die Grundachsen die Gerade fahren würden. Wahrscheinlich ginge das sogar mit beliebigem TCP.


    Fubini