Wie bringe ich eine externe Achse dazu auf den Vel.CP zu reagieren?

  • Hallo, wir haben einen Kuka mit einer Krc 2 Steuerung bei uns in der Firma. Der Kuka steht auf einer Linear Achse und davor ein Drehtisch als endlos drehende Achse. Das Programm kommt aus dem Cam System Sprutcam.

    Nun zu meinem Problem: Der Roboter soll die montierte Frässpindel "hinhalten" und der Drehtisch (Achse 8 ) dreht sich, der Roboter muss nur zwischendurch zustellen. Dies macht er auch allerdings reagiert der Drehtisch (Achse 8, mathematisch gekoppelt) nicht auf den vel.cp und der Verschleifbefehl c_Dis scheint auch nicht zu funktionieren da der Tisch sich ruckelig bewegt. Ich kann den Vel.cp von 0.1 bis 2 hochstellen und der Tisch macht immer dasselbe. Gibt es da einen extra Befehl um die Kopplung aufzurufen? oder ist die Achse vielleicht falsch installiert? Muss der Drehtisch mit einem anderen Befehl versorgt werden?

    Die Leute von Sprutcam und Kuka wissen auch nicht so recht weiter. Vielleicht gibt es hier einen klugen Kopf der mir weiterhelfen kann?:)


    Teacht man ein Programm direkt am Roboter kann der Tisch auf einmal auf unterschiedliche Geschwindigkeiten fahren und auch im Handverfahren folgt der Roboter einer Spitze auf dem Tisch so wie es sein soll.


    Das Programm sieht in etwa so aus:


    DEF Test()

    GLOBAL INTERRUPT DECL 3 WHEN $STOPMESS==TRUE DO IR_STOPM ( )

    INTERRUPT ON 3

    BAS (#INITMOV,0)

    BAS (#VEL_PTP,100)

    BAS (#ACC_PTP,100)


    $BASE=BASE_DATA[18]

    $TOOL=TOOL_DATA[1]

    S_RPM=18000

    DoR=3

    $advance=5

    $VEL.CP=0.167

    PTP {A1 -22.427, A2 -86.762, A3 136.469, A4 -179.779, A5 34.659, A6 179.852, E1 -1560, E2 -112.89, E3 0, E4 0, E5 0, E6 0}

    LIN {X -560.222, Y -231.219, Z 34.001, A -157.443, B 0, C -180, E2 -112.89} C_DIS

    LIN {X -560.222, Y -231.219, Z 48, A -157.443, B 0, C -180, E2 -112.89} C_DIS

    $VEL.CP=0.133

    LIN {X -560.222, Y -231.219, Z 24, A -157.443, B 0, C -180, E2 -112.89} C_DIS

    LIN {X -560.219, Y -231.218, Z 24, A -157.443, B 0, C -180, E2 -122.34} C_DIS

    LIN {X -560.223, Y -231.22, Z 24, A -157.443, B 0, C -180, E2 -131.8} C_DIS

    LIN {X -560.224, Y -231.22, Z 24, A -157.443, B 0, C -180, E2 -141.25} C_DIS

    LIN {X -560.224, Y -231.22, Z 24, A -157.443, B 0, C -180, E2 -150.7} C_DIS

    LIN {X -560.225, Y -231.221, Z 24, A -157.443, B 0, C -180, E2 -160.16} C_DIS

    LIN {X -560.226, Y -231.221, Z 24, A -157.443, B 0, C -180, E2 -169.61} C_DIS

    LIN {X -560.229, Y -231.222, Z 24, A -157.443, B 0, C -180, E2 -179.07} C_DIS

    LIN {X -560.229, Y -231.222, Z 24, A -157.443, B 0, C -180, E2 -188.52} C_DIS

    LIN {X -560.229, Y -231.222, Z 24, A -157.443, B 0, C -180, E2 -197.97} C_DIS

    LIN {X -560.232, Y -231.223, Z 24, A -157.443, B 0, C -180, E2 -207.43} C_DIS

    LIN {X -560.235, Y -231.225, Z 24, A -157.443, B 0, C -180, E2 -216.88} C_DIS

    LIN {X -560.232, Y -231.223, Z 24, A -157.443, B 0, C -180, E2 -226.33} C_DIS

    LIN {X -560.232, Y -231.223, Z 24, A -157.443, B 0, C -180, E2 -235.79} C_DIS

    LIN {X -560.236, Y -231.225, Z 24, A -157.443, B 0, C -180, E2 -245.24} C_DIS

    LIN {X -560.236, Y -231.225, Z 24, A -157.443, B 0, C -180, E2 -254.69} C_DIS

    LIN {X -560.234, Y -231.224, Z 24, A -157.443, B 0, C -180, E2 -264.15} C_DIS

    LIN {X -560.236, Y -231.225, Z 24, A -157.443, B 0, C -180, E2 -273.6} C_DIS

    LIN {X -560.233, Y -231.224, Z 24, A -157.443, B 0, C -180, E2 -283.05} C_DIS

    LIN {X -560.233, Y -231.224, Z 24, A -157.443, B 0, C -180, E2 -292.51} C_DIS

    LIN {X -560.23, Y -231.223, Z 24, A -157.443, B 0, C -180, E2 -301.96} C_DIS

    LIN {X -560.229, Y -231.222, Z 24, A -157.443, B 0, C -180, E2 -311.42} C_DIS

    LIN {X -560.232, Y -231.223, Z 24, A -157.443, B 0, C -180, E2 -320.87} C_DIS

    LIN {X -560.23, Y -231.223, Z 24, A -157.443, B 0, C -180, E2 -330.32} C_DIS

    LIN {X -560.229, Y -231.222, Z 24, A -157.443, B 0, C -180, E2 -339.78} C_DIS

    LIN {X -560.229, Y -231.222, Z 24, A -157.443, B 0, C -180, E2 -349.23} C_DIS

    LIN {X -560.227, Y -231.221, Z 24, A -157.443, B 0, C -180, E2 -358.68} C_DIS

    LIN {X -560.222, Y -231.219, Z 24, A -157.443, B 0, C -180, E2 -368.14} C_DIS

    LIN {X -560.22, Y -231.219, Z 24, A -157.443, B 0, C -180, E2 -377.59} C_DIS

    LIN {X -560.224, Y -231.22, Z 24, A -157.443, B 0, C -180, E2 -387.05} C_DIS

    LIN {X -560.22, Y -231.218, Z 24, A -157.443, B 0, C -180, E2 -396.5} C_DIS...........

  • Schritt für Schritt zum Roboterprofi!
  • Du brauchst eine aktive externe Base die sich mit dem Tisch mitdreht. Dafür ist der EK Befehl da der in deinem Anwenderprogramm fehlt. Das sieht dann in etwa so aus


    $BASE = EK(...)


    Du machst dagegen ein direkte Zuweisung an $BASE in Zeile 7 was nur ein festes Bezugssystem im Raum aktiviert. EK dient also dazu dem System zu sagen mit welcher externen Kinematik das BASE mitfahren soll. Das funktioniert wahrscheinlich beim teachen am Roboter weil dein BASE als externes BASE auf einer Zusatzachse vermessen wurde. In dem Fall ruft bei Inlineformularen das bas.src über die Methode EX_BASE den passenden EK Aufruf auf. Ersetze also deine direkte Zuweisung an BASE in Zeile 7 durch


    EX_BASE(18,3)


    und es sollte klappen. Die genauen Parameter lies bitte im bas.src noch mal selbst nach. Ich hab keine Steuerung parat.


    Übrigens die Geschwindigkeit von Zusatzachsen wird über $vel_extax[] programmiert nicht $vel.cp. Wenn ich mich richtig erinnere wird das aber durch


    BAS (#VEL_PTP,100)


    schon auf 100 Prozent mitgesetzt.


    https://www.robot-forum.com/ro…r/?postID=81256#post81256

    https://www.robot-forum.com/ro…s/?postID=50461#post50461


    Ansonsten bin ich doch sehr überrascht, dass der KUKA Support da nicht helfen konnte ist ziemlich Standard.

    Bei externer Programmgenerieren über Sprutcam oder ähnliche Software hab ich das noch nie richtig erzeugt gesehen. Vielleicht geht es ja wieder erwarten doch und das Projekt ist da auch noch falsch. Das müsste aber jemand von Sprutcam sagen können. KUKA ist da sicher raus.


    Fubini

    17 Mal editiert, zuletzt von fubini ()

  • Das werde ich am Montag mal ausprobieren, Danke!


    Bezüglich des Supports bei Kuka hab ich die Erfahrung gemacht das es immer darauf ankommt an wen man gerät...


    Und das mit den Vel.cp müsste doch funktionieren dadurch das die Achse mathematisch gekoppelt ist oder bin ich da falsch informiert? (entschuldigt, ich hab leider auch nur halbwissen da ich eigentlich Tischler bin)

    Normalerweise ist vel.cp ja nur auf den TCP bezogen, aber durch die Kopplung müsste die externe achse doch auch darauf reagieren oder braucht die immer den $vel_axis?

  • Es ist genau andersherum. Der Roboter fährt mit dem Tisch (genauer auf dem base und das wiederum mit dem Tisch) mit und nicht der Tisch mit dem Roboter. Vel.cp ist dann die Geschwindigkeit der Prozessbewegung im basesystem, die der Roboter auf dem Tisch fährt ohne die zusätzliche Geschwindigkeit die durch die Drehbewegung des Tisches entsteht. Ob nun der Roboter bei stehendem Tisch seine Prozessbahn abfährt oder mit drehendem Tisch führt dann immer zum gleichen Prozessergebnis. Insbesondere kannst du die Prozessbahn eben dann auch teachen während der Tisch noch steht und erst später nimmst du die Tischbewegung mit vorgegebener Geschwindigkeit laut vel_extax dazu. Aber probiers einfach mal aus. Setze einfach mal $vel_Extax[2] für den Tisch testweise am Roboter runter und du wirst feststellen dass die Kontur auf dem Bauteil immer noch die gleiche ist.

    9 Mal editiert, zuletzt von fubini ()

  • Der Roboter soll die montierte Frässpindel "hinhalten" und der Drehtisch (Achse 8 ) dreht sich, der Roboter muss nur zwischendurch zustellen. Dies macht er auch allerdings reagiert der Drehtisch (Achse 8, mathematisch gekoppelt)

    Wenn ich all Deine geposteten Positionen sehe.....


    LIN {X -560.222, Y -231.219, Z 24, A -157.443, B 0, C -180, E2 -112.89} C_DIS

    ....

    LIN {X -560.22, Y -231.218, Z 24, A -157.443, B 0, C -180, E2 -396.5} C_DIS.....


    ändert sich rein der Winkel der Drehachse E2.

    Wenn Du wirklich mathematisch gekoppelt fahren würdest, würde sich die programmierte Base 18 mitdrehen mit der Tischbewegung und der Roboter würde mitfahren! Heisst, gegenüber dem Werkstück still stehen, was Du ja auch nicht willst.


    Rein die Kopplung richtig aktivieren wird nicht die Lösung sein. Punkte müssten dann dazu auch richtig generiert werden.


    Ich kann den Vel.cp von 0.1 bis 2 hochstellen und der Tisch macht immer dasselbe.

    Weil Du positionstechnisch TCP gegenüber der Base stehen bleibst, wird die aktuelle Geschwindigkeit 0 m/s sein. Da nützt eine andere Vorgabe nichts.


    Ich würde Dir empfehlen, die systemrelevanten Variabeln im Hauptlauf der Geschwindigkeit / Beschleunigung mal abzubilden in der Variabelnübersicht und parallel zum Ablauf aktualisiert anzeigen zu lassen. Dann siehst Du auch, wie sich das Ganze verhält..

    Es ist sicher nett, gleich mit einem Sprutcam-generierten Prog zu starten und zu Testen.


    Für's Verständnis der Sache würde ich aber mal simpel ein Testprogramm teachen mit ILF's, und danach mal Verfolgen, was das ILF für Parameter exakt setzt und was ein BAS (#CP_PARAMS, .. ) alles so macht. Auch das Verhalten der Punktkoordinaten müsste dann gut ersichtlich sein, dass sich die ändern, wenn sich die BASE mit dem Tisch sich mitdreht.

    Manche Maenner bemuehen sich lebenslang, das Wesen einer Frau zu verstehen. Andere befassen sich mit weniger schwierigen Dingen z.B. der Relativitaetstheorie.

  • Rein die Kopplung richtig aktivieren wird nicht die Lösung sein. Punkte müssten dann dazu auch richtig generiert werden.

    Also hilft mir der Lösungsansatz von Fubini mit Ex_Base nicht weiter?

    Ich würde Dir empfehlen, die systemrelevanten Variabeln im Hauptlauf der Geschwindigkeit / Beschleunigung mal abzubilden in der Variabelnübersicht und parallel zum Ablauf aktualisiert anzeigen zu lassen. Dann siehst Du auch, wie sich das Ganze verhält..

    Wenn ich mir die Variabeln angucke kommt der Tisch immer nur auf ca. 20 Prozent seiner Geschwindigkeit. Vielleicht verdeutlicht ein kurzes video mein problem.


    Um eine generierung des Programms durch Sprutcam kommen wir auch nicht herum da wir 3D Teile fräsen wollen und das ist so am Roboter ja nicht möglich zu programmieren(zumindest für ein Tischler^^).

    Vielleicht gehen wir auch falsch an die Sache ran und man muss mehr mit den Roboterachsen machen als mit dem Tisch aber für mich macht es mehr sind bei runden Bauteilen den Tisch drehen zu lassen als den Roboter da hier ja viel weniger Achsen in bewegung sind.

  • Stell es dir mal so vor. Du bist der Roboter und sitzt im Zug auf deinem Sitzplatz und willst ins Bordrestaurant. Was ich machen will ist du teached den Weg, der dich ins Restaurant bringst und läufst dann den mit vel.cp ab. Das kannst du komplett machen ohne zu Wissen wie der Zug gerade fährt oder ob er sogar steht. Was du machen willst ist sitzen bleiben und den Zug unter dir so zu verschieben, dass das Bordrestaurant unter deinen Hintern kommt. Was ist leichter?


    Das was du machen willst geht aber tatsächlich auch. Dazu solltest du dir $IPO_MODE anschauen. Das dreht letzten Endes die Bedeutung von Tool und Base um und invertiert den pos_act. Wird normalerweise verwendet wenn der Roboter das Werkstück hält und das Werkzeug fest irgendwo installiert ist. Dann kannst für den Roboter einen circ entgegen der Drehrichtung der Zusatzachse programmieren und der Roboter bleibt stehen.

    Also hilft mir der Lösungsansatz von Fubini mit Ex_Base nicht weiter?

    Doch. Er meinte glaube ich nur dass deine Posen dann sicher nicht korrekt sind um deinen Prozess zu realisieren. Wenn deine Posen unbedingt aus Sprutcam kommen müssen muss diese Software das einfach auch unter Berücksichtigung der Tischdrehung richtig generieren. Ob es das überhaupt kann ist kein Problem der Robotersteuerung. Du sagst ja selbst dass es wie gewünscht funktioniert wenn du direkt am Roboter teached. Schau dir da doch mal die Koordinaten an und du wirst feststellen, dass sie nicht konstant sind wie in dem Sprutcam generierten Code. Den Ex_base braucht es auf alle Fälle weil sonst Tisch und Roboter nie als gekoppelte Einheit behandelt werden.


    Fubini

    7 Mal editiert, zuletzt von fubini ()

  • Doch. Er meinte glaube ich nur dass deine Posen dann sicher nicht korrekt sind um deinen Prozess zu realisieren. Wenn deine Posen unbedingt aus Sprutcam kommen müssen muss diese Software das einfach auch unter Berücksichtigung der Tischdrehung richtig generieren. Ob es das überhaupt kann ist kein Problem der Robotersteuerung.

    fubini: Ja, genau dies meine ich. So wie Du es umschrieben hast, gehen auch meine Gedanken.


    Ich kenne Sprutcam selbst überhaupt nicht. Habe aber einfach mal kurz einen Blick geworfen in die Knowledge Base. Da wird was erwähnt betreffend Koordinatensystem mitdrehen lassen.

    Robot rotating table - SprutCAM Knowledge Base - SPRUT Technology

    Wie sieht das aktuell bei Dir aus?

    Manche Maenner bemuehen sich lebenslang, das Wesen einer Frau zu verstehen. Andere befassen sich mit weniger schwierigen Dingen z.B. der Relativitaetstheorie.

  • Du machst dagegen ein direkte Zuweisung an $BASE in Zeile 7 was nur ein festes Bezugssystem im Raum aktiviert. EK dient also dazu dem System zu sagen mit welcher externen Kinematik das BASE mitfahren soll. Das funktioniert wahrscheinlich beim teachen am Roboter weil dein BASE als externes BASE auf einer Zusatzachse vermessen wurde. In dem Fall ruft bei Inlineformularen das bas.src über die Methode EX_BASE den passenden EK Aufruf auf. Ersetze also deine direkte Zuweisung an BASE in Zeile 7 durch


    EX_BASE(18,3)

    Schreibe ich das so, sagt die Steuerung: Name nicht als Untergramm vereinbart


    DEF Test()

    GLOBAL INTERRUPT DECL 3 WHEN $STOPMESS==TRUE DO IR_STOPM ( )

    INTERRUPT ON 3

    BAS (#INITMOV,0)

    BAS (#VEL_PTP,100)

    BAS (#ACC_PTP,100)


    EX_Base(18,3)

    $TOOL=TOOL_DATA[1]

    S_RPM=18000

    DoR=3

    $advance=5

    $VEL.CP=0.167

    PTP {A1 -22.427, A2 -86.762, A3 136.469, A4 -179.779, A5 34.659, A6 179.852, E1 -1560, E2 -112.89, E3 0,

    .......


    Mein Roboter Experte hat mir das dann so vorgeschlagen, dabei fährt der Robbi den ersten PTP richtig an und fährt dann weit weg vom Tisch in den Achs Endschalter?


    DEF Test()

    GLOBAL INTERRUPT DECL 3 WHEN $STOPMESS==TRUE DO IR_STOPM ( )

    INTERRUPT ON 3

    BAS (#INITMOV,0)

    BAS (#VEL_PTP,100)

    BAS (#ACC_PTP,100)


    $BASE=EK(MACHINE_DEF[3].ROOT,MACHINE_DEF[3].MECH_TYPE,BASE_DATA[18]:{x 0,y 0,z 0,a 0,b 0,c 0})

    $TOOL=TOOL_DATA[1]

    S_RPM=18000

    DoR=3

    $advance=5

    $VEL.CP=0.167

    PTP {A1 -22.427, A2 -86.762, A3 136.469, A4 -179.779, A5 34.659, A6 179.852, E1 -1560, E2 -112.89, E3 0, E4 0, E5 0, E6 0}

    LIN {X -560.222, Y -231.219, Z 34.001, A -157.443, B 0, C -180, E2 -112.89} C_DIS

    Einmal editiert, zuletzt von Kotti kuka ()

  • Zitat

    Schreibe ich das so, sagt die Steuerung: Name nicht als Untergramm vereinbart

    Seltsam er kennt ja BAS auch und das ist genau gleich im bas.src definiert. Was hast du den für eine Softwareversion? Recht Alt? Ganz Ganz früher musste man Unterprogramme explizit über EXT deklarieren. Das ist solang her, dass ich da aber die Details auswendig nicht zusammenbringe,


    Zitat

    Mein Roboter Experte hat mir das dann so vorgeschlagen, dabei fährt der Robbi den ersten PTP richtig an und fährt dann weit weg vom Tisch in den Achs Endschalter?

    Wundert mich nicht. Liegt dann wohl wie oben schon besprochen an den falschen Posen. Die können so nicht richtig sein. Wenn der Roboter bezogen auf das bewegte Base steht heißt das das er relativ zum sich mit der Tischbewegung wegdrehenden Base konstante Position hat. Um den Roboter dann in der Welt stehen zulassen muss er genau die Bewegung des Tisches ausgleichen.

    Stell dir wieder den Zug vor. Wenn du auf der Erde stehen willst musst du gegen die Zugbewegung anlaufen um nicht mitgerissen zu werden.


    Fubini

  • Hätte ich mal früher gewusst das es euch gibt^^ So wie es aussieht ist das Problem gelöst. Hab es jetzt so:


    Bei den X,Y,Z,a,b,c Werten die vermessenen Basedaten eintragen (nur den Z-Wert musste ich um ca. 100mm anpassen, das erklärt sich mir noch nicht so ganz)

    Und zusätzlich den Anweisungen aus dem Video folgen um Sprutcam richtig einzustellen und dann ist die Geschwindigkeit über vel.cp anpassbar und der Tisch läuft auch flüssiger. https://kb.sprutcam.com/display/SKB/Robot+rotating+table



    DEF Test()

    GLOBAL INTERRUPT DECL 3 WHEN $STOPMESS==TRUE DO IR_STOPM ( )

    INTERRUPT ON 3

    BAS (#INITMOV,0)

    BAS (#VEL_PTP,100)

    BAS (#ACC_PTP,100)


    $BASE=EK(MACHINE_DEF[3].ROOT,MACHINE_DEF[3].MECH_TYPE,BASE_DATA[18]:{x 0,y 0,z 0,a 0,b 0,c 0})

    $TOOL=TOOL_DATA[1]

    S_RPM=18000

    DoR=3

    $advance=5

    $VEL.CP=0.167

    PTP {A1 -22.427, A2 -86.762, A3 136.469, A4 -179.779, A5 34.659, A6 179.852, E1 -1560, E2 -112.89, E3 0, E4 0, E5 0, E6 0}

  • Schön, dass es scheint zu funktionieren.


    Hab mal noch kurz Deine "Kinematikkettenbeschriebe" angeschaut.


    Code
    DECL ET_AX $ET2_AX={TR_A1 #E2,TR_A2 #NONE,TR_A3 #NONE} ;EXTERNE ACHSEN #NONE, #E1, #E2, #E3, #E4, #E5, #E6
    CHAR $ET2_NAME[20] ;NAME DER TRANSFORMATION ET2 MAX. 20 ZEICHEN
    $ET2_NAME[]="Drehtisch "
    FRAME $ET2_TA1KR={X 3700.0,Y 800.0,Z 840.591003,A 0.0,B 90.0,C 0.0} ;FRAME ZWISCHEN A1 UND FUSSPUNKT DER KIN IN TRAFO ET2
    FRAME $ET2_TA2A1={X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0} ;ZWISCHEN A2 UND A1
    FRAME $ET2_TA3A2={X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0} ;ZWISCHEN A3 UND A2
    FRAME $ET2_TFLA3={X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0} ;ZWISCHEN FL UND A3
    FRAME $ET2_TPINFL={X 200.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0} ;ZWISCHEN MESSPUNKT UND FL

    Der X-Wert von 3700 scheint mir anhand Deines Videos schon speziell.

    Auch nur die einmalige verdrehung um 90 Grad.

    Die X 200 des Messpins braucht es eigentlich ab V5.x auch nicht mehr.


    Auch bei der KL:

    Code
    $ET1_NAME[]="KL 1500"
    FRAME $ET1_TA1KR={X 0.0,Y 0.0,Z 490.0,A 0.0,B 90.0,C 0.0} ;FRAME ZWISCHEN A1 UND FUSSPUNKT DER KIN IN TRAFO ET1
    FRAME $ET1_TA2A1={X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0} ;ZWISCHEN A2 UND A1
    FRAME $ET1_TA3A2={X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0} ;ZWISCHEN A3 UND A2
    FRAME $ET1_TFLA3={X 0.0,Y 0.0,Z 0.0,A -27.9694996,B -89.9841003,C 27.9694996} ;ZWISCHEN FL UND A3

    Die Verdrehungen der beiden +- 27.96.. sind auch sehr speziell.


    Hast Du diese Werte ermittelt / eingetragen ?


    Z.T. wird dies kompensiert durch die Fusspunktvermessung und den daraus resultierenden Werte in der config.dat. Das nachvollziehen der Nullpunkte der verschiedenen Koordinatensysteme wird dadurch aber sehr unübersichtlich.

    Manche Maenner bemuehen sich lebenslang, das Wesen einer Frau zu verstehen. Andere befassen sich mit weniger schwierigen Dingen z.B. der Relativitaetstheorie.

  • Der X-Wert von 3700 scheint mir anhand Deines Videos schon speziell.

    Auf dem Video ist die Linearachse nicht zu sehen auf der der Roboter steht. Wollte nicht die zurzeit noch herrschende Unordnung zeigen😅 also müsste das ja hinkommen.

    Hast Du diese Werte ermittelt / eingetragen ?

    Nein das wurde von jemandem gemacht der sich hauptberuflich mit Robotern beschäftigt. Nur halt nicht mit sprutcam.

  • Auf dem Video ist die Linearachse nicht zu sehen auf der der Roboter steht. Wollte nicht die zurzeit noch herrschende Unordnung zeigen😅 also müsste das ja hinkommen.


    Die X 3700 haben da nichts mit der Linearachse zu tun.

    Das ist rein der interne Beschrieb der Tisch-Kinematik selbst, Versatz Fusspunkt zu erstem Drehpunkt.

    Wenn als Fusspunkt das Zentrum des Tisches angenommen wird, wäre typischerweise X und Y 0 und so das Root-Koordinatensystem des Tisches im Zentrum der Drehachse, und nicht 3,7m versetzt.

    Wenn man das vereinfachte Beschreibungsverfahren anwendet, würde man die Tischhöhe auch gleich als Z-Wert darin berücksichtigen.

    Dann wäre hier wirklich die Differenz Weltkoordinationssystem zu Tischmitte Arbeitsplatte ersichtlich:

    MACHINE_DEF[3]={NAME[] "Tisch",COOP_KRC_INDEX 1,PARENT[] "base",ROOT {X 4573.82324,Y 102.487602,Z -2756.90601,A -97.8034973,B -89.9136963,C 97.9244003},MECH_TYPE #EASYS,GEOMETRY[] " "}

    Der jetzige Wert in Z von -2.75 Metern ist darum hier genau so exotisch.

    Wenn Dir klar ist, wo die Systemrelevanten Koordinatensysteme liegen, sollte man diese Distanzen problemlos mit dem Zollstock kontrollieren können.



    von jemandem gemacht der sich hauptberuflich mit Robotern beschäftigt.

    Für mich ist es nur noch Hobby. :beerchug: Eigentlich genug graue Haare vom der Koordinatensystemakrobatik

    Manche Maenner bemuehen sich lebenslang, das Wesen einer Frau zu verstehen. Andere befassen sich mit weniger schwierigen Dingen z.B. der Relativitaetstheorie.

  • Hallo Roboterforum,


    ich habe ein ähnliches Problem das mich schon länger begleitet. Konkret versuche ich eine Synchrone Bewegung einer externen Achse ohne mathematische Kopplung auszuführen. Dabei beschreibt der TCP eine Spirale auf einer Welle die beschichtet wird mittels Auftragschweißen. Wir haben 2x Kuka Roboter mit DKP400 und lassen diesen DKP als Drehachse synchron laufen mit dem TCP.

    Interessanterweise läuft beim Kollegen - KRC2 V5.5.5 - die Drehachse immer synchron, bei meinem - KRC2 V4.1.7 SP05 - aber nicht. Das heißt, dass mein Drehtisch kurz stoppt/ kurz langsam wird(vergleichbar Video Kotti Kuka), bei nicht korrekt vorgegebener vel.ptp trotz Überschleifens der Punkte, so als wartet der DKP auf den Robi. Bei mathematischer Kopplung funktioniert alles reibungslos.

    Mein Kollege schreibt einfach eine X und E2 Bewegung und der DKP macht tatsächlich eine kontinuierliche+korrekte Drehgeschwindigkeit abhängig von vel.cp über das Inlineformular lt. seiner Aussage. Ich bin mir nur nicht sicher ob es wirklich so feingestuft ist aber zumindest dreht er kontinuierlich ohne Geschwindigkeitseinbrüche.

    Ich muss zwingend die EXT_AX[].vel (programmiert ohne Inlineformular) vorgeben, damit diese nicht stoppt/langsam wird aber diese lässt sich gar nicht fein einstellen, nur 0-100% als Integerwert -> ich bräuchte aber Werte dazwischen, das ich meine Schweißgeschwindigkeit korrekt einstellen kann. Das Übel nimmt natürlich zu wenn ich große Durchmesser 300mm und mehr als Bauteil habe. Z.B. wenn die TCP-Geschwindigkeit am Bauteilaußendurchmesser mal 1000 mm/min und mal 1100 mm/min haben soll (ja ich rechne alles um das die m/s für den Robi vorgegeben werden) dann sind Einstellungen, nur mal angenommen zwischen 4-5%, der externen Achse notwendig.

    Mich wundert auch wo das Inlineformular beim Kollegen die Geschwindigkeit so genau definiert, thereotisch doch im BAS() aber dort ist der Wert genauso 0-100% Integer und die Programmstruktur in BAS() gleich bis auf Meldungserweiterung.


    Asynchron schalten der Achsen geht grundsätzlich auch für Drehachse, löst auch vollständig das Problem mit dem Ruckeln. Aber die Anwenderfreundlichkeit für uns ist begrenzt, gerade wenn man an bestimmten Punkten schalten will -> Forschungsinstitut mit ständig wechselnden Bedingungen.


    Ich hatte das Forum schon ein Zeit studiert aber habe noch keinen passenden Thread dazu gefunden. Bitte Bescheid geben wenn das Thema hier falsch gewählt ist oder doch schon gelöst wurde.


    Im Datei Anhang sind gekürzte Roboterarchive, für einen genaueren Blick.


    Falls jemand Ideen hat, bin ich über jeden Gedanken dankbar :merci: .

Erstelle ein Benutzerkonto oder melde dich an um zu kommentieren

Du musst ein Benutzerkonto haben um einen Kommentar hinterlassen zu können

Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen. Geht einfach!
Neues Benutzerkonto erstellen
Anmelden
Du hast bereits ein Benutzerkonto? Melde dich hier an.
Jetzt anmelden