Ein Offset einer Position zuweisen

    Hallo KUKA-Freunde,

    ich steh hier auf dem Schlauch.

    Robi fährt den Offset nicht an.

    DECL FRAME TEILOFFSET_HOEHE={X 0.0,Y 0.0,Z 1000.0,A 0.0,B 0.0,C 0.0}

    TEILOFFSET_HOEHE.Z=(iTeil)*(iHoehe)


    BAS(#TOOL,4)

    BAS(#BASE,2)

    LDAT_ACT=LCPDAT0

    BAS (#VEL_CP,0.5) ;

    BAS (#ACC_CP,100) ;

    LIN XRefPos_EinfGest : TEILOFFSET_HOEHE

    Auszug .dat liste

    ;--- Referenzposition Einfach-Gestell)

    DECL E6POS XRefPos_EinfGest={X 718.949524,Y 470.562714,Z 125.385193,A -119.680298,B -0.352715909,C 179.839005,S 2,T 2,E1 0.0,E2 0.0,E3 0.0,E4 0.0,E5 0.0,E6 0.0}

    DECL FDAT FRefPos_EinfGest={TOOL_NO 4,BASE_NO 2,IPO_FRAME #BASE,POINT2[] " ",TQ_STATE FALSE}

    DECL LDAT LCPDAT0={VEL 2.0,ACC 60.0,APO_DIST 100.0,APO_FAC 50.0,ORI_TYP #VAR,CIRC_TYP #BASE,JERK_FAC 50.0}


    Was habe ich falsch gemacht?

    Freue mich über schnelle Hilfe...

    "Eine Lüge ist bereits dreimal um die Erde gelaufen, bevor die Wahrheit ihre Schuhe anzieht." - Mark Twain

    • Schritt für Schritt zum Roboterprofi!

    Okay,

    habe den Fehler entdeckt...

    Frame bezieht sich sich nicht wie von mir angenommen auf die $Base.

    Musste das Vorzeichen ändern. :)

    DECL FRAME TEILOFFSET_HOEHE={X 0.0,Y 0.0,Z -1000.0,A 0.0,B 0.0,C 0.0}

    TEILOFFSET_HOEHE.Z=(-iTeil)*(iHoehe)

    Ich muss schon sagen, dass ABB wesentlich strukturierter vorgeht...

    Danke und Gruß.

    "Eine Lüge ist bereits dreimal um die Erde gelaufen, bevor die Wahrheit ihre Schuhe anzieht." - Mark Twain

    Vielen Dank!

    Quote from Hermann

    Na, wenn es sich auf das Base beziehen soll, dann musst die beiden Werte um den Doppelpunkt tauschen, dann passt das.

    Das andere ist dann eine Verschiebung um den Punkt?

    "Eine Lüge ist bereits dreimal um die Erde gelaufen, bevor die Wahrheit ihre Schuhe anzieht." - Mark Twain

    Quote from RobSpace

    Ich muss schon sagen, dass ABB wesentlich strukturierter vorgeht...

    Das glaube ich nicht!

    Mathematik ist unabhängig von den Roboterherstellern!

    Für die Framearithmetik müssen die Frames in Transformationsmatrizen umgerechnet werden und dann gilt, dass die Reihenfolge der Matrizenmultiplikation (nicht kommutativ) eingehalten werden muss!

    Falsche Reihenfolge - falsche Ergebnisse (es gibt auch hier Ausnahmen)

    Daher einen kleinen Tip(p):

    Koordinatensysteme nicht mit Namen, sondern einem Index versehen

    anstatt Kwelt K0 verwenden

    anstatt Kkorr K1 verwenden

    die Transformationsmatrix hier wäre dann T01, eine zweite wäre dann T12 (von K1 nach K2)

    Überleg mal, bei Rückfragen stehe ich gerne zu Verfügung (außerdem gibt es bereits genügend Beispiele im deutschen und englischem Forum)

    Die gibt's bei Kuka auch

    Lin_rel offset #TOOL

    bzw.

    Lin_rel offset #BASE

    Geht glaube ich in neueren Releases mit allen Bewegungsarten. Zumindest beim Spline wurde es damals so eingeführt. Bei alten Typen haben wird dann weil's wenig Aufwand war auch noch umgesetzt soweit ich mich erinnere.

    Edited once, last by fubini (February 9, 2022 at 7:25 AM).

    Hi,

    irgendeine geteachte Position gibt es ja wahrscheinlich schon.

    Ein Praxisbespiel wäre:

    Alle Koordinaten sind aktuell Null, aber könnten nachgetragen werden, wenn ich eine Abweichung zum Master brauche. Case-Nummer kommt von der SPS, je nach Teil was läuft. Kann also unterschiedliche Offsets je Teil fahren.

    Gruß

    Mein Name ist Hase. Ich weiß von nix.

    Was für ein neckisches Spiel machen wir hier?

    RobSpace hat sein Problem geschildert und nachgelegt, sonst aber nichts, alle anderen haben nur Vermutungen angestellt (ich wahrscheinlich auch)

    RobSpace

    Was ist eigentlich das Problem?

    Nach deinem "-" in Post #3 vermute ich, dass es hier um eine Inverse handelt!

    Somit:

    Alle Karten auf den Tisch

    Thread am besten schließen. Ist doch alles geklärt.

    Er hat sein Problem eh schon gelöst.

    Das Minuszeichen vor der Z-Koordinate kommt daher, dass der Offset hinter dem Doppelpunkt toolbezogen ist, wenn die Stossrichtung des Tools Z ist und aus dem Flansch heraus geht, dann muss der Offset halt negativ sein, dass das Tool nicht hinter den Zielpunkt fährt. Das ist doch schon alles.

    Ende Gelände.

    Der Rest geht dann ins philosophische.

    Hallo Zusammen,

    danke zunächst für die hilfreichen Ideen.

    Ich muss gestehen, dass ich nicht der typische KUKA-Programmierer bin und sehr selten mit KrL in Kontakt komme. :(

    Deswegen finde ich dieses Forum so hilfreich.

    Hatte auch 2 Kurse vor langer Zeit bei KUKA gemacht - vermutlich nur noch die basics geblieben...

    Bei ABB:

    nur als Beispiel:

    Versatz zum Werkobjekt:

    MoveL Offs(Position,var1,var2,var3), speed, zone, tool\WObj:=werkobjekt;

    Versatz zum Tool:

    MoveL RelTool(Position,var1,var2,var3),speed,zone,tool\WObj:=werkobjekt;

    Natürlich gibt es auch Pose -vermutlich ähnlich wie bei KUKA

    poseVERSATZ:=[[nPosy,nPosx,nPosZ],[1,0,0,0]]

    poseOrient.rot:=OrientZYX(angleZ,angleY,angleX)

    Deshalb nochmal vielen Dank, werde mich vermutlich des öfteren an euch wenden... :)

    "Eine Lüge ist bereits dreimal um die Erde gelaufen, bevor die Wahrheit ihre Schuhe anzieht." - Mark Twain

    Du musst nur irgendwie klar machen, was Dein Ziel ist.

    Für mich reicht der geometrische Operant ":" um einen geteachten Punkt mit einem Offset zu verrechnen, je nach Produkt, was auf der Anlage läuft.

    Weswegen ich deinen Vergleich zu ABB nicht mal nachvollziehen möchte. Sieht für mich irgendwie kompliziert aus ..

    Und mein Weg ist in KRL nur ein Weg, es gibt viele Wege um Offsets in KRL zu verarbeiten.

    Ich habe eben die Operanten-Version, Arrays usw .. der Möglichkeiten viele .. Am Ende muss es funktionieren.

    Mein Name ist Hase. Ich weiß von nix.