INTERRUPT Programmierung für Anfänger

DEF CELL ( )
EXT P_01_Schweissen()
EXT P_02_Heimfahrt()

INTERRUPT DECL 81 WHEN $IN[1]== TRUE DO abbruchSchweissen()
INTERRUPT ON 81
WAIT sec 0.012

LOOP
P00 (#EXT_PGNO,#PGNO_GET,DMY[],0 )
SWITCH PGNO ; Select with Programnumber

CASE 1
P00 (#EXT_PGNO,#PGNO_ACKN,DMY[],0 ) ; Reset Progr.No.-Request
P_01_Schweissen(); Call User-Program

CASE 2
P00 (#EXT_PGNO,#PGNO_ACKN,DMY[],0 ) ; Reset Progr.No.-Request
P_02_Heimfahrt(); Call User-Program

ENDSWITCH

if ($IN[1]) then
; achtung kollisionsgefahr
P_02_Heimfahrt()
endif
ENDLOOP

INTERRUPT OFF 81
WAIT sec 0.012

def abbruchSchweissen()
brake
resume
end

INTERRUPT DECL 81 WHEN $IN[1]== TRUE DO abbruchSchweissen()
INTERRUPT ON 81
WAIT sec 0.012

Der interrupt on ist an Der stelle falsche. Wenn der interrupt im hauptprogramm aktiv wird kommt es zum Fehler.
Interrupt on hier immer im unterprogramm oder unmittelbar vor dessen Aufruf.
Wozu das wait gut sein soll,weiß ich nicht.

def abbruchSchweissen()
brake
resume
end
For dem brake,bitte den interrupt ausschalten.

soma hat Recht. Sonst gibt's "ungültige Programmstruktur für Resume".

Und vor dem Einschallten des Interrupts immer schön abfragen, ob die Bedingung, die den Interrupt einschaltet nicht aktiv ist. Sonst kann's auch da zu Probs führen.

WAIT FOR NOT $IN[1]
INTERRUPT ON 81

Zitat von IrrerPolterer

soma hat Recht. Sonst gibt's "ungültige Programmstruktur für Resume".

Und vor dem Einschallten des Interrupts immer schön abfragen, ob die Bedingung, die den Interrupt einschaltet nicht aktiv ist. Sonst kann's auch da zu Probs führen.

WAIT FOR NOT $IN[1]
INTERRUPT ON 81

Nicht direkt zu Problemen. Man muss nur wissen, dass die Interrupter Flankengesteuert ausgewertet werden.
Frag man zB den Eingang 1 auf HIGH ab, und beim aktivieren ist dieser HIGH, wird der Interrupter nicht ausgelöst, da keine Flanke entstehen kann.
Also das Programm schon so vorbereiten, dass dieser Fall nicht vorkommen kann.
Ein Wait kann unter umständen ja andere Probleme verursachen. Ich finde aber, dass die Interrupter recht schön beim KUKA Funktionieren. Bisher hatte ich da nicht grössere Probleme.

Ich persönlich sehe keinen Sinn in Wait sec 0.012.

Hatte noch nie Probleme,dass der Programmzeiger diese Wartezeit benötigt.
Vorlaufstopp mach ich mit Wait sec 0.0 oder $Advance.

Kann mich jemand eines besserern belehren?

Zitat von Stethi

Kann mich jemand eines besserern belehren?

Nö! Sehe jch auch keinen Sinn drin...

Zitat von IrrerPolterer

Nö! Sehe jch auch keinen Sinn drin...

Dito, die ganze Sache sollte schon mal rein gar nichts mit dem Interpolationstakt zu tun haben. Der ist für andere Dinge zuständig.
Das "Wait sec" in der Interrupt-Service-Routine vor dem "Brake" ist m.E. schädlich, da sich der Roboter in der Zeit noch weiterbewegen kann. Wenn schon ein Wait, dann hinter dem Brake.

Auszüge aus KRC4 Systemintegrator Doku:

Einschalten des Interrupts
Der Zustandswechsel
darf frühestens einen Interpolationstakt nach INTERRUPT ON erfolgen.
(Dies kann erreicht werden, indem man nach INTERRUPT ON ein WAIT
SEC 0.012 programmiert. Wenn kein Vorlaufstopp gewünscht ist, kann zusätzlich
vor dem WAIT SEC ein CONTINUE programmiert werden.)
Der Grund ist, dass INTERRUPT ON einen Interpolationstakt (= 12 ms)
benötigt, bis der Interrupt tatsächlich aktiviert ist. Wenn der Zustand zuvor
wechselt, kann der Interrupt den Wechsel nicht erkennen.
Daher kommen die 12ms

RESUME bricht alle laufenden Interrupt-Programme und alle
laufenden Unterprogramme ab bis zu der Ebene, in der der aktuelle Interrupt
deklariert wurde.
Zum Zeitpunkt der RESUME-Anweisung darf der Vorlaufzeiger nicht in der
Ebene sein, in der der Interrupt deklariert wurde, sondern er muss sich mindestens
eine Ebene tiefer befinden.

Bedeutet wenn der Interrupt in der gleichen Ebene aktiv ist wie die Deklaration weiß die Steuerung mit dem RESUME-Befehl nicht mehr in welche Ebene sie zurück soll weil sie ja schon dort ist. Und das erzeugt dann einen STOP-Fehler.

Zitat von der_Held

soma: das Wait 0.012 bewirkt ein Vorlaufstop und eine Wartezeit von 0,012Sekunden. Genau so lange soll der Interpolationstakt meiner KR C4 sein; also genau die Zeit, die der Rechenknecht im Vierkantkasten braucht um einmal durch mein erstelltes Programm zu rasen. Das Wait 0.012 stellt sicher, dass beim darauf folgenden Befehl der Interrupt sicher aktiviert oder deaktiviert ist.

Nur der Vollständigkeit halber sei angemerkt, dass der Interpolationstakt die Zeit für die Abarbeitung eines Befehls ist.
Das Roboterprogramm wird sequentiell abgearbeitet, der aktuelle Befehl wird durch den Satzzeiger angezeigt, einen permanenten Durchlauf wie in einer SPS gibt es hier nicht.

Somit ist der Interpolationstakt auch nicht mit der Zykluszeit einer SPS gleichzusetzen.
(Mal abgesehen von der sps.sub. Dort könnte man durch von Anzahl der Befehle * Interpolationstakt = "Zykluszeit" sprechen.)

hmmmm

Zitat

Befehle * Interpolationstakt = "Zykluszeit"

hmmm
bei 12ms und 100 Befehle -> 1 sec. ...
kann nicht sein .....

Eher:
Interpolationstakt in dem alle "Prozesse" aufgerufen werden
Ich meine, in der Zeit schaft er 3000 Befehle

INTERRUPT läuft im "Hintergrund"
da kann es gut sein, dass er erst in nächsten "Zyklus" aktiv wird und die Bedingungen abgearbeitet werden

Zitat von ottosieben

Somit ist der Interpolationstakt auch nicht mit der Zykluszeit einer SPS gleichzusetzen.
(Mal abgesehen von der sps.sub. Dort könnte man durch von Anzahl der Befehle * Interpolationstakt = "Zykluszeit" sprechen.)

Neenee, keinesfalls.
Man kann sich mit entsprechenden Timer-Befehlen ja die Ausführungszeit (einen Zyklus) der SPS.SUB in eine Variable schreiben lassen und überwachen. Wenn das Programm im Submit-Interpreter sehr groß ist, dann kriegt man da auch schon mal 24ms oder 36 usw. angezeigt.
Wenn der Robbi so schnarchlangsam wäre, dann hätte ich auf Gärtner umgeschult, denn da wachsen ja die Radieschen schneller.

Grüße,
Michael

Zitat von Programmiersklave

Neenee, keinesfalls.
Man kann sich mit entsprechenden Timer-Befehlen ja die Ausführungszeit (einen Zyklus) der SPS.SUB in eine Variable schreiben lassen und überwachen. Wenn das Programm im Submit-Interpreter sehr groß ist, dann kriegt man da auch schon mal 24ms oder 36 usw. angezeigt.
Wenn der Robbi so schnarchlangsam wäre, dann hätte ich auf Gärtner umgeschult, denn da wachsen ja die Radieschen schneller.

Grüße,
Michael

Alles anzeigen

Na? Du bist Dir da 100% sicher?
Wie lang ist denn Dein sps.sub? Timer Befehle sind ausserdem asynchron, inwieweit die Zeitmessung für eine "Zykluszeiterfassung" zu gebrauchen ist, halte für fragwürdig. Weiterhin ist die Abarbeitungsgeschwindigkeit in sps.sub abhängig vom Durchlauf. Also durch ein "if" kann schon die Anzahl der bearbeiteten Befehle variieren.

Nebenher: Mein Kenntnisstand ist, dass die KRC4 4ms Interpolationstakt hat. Kann das hier jemand bestätigen? Dann würde der Wartetakt auf den Interrupt ja 3 Interpolationstakte lang sein. Gab es für die KRC2 eine ähnliche Vorgabe?

Grüße

Zitat von ottosieben

Na? Du bist Dir da 100% sicher?
Wie lang ist denn Dein sps.sub?

Yes, Sir.
Ich hab hier eine auf einer KRC 2, zusätzlich zur originalen SPS.SUB (die ja auch noch mal in die Gripper-Tech-Sache verzweigt) noch eine Datei mit 20 KB Anweisungen (607 Zeilen ohne Leerzeilen, danke UE), die zeigt die besagten 24.
Eine andere auf einer KRC 4 hat 31 KB Anweisungen (939 Zeilen mit Befehlen), die zeigt auch schon mal 48ms, je nachdem, wo reinverzweigt wird. Die Zahl der Zeilen sagt allerdings wenig, da ja öfters Loops durchlaufen werden, teilweise ineinandergeschachtelt, und andere Bereiche nicht aufgerufen werden.

Allgemein ist das bei meinen Maschinchen immer so ein Thema, deswegen bin ich ein wenig sensibilisiert dafür. Bei einigen Programmen passiert es tatsächlich, dass der Robbi mal eine halbe Sekunde Bedenkzeit braucht, was natürlich sofort auffällt, wenn er sich nicht bewegt, und zu Fragerei und albernen Verbesserungsvorschlägen seitens der Projektleiter führt. Aber dazu muss schon ein extremer Logikblock durchlaufen werden.
Hatte neulich noch auf einer KRC2 eine Messwerterfassung nachgerüstet, ca. 450 (Integer)Werte mit Glättung über Median, Fensterwertsuche, diversen Vergleichen usw., und es gab keine sichtbare Verzögerung im Programm. Von daher....

Aber das ist hier schon ziemlich Off Topic.

Grüße,
Michael

Programmiersklave
Das überzeugt mich.

Wieder wird ein grosses Missverständnis zu Grabe getragen....

Grüße

Bin mir nicht sicher, aber wo sich das Programm "Abbruch" im Verzeichnisbaum "Programme" befindet, ist hier wohl nicht relevant.
Vielmehr stimmt was im Programmablauf nicht.
Schau mal ob Du damit weiter kommst:
-> Gibt die Hilfefunktion mittels Fehlernummer (Fehlermeldung kommt ja nicht nur als Text, oder?) irgendetwas her?
-> In welcher Programmzeile steht denn der Satzzeiger beim Hängen?
-> Läßt sich eine Fehlerliste öffnen?

viel Erfolg

Hallo Held,

Mein Tip wäre die INI Falte im Interruptprogramm Abbruch() das das Problem verursacht.
Da drin werden über das UP bas() Sachen initialisiert, die in Interruptroutinen genau zu solchen Fehlern führen.
Braucht es da nicht.

Gruss SJX

Zitat

Bei einigen Programmen passiert es tatsächlich, dass der Robbi mal eine halbe Sekunde Bedenkzeit braucht

man muss hier aufpassen.

hatten mega Probleme,
weil der Robi ca. 600ms für die Reaktion gebraucht hat (angeblich).

Nach Aufzeichnungen und Versuchen:
wenn der Roboter wartet,....
schaltet er seine Antriebe ab und befindet sich nicht mehr in der Regelung.
Wenn nun die "wait-Anweisung" erfüllt ist,
braucht er ca. 600ms um loszufahren....

Lösung:
while (NOT($in[1]))
LIN wartepos
endwhile