Beiträge von doc_rob

Ja ich weiß, aber es ist gut dass du meine Einschätzung teilst

Wir sind gerade am suchen neben der Produktion. Haben auch schon Situationen nachgestellt, das Problem tritt aber nicht immer auf. Wir tracen aktuell auf Roboter- sowie SPS Seite die Variablen die in Frage kommen. Ich melde mich mit einem Ergebnis.

Hallo an alle,

Ich habe folgendes Problem (KRC4, KSS 8.6.x):

Ich muss bei einigen Bewegungen auf zwei Ereignisse reagieren können: Einmal auf "Bauteil gegriffen" und einmal auf "Kollision". Die Signale können auch gleichzeitig auftreten und werden in separaten Interrupts abgearbeitet.

Wenn beide Fälle gleichzeitig auftauchen hat die Reaktion auf die Kollision Vorrang (niedrigere Prio Zahl). Die Bauteilaufnahme wird abgebrochen und ein Rückzug ausgelöst.

Sobald ich jedoch wieder in dasselbe Programm springe und die beiden genannten Interrupts aktiviere, wird das Interrupt Programm "Bauteil gefunden" ausgeführt.

Da ich in den beiden Interrupts den jeweils anderen mitabschalte (mit Interrupt OFF xx), gehe ich davon aus, dass der Merker mitgelöscht wird. Es steht auch so ähnlich in der Kuka Doku, wenn auch im Kapitel für Enable/Disable:

"Wenn ein gesperrter Interrupt nicht mehr freigegeben wird, sondern deaktiviert

wird (d. h., nach INTERRUPT DISABLE kommt INTERRUPT OFF),

löscht dies den Merker für das Ereignis. Wenn der Interrupt danach wieder

aktiviert wird, reagiert er erst wieder auf ein neues Ereignis."

Habt ihr eine Idee woran das liegen kann?

Die Interrupts mit diesen Prioritäten gibt es aufgrund der Komplexität der Anwendung jeweils über 70 Mal in dem Projekt, sie sind aber natürlich nicht gleichzeitig aktiv.

Danke

DEF MAIN()

INTERRUPT DECL 30 WHEN Kollision == FALSE DO IP001_Rueckzug()
INTERRUPT OFF 30
INTERRUPT DECL 31 WHEN TeilGefunden == FALSE DO IP002_Freifahren()
INTERRUPT OFF 31

;Programm...

END

DEF Programm()

INTERRUPT ON 30
INTERRUPT ON 31

;Fahre zu Bauteil

WAIT SEC 0

INTERRUPT OFF 30
INTERRUPT OFF 31

END
DEF IP001_Rueckzug()

BRAKE

INTERRUPT OFF 30
INTERRUPT OFF 31

RueckzugsProgramm()

RESUME

END

DEF IP002_Freifahren()

BRAKE

INTERRUPT OFF 30
INTERRUPT OFF 31

RESUME

END

Vielen Dank für euren Input! Mir ist nun klar, dass wir $on_path anscheinend missbräuchlich verwenden.

Wir werden uns etwas einfallen lasen für diesen Fall.

Ab wann wäre $on_path wieder TRUE nach einem Interrupt mit Resume? Sobald sich die geplante Bahn wieder mit der aktuellen Position deckt?

lg

Hallo Martin,

Danke für deinen Input, habe es soeben probiert:

einmal indem ich $POS_INT um 10mm transformiert habe, und einmal indem ich $Base um 10mm transformiert habe.

Leider wird $ON_PATH noch immer False

Mich würde interessieren wie $ON_PATH gebildet wird und was die genaue Definition von "am Pfad" bzw. "Pfad verlassen" ist.

lg,

doc_rob

Hallo Kollegen,

wir haben hier ein unangenhmes verhalten von einem Roboter (KRC4, KSS 8.6x), wobei wir die Systemvariable $ON_PATH für die Job Vergabe von der übergeordneten SPS aus nutzen.

Bei einem Interrupt (normales Brake ohne F) mit einer kurzen LIN_REL Bewegung und anschließendem RESUME wird die Systemvariable $ON_PATH jedoch FALSE, was die SPS bei ihrer Auftragsvergabe irritiert.

Meine Fragen:

- ist dieses Verhalten normal bzw. so gewollt? Verlässt der Roboter hier tatsächlich seine Bahn?

-Habt ihr hier einen Lösungsvorschlag bzw. Workaround?

Danke und lg,

doc_rob

BRAKE

INTERRUPT OFF 30

INTERRUPT OFF 25

LIN_REL {Z -10.0} #TOOL

PULSE ( oSaugerAus, true, 0.5 )

WAIT SEC 0.5

PULSE ( oAbblasen, true, 1)

RESUME

Leider konnten wir die dynamischen Bases trotz Kuka Support (D) nicht zum Laufen bekommen.

Die Kuka Techniker aus AT haben uns folgenden Weg vorgeschlagen:

