Überschleifen trotz Programmaufruf in Cell

- Während der Fahrt nach Home wird die cell durchlaufen und startet ein neues Programm (kann aber auch wieder Programm 1 sein)

Kann so eigentlich nicht funktionieren, da aus der Cell heraus ja auch nur dein aktuelles Programm heraus aufgerufen wird. D.h. das die Cell erst dann wieder abgearbeitet wird, wenn das aufgerufene Programm beendet ist. Theoretisch kann man dem Cell Programm ja auch einen beliebigen Name geben, es ist also kein systemspezifisches Programm.

Wenn dein Kollege das hinbekommen haben sollte, eine PTP Bewegung während der Fahrt auf eine andere Position umzuleiten, wüsste ich gerne, wie das gehen soll

Also setze mal die Variable $stopnoaprox auf TRUE im Automatik zeigt die Steuerung Dir dann die Zeile an welche nicht verschliffen werden kann. E-Log abspeichern und dann siehts Du alle Programmzeile welche er nicht verschleifen kann.
Nach der Optimierung wieder zurücksetzen nicht vergessen.

Gruß

Sven

Ach sooo...

Habs hier gerade mal nachgebaut, so funktioniert das bei mir durchaus.

Hast du evtl. in einem deiner Unterprogramme auf irgendeine Art und Weise einen Vorlaufstop drin bevor es verlassen wird? Ausgang gesetzt etc. ?

Auf welchen Wert steht dein Vorlaufzeiger? ($ADVANCE)

Was ich mit bekommen habe ist ein CONTINUE am Ende eines jeden Unterprogramms.
Wirkt manchmal Wunder.
Mach mal bitte vor der Zeile ProgNum=giProgNumSPS ein CONTINUE hier wird auf Systemvariablen zugegriffen welche unter anderem einen Vorlaufzeigerstopp hervorrufen können.

Das grundsystem sollte eigentlich ohne weiteres gehen. Nur ist die Frage was Du noch in Deinen einzelnen Unterprogrammen machst.

Gruß

Sven

Zitat von ROBOter_Nils

Wollte ja eigentlich nicht gänzlich von der ursprünglichen (original KUKA) cell abweichen

Warum eigentlich nicht? Ich für mein Teil habe das Ding noch nie komplett verstanden (und auch nie wirklich hinterfragt). Ich bevorzuge die radikale Lösung:

def cell()
haupt()
end

und dann alles selber machen. Den Programmnummer-Austausch mit einer übergeordneten SPS könnte z. B. durchaus die SPS.SUB während des laufenden Programms erledigen - am Ende hat man zwei Variablen in der config: eine Programmnummer und eine Info darüber, ob die Programmnummer gültig ist. Sowas wäre mir dabei wesentlich sympathischer als Experimente mit dem Vorlaufstopp bei EA-Anweisungen, der so sinnlos nicht ist (wie jeder ABB-Programmierer leidvoll bestätigen kann )

Grüße,
Michael

schau mal ob du am beginn deiner UP's ein INI hast?
dies stop den vorlauf glaube ich auch

IMO wird eine Vorlaufstopp ausgelöst, wenn die Unterprogramme eine INI-Zeile haben - kann das jemand bestätigen?
[Edit: atw11m92 war etwas schneller ]
Ich benutze diesen Cell-Kram auch nicht und weiß auch nicht was an der anderen Lösung "radikal" sein soll?

bei mir sieht das meist so aus, dass das nur das Programm Automatik.src für den Bediener sichtbar ist.
Automatik.src wird angewählt:

DEF automatik()
INI
;hier folgen weiter Initialisierungen:
;....
;....


INTERRUPT DECL 8 WHEN b_Programm_Reset DO ResetPrg() ;Interrupt fuer Programmabbruch
LOOP
b_Programm_Reset=False
GRST() ;Kontrollierte Grundstellungsfahrt
MAIN() ;Hauptprogramm aufrufen
ENDLOOP
END
DEF ResetPrg()
INTERRUPT OFF 8
BRAKE
RESUME
END

In Main.src wird die Programmnummer ausgewertet und die einzelnen Unterprogramme aufgerufen:

DEF Main()
INTERRUPT ON 8
REPEAT
SWITCH I_PLC_PGNO
CASE 1
 Prg1()
CASE 2
 Prg2()
CASE 3
 Prg3()
DEFAULT
  ;meldung ausgeben und in Grundstellung fahren
  b_Cycleend=TRUE
UNTIL b_Cycleend ;bis Zyklusende - kann in Verschiedenen Situationen gestetzt werden
END

Juüp kann ich bestätigen:
habe INI Zeile immer so modifiziert:
;FOLD USER INI

