Beiträge von AHZG

Das Problem hat sich erledigt. Wenn der Roboter auf HALT steht, werden die Ausgänge nicht aktualisiert ...

Moin,

schon einmal vielen Dank für das Feedback. Das Programm ist jetzt lauffähig, tut aber noch nicht was es soll ...

Signalvereinbarung als Regelglied ist mir kein Begriff. In welcher Anleitung wird das erklärt?

Die Begrenzung durch die Angabe von Maximal- und Minimalspannung ist für meinen Fall nützlich, da ich so theoretisch einstellen kann, dass die Ausgabe nur geändert wird, wenn das Signal am Eingang einen bestimmten Wertebereich verlässt. Bei der EA-Verschaltung in WoV gibt es keine Möglichkeit die Werte umzurechnen, wie es bei ANOUT der Fall ist, oder?

Ich habe dazu noch ein Minimalbeispiel programmiert:

DEF testAninAnout ( )

SIGNAL TESTIN $ANIN[2]
TESTINVAR = 0.0

;FOLD INI;%{PE}
  ;FOLD BASISTECH INI
    GLOBAL INTERRUPT DECL 3 WHEN $STOPMESS==TRUE DO IR_STOPM ( )
    INTERRUPT ON 3 
    BAS (#INITMOV,0 )
  ;ENDFOLD (BASISTECH INI)
  ;FOLD USER INI
    ;Make your modifications here
  ;ENDFOLD (USER INI)
;ENDFOLD (INI)
;FOLD SPTP HOME Vel=100 % DEFAULT ;%{PE}
;FOLD Parameters ;%{h}
;Params IlfProvider=kukaroboter.basistech.inlineforms.movement.spline; Kuka.IsGlobalPoint=False; Kuka.PointName=HOME; Kuka.BlendingEnabled=False; Kuka.MoveDataPtpName=DEFAULT; Kuka.VelocityPtp=100; Kuka.VelocityFieldEnabled=True; Kuka.CurrentCDSetIndex=0; Kuka.MovementParameterFieldEnabled=True; IlfCommand=SPTP
;ENDFOLD
SPTP XHOME WITH $VEL_AXIS[1] = SVEL_JOINT(100.0), $TOOL = STOOL2(FHOME), $BASE = SBASE(FHOME.BASE_NO), $IPO_MODE = SIPO_MODE(FHOME.IPO_FRAME), $LOAD = SLOAD(FHOME.TOOL_NO), $ACC_AXIS[1] = SACC_JOINT(PDEFAULT), $APO = SAPO_PTP(PDEFAULT), $GEAR_JERK[1] = SGEAR_JERK(PDEFAULT), $COLLMON_TOL_PRO[1] = USE_CM_PRO_VALUES(0)
;ENDFOLD


ANIN ON TESTINVAR = 1.0 * TESTIN + 0.0

ANOUT ON CHANNEL_10 = 1.0 * TESTINVAR + 0.0


HALT


;FOLD SPTP HOME Vel=100 % DEFAULT ;%{PE}
;FOLD Parameters ;%{h}
;Params IlfProvider=kukaroboter.basistech.inlineforms.movement.spline; Kuka.IsGlobalPoint=False; Kuka.PointName=HOME; Kuka.BlendingEnabled=False; Kuka.MoveDataPtpName=DEFAULT; Kuka.VelocityPtp=100; Kuka.VelocityFieldEnabled=True; Kuka.CurrentCDSetIndex=0; Kuka.MovementParameterFieldEnabled=True; IlfCommand=SPTP
;ENDFOLD

SPTP XHOME WITH $VEL_AXIS[1] = SVEL_JOINT(100.0), $TOOL = STOOL2(FHOME), $BASE = SBASE(FHOME.BASE_NO), $IPO_MODE = SIPO_MODE(FHOME.IPO_FRAME), $LOAD = SLOAD(FHOME.TOOL_NO), $ACC_AXIS[1] = SACC_JOINT(PDEFAULT), $APO = SAPO_PTP(PDEFAULT), $GEAR_JERK[1] = SGEAR_JERK(PDEFAULT), $COLLMON_TOL_PRO[1] = USE_CM_PRO_VALUES(0)
;ENDFOLD
END

Ich weiß, dass am Eingang [3] eine leicht schwankende Spannung anliegt und hätte daher erwartet, dass diese einfach an den Ausgang[10] durchgereicht wird. Am Ausgang[10] kommt jedoch nichts an. In unserer config.dat ist

SIGNAL CHANNEL_10 $ANOUT[10] definiert.

Beste Grüße und Vielen Dank

Wurden die DIGIN-Anweisungen durch etwas anderes ersetzt oder stehen jetzt nur noch die ANIN-Anweisungen zur Verfügung?

Beste Grüße

Liebe Roboterexperten,

ich möchte ein digitales input-Signal nutzen, um einen analogen Ausgang zu steuern. Das ganze soll kontinuierlich während eines Schweißprozesses genutzt werden, um den Prozess zu steuern.

Unsere Steuerung ist eine KRC4 mit Version 8.5.7.453 HF1

Folgenden Code habe ich geschrieben, um die Funktionalität zu testen:

DEF  TestDiginMotorstrom ( )

SIGNAL MOTORSTROMSIGNAL $IN[201] to $IN[216]

SIGNAL DRAHTGESCHWINDIGKEIT $ANOUT[9]

LEERLAUFSTROM = 70
GRENZSTROM = 100
K_DRAHT = -0.01
DRAHT_SOLL = 0.1

DRAHT_MIN = DRAHT_SOLL * 0.5
OFFSETSTROM = GRENZSTROM * K_DRAHT + DRAHT_SOLL

;FOLD INI;%{PE}
;FOLD BASISTECH INI
GLOBAL INTERRUPT DECL 3 WHEN $STOPMESS==TRUE DO IR_STOPM ( )
INTERRUPT ON 3
BAS (#INITMOV,0 )
;ENDFOLD (BASISTECH INI)
;FOLD USER INI
;Make your modifications here

;ENDFOLD (USER INI)
;ENDFOLD (INI)

;FOLD SPTP HOME Vel=100 % DEFAULT ;%{PE}
;FOLD Parameters ;%{h}
;Params IlfProvider=kukaroboter.basistech.inlineforms.movement.spline; Kuka.IsGlobalPoint=False; Kuka.PointName=HOME; Kuka.BlendingEnabled=False; Kuka.MoveDataPtpName=DEFAULT; Kuka.VelocityPtp=100; Kuka.VelocityFieldEnabled=True; Kuka.CurrentCDSetIndex=0; Kuka.MovementParameterFieldEnabled=True; IlfCommand=SPTP
;ENDFOLD
SPTP XHOME WITH $VEL_AXIS[1] = SVEL_JOINT(100.0), $TOOL = STOOL2(FHOME), $BASE = SBASE(FHOME.BASE_NO), $IPO_MODE = SIPO_MODE(FHOME.IPO_FRAME), $LOAD = SLOAD(FHOME.TOOL_NO), $ACC_AXIS[1] = SACC_JOINT(PDEFAULT), $APO = SAPO_PTP(PDEFAULT), $GEAR_JERK[1] = SGEAR_JERK(PDEFAULT), $COLLMON_TOL_PRO[1] = USE_CM_PRO_VALUES(0)
;ENDFOLD

$ADVANCE = 1

DIGIN ON MOTORSTROMVAR = 1 * MOTORSTROMSIGNAL + 0
ANOUT ON DRAHTGESCHWINDIGKEIT = K_DRAHT * MOTORSTROMVAR + OFFSETSTROM MINIMUM = DRAHT_MIN MAXIMUM = DRAHT_SOLL

PULSE($OUT[31], FALSE, 0.1)
PULSE($OUT[32], FALSE, 0.1)
WAIT SEC 1
$OUT[33]=TRUE
HALT
$OUT[33]=FALSE

DIGIN OFF MOTORSTROMVAR
ANOUT OFF DRAHTGESCHWINDIGKEIT

;FOLD SPTP HOME Vel=100 % DEFAULT ;%{PE}
;FOLD Parameters ;%{h}
;Params IlfProvider=kukaroboter.basistech.inlineforms.movement.spline; Kuka.IsGlobalPoint=False; Kuka.PointName=HOME; Kuka.BlendingEnabled=False; Kuka.MoveDataPtpName=DEFAULT; Kuka.VelocityPtp=100; Kuka.VelocityFieldEnabled=True; Kuka.CurrentCDSetIndex=0; Kuka.MovementParameterFieldEnabled=True; IlfCommand=SPTP
;ENDFOLD
SPTP XHOME WITH $VEL_AXIS[1] = SVEL_JOINT(100.0), $TOOL = STOOL2(FHOME), $BASE = SBASE(FHOME.BASE_NO), $IPO_MODE = SIPO_MODE(FHOME.IPO_FRAME), $LOAD = SLOAD(FHOME.TOOL_NO), $ACC_AXIS[1] = SACC_JOINT(PDEFAULT), $APO = SAPO_PTP(PDEFAULT), $GEAR_JERK[1] = SGEAR_JERK(PDEFAULT), $COLLMON_TOL_PRO[1] = USE_CM_PRO_VALUES(0)
;ENDFOLD

END

DEFDAT TestDiginMotorstrom
;FOLD EXTERNAL DECLARATIONS;%{PE}%MKUKATPBASIS,%CEXT,%VCOMMON,%P
;FOLD BASISTECH EXT;%{PE}%MKUKATPBASIS,%CEXT,%VEXT,%P
EXT  BAS (BAS_COMMAND  :IN,REAL  :IN )
DECL INT SUCCESS

DECL REAL MOTORSTROMVAR
DECL REAL LEERLAUFSTROM
DECL REAL OFFSETSTROM
DECL REAL K_DRAHT
DECL REAL GRENZSTROM
DECL REAL DRAHT_SOLL
DECL REAL DRAHT_MIN

;ENDFOLD (BASISTECH EXT)
;FOLD USER EXT;%{E}%MKUKATPUSER,%CEXT,%VEXT,%P
;Make your modifications here

;ENDFOLD (USER EXT)
;ENDFOLD (EXTERNAL DECLARATIONS)
ENDDAT

In Work Visual sieht das ganze sauber aus. Wenn ich das auf die Steuerung lade, bekomme ich jedoch Syntaxfehler "2309 "(" erwartet" in der .src in den Zeilen mit "DIGIN ON" und "DIGIN OFF" angezeigt. Hat jemand eine Idee, woran das liegt?

Ein paar Bedenken habe ich noch bei der Umwandlung der INT Zahl bestehend aus den Eingängen 201-216 in eine REAL. Die Variablenanzeige am Roboter für MOTORSTROMSIGNAL stimmte aber gut mit der Anzeige am Preripheriegerät überein. Gibt es da Fälle unter denen es zu Abweichungen kommen kann?

Beste Grüße

Zitat von Programmiersklave

Ich denke nicht, dass das "Problem" innerhalb der Kreisbewegung auftritt. Es dürfte an der Stelle kommen, wenn der TCP den Kreis verlässt. Er kommt aus dem Bogen mit {a 180} raus und muss LIN wieder auf den nächsten Punkt mit {a 0}. Und jetzt kommt es eben darauf an, ob die Realität 179.99 lautet oder -179,99 - bei LIN interessieren ihn S und T nicht, er will gleichmäßig und kurz zum Ziel interpolieren. Du müsstest vielmehr auf der Strecke zwischen dem Ausgang des Kreises und dem nächsten LIN-Punkt einen Zwischenpunkt mit definierter Orientierung haben, um das zu vermeiden.

Es ist wie beim Totpunkt einer Dampfmaschine, es ist eine Form der Singularität. Orientierungen aufeinander folgender Punkte in LIN, die sich exakt gegenüberliegen, sind böse, Du musst Dein Offline-Programmiersystem dazu erziehen, solche nicht zuzulassen.

Grüße,

Michael

Alles anzeigen

In diesem Programm ist der Winkel A an allen Positionen 0. Es gibt keine Punkte mit gegenüberliegender Orientierung. Es soll eine Umorientierung relativ zur Bahn, aber nicht relativ zum Werkstückkoordinatensystem geschehen. Die ungewollte Umorientierung beginnt auch mit Beginn der CIRC-Bewegung und nicht nach Abschluss der CIRC-Bewegung.

Grüße

AHZG

Martin Huber: Die Verwendung von ori_type=joint wollte ich eigentlich vermeiden, da dort die Anstellung des Werkzeuges zur Bahn nicht klar definiert interpoliert wird.

fubini: Der Roboter befindet sich während der Bewegung weit weg von Singularitäten. Mit Ungesund meine ich, dass der Roboter während der CIRC-Bewegung das Werkzeug um 180° um die Stoßrichtung drehen und dabei sogar in den Endschalter fahren will. Das ganze dann mit maximaler Geschwindigkeit und Beschleunigung wenn diese nicht durch den Testmodus begrenzt sind ...

Programmiersklave: Viele Dank für den Hinweis. Ich werde das mit der "Bauchigkeit" testen. In unserer Applikation haben wir die Möglichkeit den maximalen Winkel von Kreisbewegungen zu begrenzen, sodass größere Winkel dann durch mehrere Kreisbewegungen zusammengesetzt werden. Das sollte das Problem dann hoffentlich vermeiden.

Hallo Hermann, vielen Dank für deine Antwort. Das ist auch die Übergangslösung, die ich aktuell verwende. Allerdings gibt es auch Programme, bei denen die pfadbezogene Interpolation der Werkzeugorientierung wichtig ist. Daher hoffe ich, dass jemand die tatsächlich Ursache für das Verhalten kennt.

Hallo an alle,

der Roboter, mit dem ich arbeite ist ein KR30HA. Der machine.dat habe ich die Versionsmummer 8.3 entnommen.

Ich arbeite mit einer CAM-Software, welche Programme in KRL-Syntax ausgiebt.

Bei dem folgenden Programm führt der Roboter in der zweiten CIRC-Bewegung eine sehr ungesunde Umorientierung des Werzeuges aus.

&ACCESS RVP
&REL 113
&COMMENT Erstellt am: 08.12.2020 / 09:17:36
&PARAM EDITMASK = *
&PARAM TEMPLATE = C:\KRC\Roboter\Template\vorgabe
&PARAM DISKPATH = KRC:\R1\Program
DEF C185( )

;---------HEADER---------
; Initialisierung Programm
;FOLD INI;%{PE}
;FOLD BASTECH INI
GLOBAL INTERRUPT DECL 3 WHEN $STOPMESS==TRUE DO IR_STOPM ()
INTERRUPT ON 3
BAS (#INITMOV,0)
;ENDFOLD (BASTECH INI)
;FOLD USER INI
;Make your modifications here

;ENDFOLD (USER INI)
;ENDFOLD (INI)

;FOLD PTP HOME2 Vel=10% Default;%{PE}%R 5.2.30,%MKUKATPBASIS,%CMOVE,%VPTP,%P 1:PTP, 2:home, 3:, 5:10, 7:DEFAULT
$BWDSTART = FALSE
PDAT_ACT=PDEFAULT
LDAT_ACT=LDEFAULT
FDAT_ACT=FHOME
BAS(#VEL_PTP,10)
PTP XHOME2
;ENDFOLD

$Base= $World
$Base= Base_data[3]
$Tool= Tool_data[4]
$CIRC_TYPE= #PATH
$ORI_TYPE= #VAR

$APO.CVEL=100
$VEL_EXTAX[1] = 100
$VEL_EXTAX[2] = 100
$ACC_EXTAX[1] = 100
$ACC_EXTAX[2] = 100

$VEL.CP=0.05

LIN {X 11.5, Y 24.28, Z 50.0, A 0, B 0, C 0, S 6, T 27} C_VEL
$VEL.CP=0.025
LIN {X 11.5, Y 24.28, Z 0.0, A 0, B 0, C 0, S 6, T 27} C_VEL
$VEL.CP=0.0083333
TRIGGER WHEN DISTANCE=1 DELAY=0 DO $OUT[33]=TRUE
$ANOUT[9]=0.15 ;3.0 m/min
TRIGGER WHEN DISTANCE=1 DELAY=0 DO $OUT[8]=TRUE
LIN {X 11.5, Y 32.28, Z 0.0, A 0, B 0, C 0, S 6, T 27} C_VEL
LIN {X 11.5, Y 34.28, Z 0.0, A 0, B 0, C 0, S 6, T 27} C_VEL
$VEL.CP=0.0041667
LIN {X 11.5, Y 78.5, Z 0.0, A 0, B 0, C 0, S 6, T 27} C_VEL
CIRC { X 10, Y 80, Z 0}, { X 8.5, Y 78.5, Z 0.0 , A 0, B 0, C 0, S 6, T 27} C_VEL
LIN {X 8.5, Y 11.5, Z 0.0, A 0, B 0, C 0, S 6, T 27} C_VEL
CIRC {X 10.26, Y 10.02, Z 0.0},{ X 11.5, Y 11.5, Z 0.0 , A 0, B 0, C 0, S 6, T 27} C_VEL
TRIGGER WHEN DISTANCE=1 DELAY=0 DO $OUT[33]=FALSE
TRIGGER WHEN DISTANCE=1 DELAY=1000 DO PULSE($OUT[35],FALSE,0.1)
TRIGGER WHEN DISTANCE=1 DELAY=1000 DO PULSE($OUT[32],TRUE,0.1)
LIN {X 11.5, Y 34.28, Z 0.0, A 0, B 0, C 0, S 6, T 27} C_VEL
$VEL.CP=0.0083333
TRIGGER WHEN DISTANCE=1 DELAY=0 DO $OUT[8]=FALSE
LIN {X 11.5, Y 35.28, Z 0.0, A 0, B 0, C 0, S 6, T 27} C_VEL
LIN {X 11.5, Y 44.28, Z 0.0, A 0, B 0, C 0, S 6, T 27} C_VEL
$VEL.CP=0.025 ;Geschwindigkeit
LIN {X 11.5, Y 44.28, Z 50.0, A 0, B 0, C 0, S 6, T 27} C_VEL

;Automatically generated PTP movement
;FOLD PTP HOME2 Vel=10% Default;%{PE}%R 5.2.30,%MKUKATPBASIS,%CMOVE,%VPTP,%P 1:PTP, 2:home, 3:, 5:10, 7:DEFAULT
$BWDSTART = FALSE
PDAT_ACT=PDEFAULT
LDAT_ACT=LDEFAULT
FDAT_ACT=FHOME
BAS(#VEL_PTP,10)
PTP XHOME2
;ENDFOLD

END

Wenn ich die Werte des Hilfspunktes der zweiten CIRC-Bewegung auf die glatten Werte X 10.0 und Y 10.0 ändere findet keine Änderung der Orientierung statt. Genauso bewegt sich der Roboter wie erwartet ohne Umorientierung, wenn ich die Zeile mit CIRC_TYPE=PATH auskommentiere.

Hat jemand eine Idee, was genau das unerwartete Verhalten auslösen könnte und wie man überprüfen kann, dass so etwas nicht auftritt. Die Programme, die über die CAM-Software generiert werden haben eine recht lange Laufdauer und müssen für die Optmierung in mehrere Schritten geringfügig angepasst werden. Diese jedes Mal im Testmodus Probe zu fahren wäre mit einem nicht unerheblichem Zeitaufwand verbunden.

Über eure Antworten freue ich mich sehr.

AHZG

Moin, vielen Dank für die schnelle Antwort und die Hinweise. Das werde ich so schnell wie möglich überprüfen. Hier sind noch die Daten der externen Basen:

MACHINE_DEF[2]={NAME[] "DKP-400_1_40A",COOP_KRC_INDEX 1,PARENT[] "WORLD",ROOT {X 1419.01038,Y -697.305298,Z -29.2460022,A -120.700386,B 0.321472496,C -0.189314902},MECH_TYPE #EASYS,GEOMETRY[] "ObjectId = -749085527"}

BASE_DATA[17]={X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0}

Von Hand funktioniert das Verfahren in der externen Basis. Wenn die externen Achsen in Base 17 verfahren werden, bewegt sich das Werkzeugt mit und behält seine orientierung relativ zum Tisch

Moin moin,

in meinem Unternehmen betreiben wir einen Kukaroboter mit einem Schweißwerkzeug und einen DKP, der das Werkstück positioniert. Hierbei sollen der DKP und der Roboter zusammenarbeiten, um die optimale Orientierung des Werkzeuges im Prozess zu gewährleisten. Die Programmierung erfolgt über eine CAD/CAM Software, die einen KRL-Code erzeugt, welcher dann auf der Steuerung installiert wird. Bei gekrümmten Pfaden, entlang denen die Werkzeugorientierung Pfadbezogen konstant gehalten werden, wird dies eigentlich durch hohe Geschwindigkeiten des DKPs erreicht. Wenn die Punktabfolgen „geteached“ werden, bewegt der DKP sich auch mit entsprechender Geschwindigkeit. In den programmierten Bewegungen schleicht der DKP jedoch vor sich hin und das Werkzeug steht während der Kurve quasi auf einer Stelle über dem Werkstück. Das heißt die Relativgeschwindigkeit zwischen Werkstück und TCP stimmt nicht. Da die Geschwindigkeit der TCP Bewegung in Weltkoordinaten mit der vorgegebenen zu stimmen scheint, jedoch nicht in dem mitbewegten Koordinatensystem des DKP, gehen wir davon aus, dass die Problematik in der Anwahl des richtigen Koordinatensystems liegt. Wie bekommen wir nun also der Steuerung über den KRL-Code mitgeteilt, in welchem Koordinatensystem sie die Geschwindigkeit berechnen soll?

Anbei habe ich Auszüge aus den Codes beigefügt. Über Anregungen oder Lösungsvorschläge würde ich mich sehr freuen.

VG

TTamredo

geteached.dat.txt

geteached.src.txt

KRL_Syntax.src.txt