BASE_DATA[32] = BASE_DATA[12] ;geteachte Basis auf freien Platz kopieren
BASE_DATA[32].X = BASE_DATA[12].X + $ROBROOT_C.X ;geteachte Basis um die Position des Roboters auf der Linearachse verschieben

hierbei muss man jedoch drauf achten, dass man die Base Verschiebung zum richtigen Zeitpunkt durchführt. Eine echte dynmische Base ist das meines erachtens nicht.

Wir haben dafür wirklich Zeit investiert und ich denke, ich habe alle Kombinationen durchgetestet.

War da etwas enttäuscht, dass auch Kuka selbst uns nicht wirklich helfen konnte, obwohl das Tool für die Lösung ja eigentlich vorhanden ist (EO Treiber).

lg

ok, Problem scheint gelöst zu sein, mit der "neuen" Funktion EO Treiber klappt das über Workvisual.

Siehe Doku:

"Konfiguration von Kinematiken

Für KUKA System Software 8.5

Montage- und Betriebsanleitung

KUKA Roboter GmbH

Stand: 05.04.2017"

ab Seite 24.

Muss es zwar erst testen, aber ich glaub das passt

lg

Hallo fubini

ich habe hier 18 Base Koordinatensysteme, die ich auf einer KL mitnehmen muss, und probiere gerade deinen Vorschlag aus.

Hier der Ausschnitt aus der Mada:

INT $EX_AX_NUM=1 ;ANZAHL EXTERNER ACHSEN (0-6)

INT $EX_AX_ASYNC='B0000' ;EXTERNE ACHSEN ASYNCHRON

INT $ASYNC_T1_FAST='B0000' ;GESCHW.-RED. DEAKTIVIERT ( T1 )