CONTINUE
IF NOT $EXT THEN
;FOLD INI
;FOLD BASISTECH INI
GLOBAL INTERRUPT DECL 3 WHEN $STOPMESS==TRUE DO IR_STOPM ( )
INTERRUPT ON 3
BAS (#INITMOV,0 )
;ENDFOLD (BASISTECH INI)
;FOLD SPOTTECH INI
USERSPOT(#INIT)
;ENDFOLD (SPOTTECH INI)
;FOLD GRIPPERTECH INI
USER_GRP(0,DUMMY,DUMMY,GDEFAULT)
;ENDFOLD (GRIPPERTECH INI)
;ENDFOLD (INI)
ENDIF
;ENDFOLD (USER INI)

Damit fahre ich nur durch die INI wenn nicht in $EXT!

Zitat von Sven Weyer

CONTINUE

IF NOT $EXT THEN

Laut KUKA Doku macht das Continue dort keinen Sinn.

Zitat aus der Doku 5.x:
In Anwendungsfällen, bei denen dieser Vorlaufstop verhindert werden soll, muß direkt vor
der betreffenden Anweisung der Befehl CONTINUE programmiert werden. Die Steuerung
setzt dann den Vorlauf fort. Die Wirkung ist aber nur auf die nächste Programmzeile beschränkt
(auch Leerzeile!!).

So richtig verstanden wann, wie, wo CONTINUE sinnvoll ist habe ich noch nie - daher probiere ich immer nach dem Verfahren Try & Error aus.

Zitat von Sven Weyer

Damit fahre ich nur durch die INI wenn nicht in $EXT!

Popelig einfach! Aber genial - ich lieber einfache geniale Dinge!

Und noch ein Gedanke:

Wenn du denn die Geschichte soweit am laufen hast:

In dem Moment, an dem der Vorlaufzeiger durch deine Switch Anweisung läuft, muss die neue Programmnummer bereits drinstehen.
Wenn du also einen variablen Ablauf gewährleisten sollst, musst du die Nummer früh genug eintragen.

Wobei früh relativ ist, es gibt (glaube ich) keine Möglichkeit auszulesen, wo denn der Satzvorlauf gerade steht. (ich meine jetzt nicht $Advance, weil der bezieht sich ja nur auf die Bewegungssätze)

Morgähn!

Im Prinzip ist das mit dem CONTINUE ganz einfach: Vor Zugriffen auf Ein- oder Ausgänge. Auch wenn die sich als Systemvariablen tarnen oder einen Signalnamen zugewießen bekommen haben (wie z.B. $EXT, der kann ja über die Automatik-Extern-Schnittstelle ein Ausgang zugewießen werden, oder der obige giProgNumSPS).
Für normale Variablen bzw. normale Systemvariablen wirds nicht benötigt.
Dass es nur für die nächste Zeile gilt wurde ja bereits erwähnt. Das ist auch der Grund, warum ein

repeatcontinueuntil Eingang

auch dann überschleift, wenn der Eingang auf dem Weg zum Punkt vorher kommt, ein

continuewhile not Eingangendwhile

nur dann, wenn der Eingang schon ansteht, wenn der Vorlauf dort das erste Mal vorbeikuckt, wie bei

continuewait for Eingang

eben auch.

Alle Klarheiten beseitigt?

Gruß,
Robotermann

Hier bei ist aber auch zu beachten das dieses CONTINUE nur funktioniert beim einlaufen in der WHILE-Schleife!

continue
while not Eingang
endwhile

Beim verbleib in der WHILE-Schleife wird jedes mal ein Vorlaufzeigerstopp ausgelöst wenn die Bedingung der WHILE-Schleife geprüft wird.
Da gibt es aber auch ein einfaches Mittel: Man nimmt eine BOOL und überträgt das Signal in der sps.sub auf die BOOL dauerhaft
BOOL = EINGANG

continue
while not BOOL
endwhile

Dann Überschleift er auch schön.

Natürlich nur sinnvoll wenn ein Bewegungsablauf innerhalb der WHILE-Schleife stattfindet.

Gruß

Sven

P.S.: IrrerPolterer Ja das mit dem einkopieren hat hier nicht funktioniert. Hab es einmal abgeändert. Hat es beim einkopieren einfach zwischen jede Zeile eine Leerzeile eingefügt. Habs mal geändert.
Ick weeß doch dat dit CONTINUE nur uff die nexte Zeile würgt.

Guten Morgen zusammen,

wenn du aber den Eingang in der sps.sub auf ein Bool überträgst, dann kannst du dir das CONTINUE wieder sparen Das mit dem While Eingang ist genau das was ich gemeint hab. Funktioniert genau wie

CONTINUEWAIT FOR Eingang

-> Überschleift nur, wenn der Eingang da ist wenn der Vorlauf das erste mal vorbeikuckt.

Was das cell betrifft: Wir hatten mal nen Kunden, der hat sich die P00 genommen, kopiert und entsprechend mit CONTINUEs versehen. Der hat dann im Vorlauf die nächste Programmnummer eingelesen. Ob das so generell funktioniert weiß ich nicht, der hatte damals noch ein paar andere Spezialitäten drin.

Gruß,
Robotermann

Zitat von Robotermann

CONTINUEWAIT FOR Eingang

-> Überschleift nur, wenn der Eingang da ist wenn der Vorlauf das erste mal vorbeikuckt.

Manchmal ist es aber wichtig, Eingänge außerhalb der Station ein weiteres Mal abzufragen:

LIN P_EP
WAIT FOR $IN[1] ;FIRST CHECK
LIN P_VP1 C_DIS
PTP p_VP2 C_PTP
PTP p_VP3 C_PTP
PTP p_VP4 C_PTP
CONTINUE
WAIT FOR $IN[1] ;2nd CHECK OUTSIDE

Ist sinnlos, weil beide Waits aufgrund des Vorlaufes unmittelbar hintereinander erfolgen. So ist es besser:

LIN P_EP
WAIT FOR $IN[1] ;FIRST CHECK
LIN P_VP1 C_DIS
TRIGGER WHEN DISTANCE = 1 DELAY=0 DO b_mvBack=TRUE
PTP p_VP2 C_PTP
PTP p_VP3 C_PTP
PTP p_VP4 C_PTP
CONTINUE
WAIT FOR b_mvBack ;WARTE BIS ENDPOS VERLASSEN
CONTINUE
WAIT FOR $IN[1] ;2nd CHECK OUTSIDE

Wartet im VL auf b_mvBack und Roboter fährt weiter in Richtung p_VP2 ohne Stopp.
Fehlt das CONTINUE vor WAIT FOR b_mvBack, gibt es immer einen Stopp, obwohl b_mvBack eine ordinäre BOOL-Variable ist.

Steht das TRIGGER allerdings über PTP p_VP3 funktioniert es nicht immer. Steht es nur über PTP p_VP4 wird auch immer ein VL-Stopp ausgelöst, obwohl die Abfrage eigentlich rechtzeitig im VL stattfindet. Wahrscheinlich muss immer mind. eine Bewegung im Bewegungsstack (Vorlauf) stehen. Wir programmieren deshalb immer mehrere Nachpositionen, damit der Bewegungsstack nicht leer laufen kann.

Gruß, Andreas

Hallo Andreas,

also hier nochmals generell:

Wenn zwischen zwei Bewegungsbefehle (z.B. PTP xP1 oder LIN xP23) eine Anweisung steht, die einen Vorlaufstop auslöst, dann fährt der Roboter die davorliegende Position exakt an (inkl. Brems- und Beschleunigungsrampe) egal ob der Punkt überschliffen programmiert wurde oder nicht.

Folgende Befehle lösen einen Vorlaufstop aus:

• alle Aktionen die digitalen oder analogen Ein- und Ausgängen sowie Signalvereinbarungen schreiben oder lesen


• wait sec [real]


• wait for [bool]


• z.T. Befehle in der INI-Falte

Mit dem Befehl CONTINUE wird die nächste Programmcodezeile (egal ob es eine Leerzeile, Kommentarzeile oder ein WAIT FOR ist) im Vorlauf ausgeführt und kein Vorlaufstop generiert. Achtung der Vorlauf ist der Roboterbewegung bis zu $ADVANCE Bewegungssätze voraus. Merke: Auch wenn der Befehl mit Hilfe des CONTINUE ohne Vorlaufstop ausgeführt wird, kann es einen Roboterstop (Genauhalt) geben. Wenn nämlich die Bedingung nicht bis spätestens der Hälfte der vorhergehenden Bewegung erfüllt ist, kann die Überschleifbahn nicht berechnet werden und ein Genauhalt wird ausgeführt.
Eine (kompliziertere und ressourcenintensivere) Lösung wäre der TRIGGER Befehl. Mit dem TRIGGER kannst du auch Interruptprogramme ausführen, um z.B. Eingänge auszuwerten. Damit aber der TRIGGER-Befehl funktioniert, muss eine Bewegung dazu vorhanden sein. Die Bewegung darf nicht zu klein sein, sonst gibt es auch einen Stop für die Roboterbewegung.

Die p00 Aufrufe im cell.src beinhalten Vorlaufstops. Das bedeutet in jedem LOOP-Durchlauf hast du mindestens die Zeilen

P00 (#EXT_PGNO,#PGNO_GET,DMY[],0 )
. . .
P00 (#EXT_PGNO,#PGNO_ACKN,DMY[],0 ) ; Reset Progr.No.-Request

die einen Vorlaufstop auslösen.

Um keine Taktzeitverluste durch das Cell zu haben, hast du folgende Möglichkeiten:

• Eigenes Programm schreiben, das die Funktionalität von Cell hat aber ohne Vorlaufstop


• Das Modul p00 modifizieren und die Vorlaufstops entfernen. (Vorsicht bei Systemupdates wird es wieder überschrieben.)


• Dein Programm so aufbauen, dass die Stops jeweils dort sind, wo du sowieso stoppst. (Greifen/Ablegen) Dann sind die SPS Befehle halt nicht mehr "Lege Teil in Maschine" sondern "Gehe von Maschineeinlegeplatz zu Bandaufnameposition"

Prinzipiell würde ich vor dem Programmieren bereits den Produktionsablauf überlegen und das Programm Taktzeitoptimiert struktirieren. Das erspart spätere Änderungsaufwendungen. Bewegungspunkte, Bewegungsarten, Überschleifparameter oder Bewegungsparameter sind einfacher nachträglich zu ändern.

lg Drudge