Stopp-Signal

Entweder du nimmst $MOVE_ENABLE weg oder du kannst z.B. auch ein eigenes Signal dazu verwenden und dann über einen Interrupt stoppen.

Hi Scmi,

wir machen das über einen Interrupt, wie DS186 schon geschrieben hat.

Beispiel:

;Programmstopp

GLOBAL INTERRUPT DECL iIptStopp WHEN bProg_Stop DO Ipt_Programmstopp()

INTERRUPT ON iIptStopp

GLOBAL DEF Ipt_Programmstopp()

;

; Programmstop von SPS ausgeloest

INTERRUPT OFF iIptStopp

;

BRAKE F

WAIT FOR diWeiter

;

INTERRUPT ON iIptStopp

;

END

Zitat von SCMI

(hoffentlich nicht)

Die Betrachtung ist ja eigentlich von der falschen Seite her. Natürlich denkt man sich "o Gott, ich habe keinen expliziten Stopp-Eingang", aber den braucht man ja auch nicht.

Der Bediener hat eine Stopp-Taste auf dem Panel.

Die Sicherheitskreise halten alles zuverlässig an.

Der Roboter selbst kann vom Programm aus warten oder anhalten und macht dafür Programmentscheidungen anhand der ihm bekannten Umgebungssituation.

Das Programm ist irgendwann fertig und endet.

Was übrig bleibt, ist eigentlich nur noch dieses "hey, irgendeine externe Instanz meint, es sei eine schlechte Idee, wenn der Roboter jetzt weiterfährt, aber diese außenstehende Instanz kann oder will dem Roboter nicht genau sagen, was sie für ein Problem hat". Und der Fall wird mit der Fahrfreigabe abgedeckt.

Zitat von SCMI

Es gibt Anlagenpanel und an diesem wählt man den Automatikbetrieb an und startet und stoppt die Anlage.

Wenn also jemand im Automatikbetrieb die Anlage stoppt, dann sollen eben auch die Roboter stoppen und da hätte ich ein Stopp-Signal schöner gefunden als ein weggrätschen der Fahrfreigabe.

Ja, bin ja Deiner Meinung, wobei die beiden Befehle "halt an!" und "fahr nicht weiter!" semantisch voneinander nicht ganz so weit entfernt sind... Wenn ich mich nicht irre, stoppt die Wegnahme der Fahrfreigabe auch Bahntreu.

Wir hatten über unsere Anlagenpanel auch immer die Diskussion. Eine Zeitlang gab es dann zwei Tasten, "Anlagenstopp" über ein Stoppsignal bzw. Wegnahme der Fahrfreigabe und "Zyklusstopp", welches dem Roboter einfach einen Eingang setzte, welcher ihm anzeigte, bei der nächsten sich bietenden Gelegenheit stehen zu bleiben. Stellte sich dann raus, dass man vorm Panel immer kurz überlegen musste, nicht auf den falschen Knopf zu drücken, da der Sofortstopp meistens zu schlechteren Nachstart-Bedingungen führte als der Zyklusstopp. Letztlich brauchte man den "harten" Stopp nur noch, wenn der Roboter in einer Warteschleife festhing.

also gibts ROB_STOP/ROB_STOP_RELEASE

Ich bin mir gerade nicht sicher (und habe auch nichts zum testen), aber wenn bei ROB_STOP die Antriebe eingeschaltet bleiben, dann sollte das ggf. berücksichtigt werden. Bei z.B. einem Sofort-Halt möchte man ja unter Umständen, dass die Antriebe ausgeschaltet werden.

Prinzipiell muss er ja sowieso die Automatik extern Schnittstelle "sauber ausprogramieren" SPS-seitig für Anlagenstart, Stop, wenn er "ohne " KCP-Bedienung arbeiten will.

$Move_Enable ist ein Teil davon und auch dokumentatorisch so erfasst im Ablaufplan. Das Handling davon wird oft in Standardschulungen schon besprochen.

Wieso es total verkomplizieren, wenn Du locker darüber ein Stop ausführen lassen kannst.

Weiter hast Du gleich noch die Möglichkeit des Verhinderns des manuellen Fahrens, wenn Du es wirklich willst. Hast also SPS-seitig auch dies im Griff, dass nicht jeder einfach manuell wegfährt.

Restart mit Quittierung gehört zur Standard-Startprozedur, die auch in anderen Fällen zum Tragen kommt wie nach Zellenzutritt.

Mit ROB_STOP/ROB_STOP_RELEASE musst Du schon wieder schauen, dass der Submit wirklich läuft.

Und auch da wieder separat was bauen für den Restart. Funktion ist den Meisten nicht bekannt.

Es via Interrupt zu lösen hat den grossen Nachteil, dass man oft nicht sieht, wo er wirklich im Programm nach Auslösung stehen geblieben ist, da auf KCP dann die Interruptroutine sichtbar ist.