Rückzugprogramm VKRC4

Wann könnte ein solches Ereignis denn eintreffen?

Du kannst - das ist eventuell nicht die eleganteste Lösung und führt je nach Häufigkeit innerhalb eines Programms zur Unübersichtlichkeit - mit Sprungbefehlen arbeiten. Wird ein Fehler festgestellt setzt du z.B. ein Flag (ohne Trockenlauf (F930-959)). Dieses Flag ist dann deine Sprungbedingung. Achtung: Sprungbedingungen können nur im nicht angewählten Programm (Editor) implementiert werden.

Da innerhalb der UPs die erste und die letzte Position meist die Homeposition ist kannst du dir eine kollisionsfrei anzufahrende, zentrale Position zuvor suchen und von dort zur HomePos. Sehr Aufwendig stelle ich mir ein solches Vorhaben bei z.B Schweißprozessen vor, bei denen in die entlegensten Winkel der Karosse verfahren werden muss. Eine solche Strategie ist ohnehin mit einem Projektverantwortlichen von VW abzusprechen.

Viel Erfolg

ja... was immer programmiert ist..

Hi

Du kannst in jeder betriebsart eine rückzugsstrategie anwenden! Ich weiß ja nicht wie du es machst.

Hier im Forum gibt es viele Tipps zum anschauen.

ich mach das zb so dass ich mir 2 Programme erstelle.....einmal ein Hauptprogramm mit der Abbruch Bedingung und ein unterprogramm wo die Logik drin steht. Meine Abbruch bedingung ist ein Eingang bzw. ein taster. Wenn der Eingang kommt kann ich immer zurück ins Hauptprogramm gelangen egal wo man sich befindet! Funktioniert super hab ich mir hier auch abgekupfert!

DEF Hauptprogramm ()

loop

Logik()

Rückzug()

Endloop

End

_______________________
DEF Logik ()

loop

Dauerschleife für das arbeitsprogramm

endloop

end

Wenn du jetzt in der dauerschleife abbrechen möchtest gelangst du in das Hauptprogramm und machst den Rückzug und fängst von vorne an.

Ich hoffe ich konnte etwas helfen.

grüsse

Hi, ist schon etwas aufwendiger bei der VKRC.

Du müsstest bei jeder Position in der Punkt-SPS einen Binär-Ausgang (Art Positionsregister) mit einer Punktnummer beschreiben, damit du weist wo der Roboter steht.

Vorher würde ich die Anlage mit Postionsnummern belegen, z.B.

- 10 Teil Entnahme

- 20 Teil entgraten

- 30 Zeitstempel prägen

- 40 Fertig Teil ablegen

- 99 Homepos

Wenn du jetzt eine Bewegung hast von 10 zu 20 ( Teil entnehmen zu Teil entgraten) zähltst du die Positionen durch 102001 dann nächste Position 102002 usw. am Schluss stehst du dann bei 20.

So jetzt weißt du eigentlich immer was der Roboter gerade vor hatte.

Wird das Programm jetzt unterbrochen, kannst du über eine Rückzugsstrategie den Roboter nach Home fahren.

Hierfür eignet sich dann eine Case - Anweisung.

Du musst natürlich beachten das du jetzt ein Teil im Greifer hast !!

Gruß

Michael

Hallo WernerRob.

Sichere Rückzugsstrategien sind begehrte Themen. Sieht man auch hier im Forum. Wäre mal eine Idee für KUKA hier was brauchbares im Grundsystem zu programmieren.

Bei uns, werden alle Palettierer mit einer funktionierenden Rückzugsstrategie ausgeliefert.
Es ist dann generell bei "Check HOME" angesiedelt. So dass bei einem Programm-Reset oder z.B. bei einem Stromausfall, nach einem Kaltstart wieder automatisch ein sicherer Weg zu HOME gefunden wird.
Ich sage zu unseren Kunden immer spaßhaft: das Handlings-Programm braucht 10% der Programmzeilen. Der Rückzug 90%.

Nun, bei unseren Palettierern ist es meist einfach. Ist $IN_HOME==false speichere ich die aktuelle Achs-Position in einer Variablen. Ich fahre dann ein wenig in Z nach oben (z.B. LIN_REL {Z -100} #TOOL), dann überschreibe ich die A2-Pos. mit einem absoluten Wert und fahre die Position an. Das mache ich ein paar Mal noch mit anderen Achsen. Wenn alles außer Bereich ist gehe ich in HOME.

Bei unseren 6-Achsern, bin ich auch immer noch am herausfinden der besten Strategie. Mit Merkern setzten (wie schon oft beschrieben) bin ich nicht wirklich glücklich geworden. Dann habe ich versucht anhand der Act.-Pos. von A1 herauszufinden wo ich bin (vor allem ob ich noch in einem speziellen BASE bin). Funktioniert aber auch nicht immer so genau (vor allem wenn's eng wird).

Meist habe ich für unterschiedliche Base's spezielle Stoßrichtungen des Tools. Also wäre es für mich schon eine Hilfe, wenn ich wüsste ob ich noch in einem BASE-Bereich bin und wenn ja in welchem. Dann könnte ich oft gegen die Stoßrichtung wieder weg fahren.

Weg fahren am besten auch mit einem Absolutwert und nicht mit einem Relativwert (da man mit zwar vom Werkstück/Maschine wegkommt, aber nach hinten wieder anstößt oder an die Grenzen kommt)

Aktuell mache ich das so:

Ich bilde mir pro Base einen Kartesischen Arbeitsraum (mit KUKA Arbeitsraumüberwachung) und weiße diesem einen Ausgang (auch für die SPS) zu. Den Arbeitsraum bemesse ich nur im Bereich wo ich definiert rückziehen müsste.

Wenn ich dann am Programm-Anfang nicht $IN_HOME bin, setzte ich ein TOOL aktiv.

Dann prüfe ich die Ausgänge der Arbeitsraumüberwachungen. Ist einer TRUE, setzte ich das entsprechende Base aktiv und fahre mit einigen absoluten, kartesischen Positionen frei. Bin ich dann im ungefährlichen Bereich, geht's weiter gen HOMAE wie mit den Palettierern.

Bei mir tut's so meistens ziemlich gut, ohne dass der Bediener eingreifen muss.

Aber ich weiß, es gibt auch kompliziertere Anlagen, wo selbst das nicht hilt.

Gruß Roland

Habe schon mal in einem anderem thread dazu was gesagt, bei unserer Schweißanlage wird im jeweiligen, aktiven Modul die Bewegung bzw Position mitgezählt und in die Variable iPos=1 .. 2 .. 3.. geschrieben, je nach dem wieviele Schritte bis zur Endpos nötig sind. Im Fehlerfall (kein Crash !) wird durch die SPS aus dem laufenden MainLoop Case XY aufgerufen und in die "homingroutine" gesprungen. Die arbeitet dann die Punkte rückwärts bis zur Homepos ab. Funktioniert ganz gut.

Alles gut und schön, aber ihr beachtet alle das V bei der KRC nicht!

Ups .. bei V bin ich raus ... sorry ..aber vllt hilft der eine oder andere Ansatz aus der Nicht-V-Welt ja doch irgendwie weiter. Dennoch Gutes Gelingen meinerseits.