Überschleifposition bei Wartebedingung in Feinpunkt konvertieren

Servus,

Wenn ich eine überschliffene Position habe und danach kommt eine nicht erfüllte Wartebedingung oder irgend eine andere Art von Vorlaufstopp, dann bleibt der Roboter relativ undefiniert am Anfangsbereich seiner Überschleifzone stehen.

Gibt es eine Konfigurationsmöglichkeit mit der man einstellen kann, dass der Roboter in so einem Fall stattdessen seine Zielposition als Feinpunkt anfährt?

Edit: Ich habe gerade den Überschleifbereich deutlich verkleinert und er bleibt immer noch an der selben Position stehen Also bleibt er nichtmal im Überschleifbereich stehen sondern bricht die Bewegung einfach mitten drin ab?

Hallo Sliwka,

Zitat von Sliwka

arbeitest du mit SLIN/SPTP?

Ja mache ich

Verhält es sich denn bei den "normalen/alten" Bewegungsbefehlen anders?

Generell hätte ich keine großen Probleme mit der Verwendung von PTP und LIN, außer dass es mich nerven würde, dass ich die laut KUKA "besseren, schnelleren und optimierten" Bewegungsbefehle nicht verwenden kann weil sie scheinbar doch schlechter sind

Zitat von Martin Huber

Ansonsten einfach die Überschleifbereiche im Punkt verkleinern

Ich habe bereits von 500 auf 50 verkleinert und konnte keinen Unterschied im Verhalten feststellen.

Zitat von fubini

und stattdessen auf einen anderen Punkt zu positionieren der "irgendwo" im Raum liegt die bessere Variante sein soll erschließt sich mir nicht.

Wieso denn "irgendwo im Raum"? Ich will doch nur, dass er die von mir geteachte Position weiter anfährt anstatt irgendwo auf der Bewegung zwischen Start- und Zielpunkt stehen zu bleiben.

Vielleicht erschließt es sich dir anhand folgenden Beispiels:

int_PosNumber=0
SPTP HOME
TRIGGER WHEN DISTANCE =1 DELAY=0 DO int_PosNumber=400
SPTP gXPrePosition CONT
WAIT FOR (int_PosNumber==400)
SLIN gXEndPosition

Dies spiegelt nicht exakt meinen Fall wieder, ist aber im Prinzip das gleiche.

Da bei der Bewegung von Home nach PrePosition die Variable int_PosNumber noch 0 ist, ist die Bedingung weiter unten nicht erfüllt und die Position "PrePosition" ist nicht überschleifffähig.
Daher stoppt der Roboter irgendwo undefiniert in der Bewegung von Home nach PrePosition und das Programm ist nicht weiter lauffähig, da die Bedingung nie erfüllt wird.

Würde der Roboter allerdings die Zielposition weiter anfahren, so würde beim erreichen der PrePosition der Wert 400 durch den Trigger auf die Variable geschrieben und die Bedingung wäre somit erfüllt und das Programm würde weiterlaufen.

Zitat

Dafür nimmt man auch das STOP WHEN PATH Feature des Spline

Diese Funktion, wie auch der "Bedingte Stopp" waren mir bis eben unbekannt, werde ich mir nun genau ansehen ob dies meine Probleme lösen kann. Vielen Dank!

Zitat von Sliwka

Leider verhalten die sich anders. Hatten hier auch viele Roboter mit S Befehlen. Haben dann wegen solchen Situationen wie bei dir, alles auf PTP LIN umgeschrieben. Dadurch wurden die Taktzeiten um ca 10-20% besser.

Die Stops mitten im Raum waren dadurch auch verschwunden.

Kannst ja ein Unterprogramm umschreiben zum testen.

Beim ändern auf PTP ändert sich das Verhalten tatsächlich zum besseren, Danke für den Tipp.

Allerdings möchte ich nicht mit laut Hersteller veralteten Befehlen programmieren und versuche das Problem anders zu lösen.