DECL EX_KIN $EX_KIN={ET1 #ERSYS,ET2 #EASYS,ET3 #NONE,ET4 #NONE,ET5 #NONE,ET6 #NONE} ;EXTERNE KINEMATIKEN #NONE,#EASYS,#EBSYS,#ECSYS,#EDSYS,#EESYS,#EFSYS,#ERSYS

DECL ET_AX $ET1_AX={TR_A1 #E1,TR_A2 #NONE,TR_A3 #NONE} ;EXTERNE ACHSEN #NONE, #E1, #E2, #E3, #E4, #E5, #E6

CHAR $ET1_NAME[20] ;NAME DER TRANSFORMATION ET1 MAXIMAL 20 ZEICHEN

$ET1_NAME[]="KL4000_Q_40"

FRAME $ET1_TA1KR={X 0.0,Y 0.0,Z 1089.00,A 0.0,B -90.0000,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 -90.0000,B 90.0000,C -90.0000} ;ZWISCHEN FL UND A3

FRAME $ET1_TPINFL={X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0} ;ZWISCHEN MESSPUNKT UND FL

DECL ET_AX $ET2_AX={TR_A1 #E1,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[]="mitfahrende_Basis"

FRAME $ET2_TA1KR={X 0.0,Y 0.0,Z 1089.00,A 0.0,B -90.0000,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 -90.0000,B 90.0000,C -90.0000} ;ZWISCHEN FL UND A3

FRAME $ET2_TPINFL={X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0} ;ZWISCHEN MESSPUNKT UND FL

Nun meine Fragen:

-Muss ich die Anzahl der externen Achsen von 1 auf 2 erhöhen?

-Ich habe den Fußpunkt der #EASYS gleich gewählt, wie die Linearachse, ist das korrekt?

-Wie kann ich nun meine 18 Bases auf der #EASYS definieren? Sonst haben wir das immer geführt bei der Fußpunktvermessung zugewiesen, was hier ja nicht der Fall ist.

Ich bin morgen wieder an der Anlage und werde testen.

Vielen Dank schonmal!

lg

Danke Woodys!

Ich probiere das gerade aus, muss nur Werte finden die für TORQ_DIFF passen... ich melde mich wieder sobald ich was weiß.

Gruß!

Ja, habe ein kleines Testprogramm um eine (sanfte) Kollision zu provozieren.

Hatte das mit dem manuell 0 setzen irgendwie ausgeblendet, mein Fehler!

Die Funktion zeigt nun das gewohnte Verhalten, also geht hoch von 0 und bleibt am Maximalwert hängen.

Ich muss nun sicherstellen, dass der Maximalwert bei der Kollision auftritt...ihr hört von mir!

Danke erstmal!

Hallo Robomann,

leider wird die Variable $COLLMON_MAX[] nur verwendet wenn $IMPROVED_COLLMON== TRUE gesetzt ist....was bei dem vorhanden (und recht umfangreichen) Programm nicht der Fall ist

In der Doku für Systemintegratoren scheint $COLLMON_MAX[] auch erst ab KSS 8.5 auf...hast du das in Kombination mit SET_TQ_VALUES{} verwenden können?

Danke trotzdem für den Input!

Hallo SJX,

vielen Dank für deinen Input!

$IMPROVED_COLLMON ist ohnehin auf FALSE, da sonst SET_TQ_VALUE nicht verwendet werden kann, lt. Doku.

Leider bleiben dann die Werte von $TORQ_DIFF[] immer unverändert, also fix. Habs gerade ausprobiert mit verschiedenen Geschwindigkeiten, Betriebsarten und Kollisionen.

Im Logbuch kann man die ausgestiegene Achse schön bestimmen...ich muss die Info nur irgendwie automatisch an die SPS bringen...

Gruss

Hallo,

ich kann nun die Kollisionsmeldung identifizieren (anhand der Meldungsnummer 1131) und Maßnahmen einleiten.

Allerdings kann ich noch nicht die auslösende Achse bestimmen.

-> die Funktion MBX_REC speichert leider keinen Meldungstext...kann man Meldungstexte überhaupt auslesen?

Hat da jemand einen Tipp für mich?

Ich benutze eine ähnliche Funktion regelmäßig, und kann bestätigen, dass das nur mit $POS_INT verlässlich funktioniert.

Hast du schnelle Messeingänge am Roboter?

Ist dein Lichttaster nicht der langsamste?

Ansonsten einfach mit der Geschwindigkeit spielen um die Genauigkeit zu erhöhen.

Hallo,

habe hier einen KR240 mit KSS 8.5 und einem fremden Roboterprogramm, welches noch den SET_TQ_VALUES Befehl zur Kollisionserkennung nutzt ->> funktioniert.

Wie kann ich im Nachhinein automatisch herausfinden, welche Achse die Kollisionserkennung ausgelöst hat?

- Muss ich da auf den Meldungstext der Quittiermeldung zugreifen, oder gibts da was eleganteres?

- In gefährlichen Bereichen für die Maschine wird eine automatische Quittierung eingesetzt. Kann ich die Meldung auch nach dem Quittieren noch lesen, oder muss ich sicherstellen, dass die Meldung erst gelesen und dann autom. quittiert wird?

Danke!

Gruß

10m/s werden schwer zu erreichen sein, wenn ich da die Achsgeschwindigkeiten im Kuka Portfolio ansehe.

Die Beschleunigung wird für die Kamera vermutlich auch reduziert werden müssen (Vibrationen / verwackeln), oder?

Gruß

Das kommt darauf an welche KSS Version man hat, deshalb meine Frage... für die 8.5 gibts Profinet 4.1, dann braucht man die GSDML 2.33

Welche KSS Version hat der Roboter?

Hast du die Kuka Doku genau gelesen und befolgt? Am besten bei Kuka Xpert den Gratis Account erstellen und die KSS8x SI Doku (für Systemintegratoren) runterladen.

Wir nutzen nur TIA und das hat immer funktioniert, Safety ID war glaub ich 7 standardmäßig.

Ja, check alle Leitungen im Drehtisch. Wenn man eine Achse absteckt sieht es genau so aus (Motor + Geber Leitung).

Zitat von KRCGreenhorn

Danke! Genau danach habe ich gesucht Jetzt habe ich dazu nur noch eine Frage und zwar gibt es eine Möglichkeit dieses Backup der Position auch im Hauptprogramm aufzurufen? Oder muss das Lokal im Unterprogramm geschehen in der die Position abgelegt ist?

Es kommt darauf an wo wie Variable abgespeichert ist, die du ändern willst.

Wenn du die E6Pos die du im DAT. File des Hauptprogramms deklariert hast beschreiben willst, dann kannst du das im HP und in lokalen UP machen (lokales UP: nach der END Zeile des HP, im selben SRC File!)

Hast du ein Unterprogramm in einem eigenen, getrennten SRC File erstellt, dann musst du die Variablen die du in beiden Programmen manipulieren willst global deklarieren (z.B. in der config.dat, da gibt es ein eigenes Plätzchen dafür -> User Globals).

Die Variable und deren Inhalt liegen nicht in einem Programm, sondern im .Dat File (-> Datenliste).

Ein Dat File ist einem SRC File zugeordnet und alles was im SRC File kreucht und fleucht kann auf dieses dazugehörige Dat File zugreifen.

ich hoffe das stimmt alles so...alle Angaben ohne Gewähr

lg

PS: gönn dir doch mal den Programmieren 2 Kurs bei Kuka, der ist wirklich sehr hilfreich!

PPS: hör auf die Kollegen hier, manipuliere nur Kopien der "Originalpunkte". Denn sobald du dein Programm abbrichst bevor du das Pos_backup wieder zurückgeschrieben hast, fährt der Robi beim nächsten Start woanders hin. Ich mach mir für solche Positionen meist ein eigenes Unterprogramm wo die Punkte der Reiche nach liegen, schön kommentiert. Das UP rufe ich nur auf, wenn ich die Positionen wirklich prüfen oder nachteachen will.