Anleitung zur Bewegungs-Programmierung

Hallo allerseits,

ich habe das Problem, dass viele Codebeispiele aus der Dokumentation, z.B. "KSS 8.7 Bedien- und Programmieranleitung für Systemintegratoren", offenbar nicht direkt lauffähig sind, da weitere Variablen gesetzt bzw. Bibliotheksfunktionen aufgerufen werden müssen, um die Steuerung für die Bewegung zu konfigurieren.

Es geht schon mit der bei Programmstart erforderlichen SAK-Fahrt mit PTP los - PTP HOME; verursacht Fehler ("Achsgeschwindigkeit nicht programmiert A1").

Leider finde ich dazu keinerlei Hinweise in der Dokumentation.

Ich versuche daher, den von Inline-Formularen generierten Code nachzuvollziehen (ebenfalls offenbar nicht dokumentiert, z.B. BAS()).

Beispiel:

;FOLD PTP XHOME Vel=100 % PDAT1 Tool[1]:Tool1 Base[0] ;%{PE}
  ;FOLD Parameters ;%{h}
    ;Params IlfProvider=kukaroboter.basistech.inlineforms.movement.old; Kuka.IsGlobalPoint=False; Kuka.PointName=XXHOME; Kuka.BlendingEnabled=False; Kuka.MoveDataPtpName=PDAT1; Kuka.VelocityPtp=100; Kuka.CurrentCDSetIndex=0; Kuka.MovementParameterFieldEnabled=True; IlfCommand=PTP
  ;ENDFOLD
  $BWDSTART = FALSE
  PDAT_ACT = PPDAT1
  FDAT_ACT = FXHOME
  BAS(#PTP_PARAMS, 100.0)
  SET_CD_PARAMS (0)
  PTP XXHOME
;ENDFOLD

• Warum wird aus HOME hier XHOME bzw. XXHOME?
• Welche der Aufrufe müssen vor jedem Bewegungsbefehl erfolgen (oder reicht es einmal für weitere PTPs)?
• Kann ich die Inlineformular-Parameter (und Folds) einfach weglassen?
• Was wäre der "klassische" Weg der Programmierung (d.h. ohne Inlineformulare) und gibt es dazu vollständigere, offizielle Dokumentation bzw. Beispiele?

Nach PTP soll es mit LIN und SCIRC im SPLINE-Block weitergehen...

Ok, danke soweit. Hatte gestern noch ein paar ähnliche Threads gefunden, werde ich morgen bei Gelegenheit verlinken. Das INI hatte ich noch nicht auf dem Schirm - werde ich mir ansehen.

XHOME, weil ich in der config (?) nirgends HOME gefunden habe.

Wenn das ILF ein X vor HOME setzt, passt es ja wieder.

Hab das nirgends in den Dokus gefunden.

"Ich schaff's mit Kuka. Jetzt einfach ..." - naja, wird schon ... irgendwann

Im INI-Fold der "Modul"-Vorlage werden über bas.src die Standardwerte aus $config.dat geladen (und der STOPMESS Interrupt aktiviert):

GLOBAL INTERRUPT DECL 3 WHEN $STOPMESS==TRUE DO IR_STOPM ( )
INTERRUPT ON 3 
BAS (#INITMOV,0 )

Damit bewegt sich schonmal was!

30 Jahre Rückwärtskompatibilität schön und gut - das bedeutet aber auch, dass 30 Jahre Zeit waren, an der Dokumentation zu arbeiten!

Hallo nochmal,

ich habe nun versucht, (in KSS 8.7) die Parameter aus Inlineformularen zu übernehmen und anzupassen, muss dabei aber etwas übersehen: das unten folgende Test-Programm

1. fährt den Spline-Block deutlich schneller als Schrittgeschwindigkeit ab, d.h. die von mir auf 50% reduzierten VEL, ACC und JERK Parameter scheinen keinen Einfluss zu haben (zumindest ist die anfängliche PTP-Bewegung deutlich langsamer)

2. stoppt an tangentialen Übergängen

Ich vermute 1. könnte am Geltungsbereich liegen - benötigt der SPLINE-Block die Parameter als WITH?

Andererseits:

Quote

Die Parameter (Tool, Base, Geschwindigkeit etc.), die dem Spline-

Block zugewiesen werden, wirken sich genauso aus wie Zuweisungen

vor dem Spline-Block.

Welche Parameter/Variablen muss ich setzen, damit im T1 mit der eingestellten, reduzierten Geschwindigkeit gefahren wird?

2. wird ja explizit in der Anleitung erwähnt:

Quote

Aufeinanderfolgende SLIN- und/oder SCIRC-Segmente vermeiden, da

die Geschwindigkeit hierdurch häufig auf 0 reduziert wird.

Zwischen SLIN- und SCIRC-Segmenten SPL-Segmente programmie-

ren. Die Länge der SPL-Segmente muss mindestens > 0,5 mm sein.

Abhängig vom konkreten Bahnverlauf können auch deutlich größere

SPL-Segmente erforderlich sein

Display More

Meine Frage ist, warum ist so ein Workaround nötig, wenn der Vorteil des Spline-Blocks die optimale Bewegungsplanung ist? Sind bei tangentialen Übergängen die Werte (Jerk) nicht besser beherrschbar und berechenbarer als bei allen anderen Übergängen? Wenn ja, warum kann die Steuerung im Zweifel nicht die Geschwindigkeit des SCIRC-Segments auf das vorhergehende SLIN-Segment anwenden, so dass die Grenzwerte nicht überschritten werden?

Der Hintergrund meiner Frage ist, dass ich eine konstante Geschwindigkeit auf dem Pfad benötige.

Hier nun das Programm:

DEF test( )

GLOBAL INTERRUPT DECL 3 WHEN $STOPMESS==TRUE DO IR_STOPM ( )
INTERRUPT ON 3 
BAS (#INITMOV,0 ) ; -> INITMOV(), RESET_CD_PARAMS(), SJERK(LDEFAULT)

;ACC_CP(10)
;$ORI_TYPE = #CONSTANT;
;$CIRC_TYPE = DEF_CIRC_TYP
;$JERK=SJERK(LDEFAULT)

LDAT_ACT = LCPDAT1
FDAT_ACT = FP1
BAS(#CP_PARAMS, 2.0)

PDAT_ACT = PPDAT1
FDAT_ACT = FXXHOME
BAS(#PTP_PARAMS, 100.0)
SET_CD_PARAMS (0)

PTP XXXHOME
PTP {Z 40}

LIN {Z 10}
LIN_REL {X 50, Y 50}

SPLINE
   SCIRC {X  100, Y 0},{X  50, Y -50}
   SLIN_REL {X -50}
   SCIRC {X -100, Y 0},{X -50, Y  50}
   SLIN_REL {X 50}
ENDSPLINE
END

DEFDAT  TEST

EXT  BAS (BAS_COMMAND  :IN,REAL  :IN )
DECL INT SUCCESS

DECL E6POS XXXHOME={X 0,Y 0,Z 500,A 62.8432350,B -3.87019610,C 179.032257,S 18,T 42,E1 0.0,E2 0.0,E3 0.0,E4 0.0,E5 0.0,E6 0.0}
DECL FDAT FXXHOME={TOOL_NO 2,BASE_NO 1,IPO_FRAME #BASE,POINT2[] " "}
DECL PDAT PPDAT1={    VEL 50.000,    ACC 50.000,    APO_DIST 500.000,    APO_MODE #CDIS,    GEAR_JERK 50.000,    EXAX_IGN 0    }
DECL LDAT LCPDAT1 = {CB {AUX_PT {ORI #CONSIDER,E1 #CONSIDER,E2 #CONSIDER,E3 #CONSIDER,E4 #CONSIDER,E5 #CONSIDER,E6 #CONSIDER},TARGET_PT {ORI #INTERPOLATE,E1 #INTERPOLATE,E2 #INTERPOLATE,E3 #INTERPOLATE,E4 #INTERPOLATE,E5 #INTERPOLATE,E6 #INTERPOLATE}},APO_FAC 50.0,APO_DIST 500,AXIS_ACC 50.0,AXIS_VEL 50.0,CIRC_TYP #BASE,JERK_FAC 50.0,ORI_TYP #VAR,VEL 2,ACC 50,GEAR_JERK 50.0,EXAX_IGN 0}
DECL FDAT FP1 = {BASE_NO 1,TOOL_NO 2,IPO_FRAME #BASE,POINT2[] " "}

ENDDAT

Besten Dank!

Hi,

danke für die Hinweise!

Ich möchte es ja direkt programmieren. Aber da ich die "passenden Stellen" noch nicht kenne, wollte ich es mir von den Inlineformularen abschauen... klappt nicht so gut :-/

Das Beispiel aus der Doku für SLIN...

SPLINE WITH $VEL = SVEL_CP(2.0, , LCPDAT2), $TOOL =
STOOL2(FS2), $BASE = SBASE(FS2.BASE_NO), $IPO_MODE =
SIPO_MODE(FS2.IPO_FRAME), $LOAD = SLOAD(FS2.TOOL_NO), $ACC
= SACC_CP(LCPDAT2), $APO = SAPO(LCPDAT2), $ORI_TYPE =
SORI_TYP(LCPDAT2), $CIRC_TYPE = SCIRC_TYP(LCPDAT2), $JERK =
SJERK(LCPDAT2), $COLLMON_TOL_PRO[1] = USE_CM_PRO_VALUES(1)
SLIN {X 1000, Z -1000} WITH $ACC={CP 5.0,ORI1 500.0,ORI2
500.0}
ENDSPLINE C_Spl
Als Einzelsatz:
SLIN {X 1000, Z -1000} C_SPL

... benutzt undokumentierte Funktionen (aus bas.src) und die undefinierte Struktur LCPDAT2.

Wie reduziere ich denn beispielsweise die Geschwindigkeit auf 0.1 m/s?

Kann die Struktur bzw. ihr Attribut .AXIS_VEL im Funktionsaufruf spezifiziert werden?

Analog für Beschleunigung (.ACC) und Ruck (.GEAR_JERK)...

SPLINE WITH $VEL=SVEL_CP(0.1,,?), $ACC=SACC_CP(?), $JERK=SJERK(?)

Gibt es irgendwo Beispielprogramme zum Lernen?

Ich habe gerade erst OfficeLite (KSS auf virtueller Maschine) entdeckt, vielleicht können wir das anschaffen, dann könnte ich besser und schneller mit KRL experimentieren.

Ok, perfekt, danke.

Jetzt sehe ich auch, was da (befürchtungsgemäß) passiert: er hält an jedem Übergang, entweder KSS03173: "Knick in XYZ-Bahn" oder KSS03174: "SLIN-SCIRC-Sequenz".

Dann muss ich da jetzt wirklich überall kurze SPL-Segmente als Workaround einbauen (und so wird es auch bei Dosierungsanwendungen etc. gemacht?)?

Habe die SPLs dazwischengesetzt, und siehe da: er fährt durch.

Ah, ok, ich hatte angenommen, dass das äquivalente "convenience functions" sind... aber wohl nicht.

Ja, dann sehe ich zu, dass ich das ändere!

Danke!