Tatsächlich lag mein Hauptproblem wiedermal bei WV..
Ich habe die Überschleifdistanz im ILF in WV angepasst und wurde mit dann in WV auch richtig angezeigt.

Nur stand im echten ILF auf der Steuerung immer noch der Standardwert von 500.

Somit war die Überschleifdistanz immer höher als die Triggerdistanz

Zitat von Hermann

Wohl vergessen das geänderte Programm zu übertragen?

Auf keinen Fall, ich habe sogar etliche male übertragen weil ich etliche Sachen ausprobiert habe

Wie gesagt dass Beispiel ist nicht 1:1 mein Fall.

Ich habe mehrere Stationen mit entsprechenden Vorpositionen in der Anlage und der Roboter soll von jeder Position zu jeder Position kommen je nachdem welche Station gerade "fertig" meldet.

Realisiert habe ich das mit einer MoveTo-Funktion die je nach aktueller Position (Bestimmt durch die getriggerte integer Variable) und Zielposition (wird in die Funktion übergeben) über Switch-Case die richtige Bewegungsroutine aufruft. So bleibt die Automatik-Sequenz dann sauberer.

Etwa so:

;Automatikablauf
IF bla THEN
MoveTo (#Station1)
;Handshake
;Stationsroutine ()
ENDIF

IF blabla THEN
MoveTo (#Station3)
;Handshake
;Stationsroutine3 ()
ENDIF

IF blablabla THEN
MoveTo (#Station7)
;Handshake
;Stationsroutine7 ()
ENDIF

Solange die Stationsroutinen dazwischen sind habe ich auch kein Problem.

Wenn allerdings mal 2 MoveTo aufrufe hintereinander kommen:

Aktuelle Pos Station 3

MoveTo (#Station1)

MoveTo (#Station4)

Dann eilt der Vorlauf so weit vor, dass beim Aufruf von MoveTo Station 4 der integer noch nicht auf die Station 1 geschrieben ist und somit die falsche Routine aufgerufen wird (nämlich von 3 nach 4 anstatt von 1 nach 4).

Deswegen schreibe ich zwischen den Positionen den integer auf Zwischenbewegung.

Sation 1 = 100; Station 2 = 200; Bewegung von 1 nach 2 = 100200

Im Positionserfassungsteil der MoveTo-Routine habe ich eine Schleife, in der auf eine richtige Stationsnummer gewartet wird, Zwischenbewegungsnummern werden ignoriert.

Prinzipiell:

b_PosOK=FALSE
REPEAT 
    IF PosNumber == 100 THEN
        ...
        b_PosOK=TRUE
    ENDIF
    ...
UNTIL b_PosOK==TRUE

Hier war dann mein Problem. Der Roboter ist auf der Bewegung von 100 nach 200, der Vorlaufzeiger lief in die Schleife, Überschleifzone war deutlich größer als Triggerpunkt. Somit blieb der Roboter in 100200 stehen und erreichte nie die 200.

Abgefangen habe ich das jetzt, indem ich in meinen "TRIGGER WHEN PATH" - Befehl die APO_DIST aus der verwendeten PDAT auslese und da noch 10mm draufrechne. Somit wird immer getriggert bevor überschliffen wird.

Der kommt im normal nicht 2x und könnte mir gerade auch keine Situation vorstellen in der das passiert.

Aber ich bin mehr so der Gürtel + Hosenträger Typ

Wenn ich es jetzt ignoriere obwohl ich weiß dass es passieren kann, dann kann ich garantiert zum blödestmöglichen Zeitpunkt 1000km zur Kundschaft fahren weil es dann doch passiert. Und sei es durch eine Programmänderung des Kunden.

Generelle Vorlaufstopps will ich nicht einprogrammieren weil es ja im Normalablauf flüssig laufen soll.

Obwohl ich im Falle eines doppel MoveTo Aufrufs sowieso einen Überschleiffehler generiere weil dann 2x hintereinander die selbe Position angefahren wird.