TIA Störende Meldung vom Technologieobjekt

[ioStart]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo allerseits,

bei einer Maschine (1515 2PN) mit Frequenzumrichter und PILZ-Steuerung zur Schutztürüberwachung, kommt regelmäßig folgende Meldung am HMI wenn eine Schutztür geöffnet wird.







Meiner Einschätzung nach ist der Grund für die Störmeldung, dass der Frequenzumrichter vom PILZ über die beiden STO-Signale abgeschaltet wird, und erst kurz darauf in der SPS das enable-Signal am MC-Power-Modul weggenommen wird. Also vermutlich genau falsch herum.
Allerdings ist das Ganze sicherheitsrelevant und daher wird daran auch nichts zu ändern sein. Was stört ist die Meldung vom Technologiemodul.

Kennt jemand so ein Szenario?

 

[TP-Inc]

Hat der G120 eine Freigabeklemme? Normal nimmt man zuerst die Freigabe damit der Antrieb eine saubere Rampe fahren kann, und nimmt dann erst STO.

 

[LarsVader]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das Problem hatten ich auch schon einmal.
Wie regelst Du die Freigabe am MC-Power?
Ich erteile zunächst einen Fahrbefehl und gebe damit die Freigabe.
Dann, nachdem die Freigabe vom TO zurückgemeldet wurde, starte ich die Positionierung.
Eine Schutztür gebe ich nur frei, wenn nicht grade eine Positionierung läuft. Diese oder der Not-Halt bewirken einen STO.
Der nimmt dann die Feigabe vom MC-Power weg, welcher mit StopMode 1 parametriert ist.
Funktioniert so eigentlich tadellos.

 

[blimaa]

Hi
Diese Meldung kenne ich auch, ich hatte damals die Freigabe vom Technologieobjekt nicht sauber weggenommen, resp. zu spät weg genommen. (MC_Power). Ich musste immer die SPS wieder neu starten um diese Meldung zu quittieren... Wie kannst du sie quittieren?

 

[TP-Inc]

Hi
Diese Meldung kenne ich auch, ich hatte damals die Freigabe vom Technologieobjekt nicht sauber weggenommen, resp. zu spät weg genommen. (MC_Power). Ich musste immer die SPS wieder neu starten um diese Meldung zu quittieren... Wie kannst du sie quittieren?

Müsste mit MC_RESET quittierbar sein

 

[blimaa]

Zuviel Werbung?
-> Hier kostenlos registrieren

Müsste mit MC_RESET quittierbar sein

Hmm OK...hätte ich auch erwartet...

Mein Problem war, dass ich anstatt MC_Power den MC_Reset angesteuert habe, wenn die Schutztüre geöffnet wurde Hat warscheinlich dann beide komischen Phänomene verursacht.

 

[ioStart]

Hat der G120 eine Freigabeklemme? Normal nimmt man zuerst die Freigabe damit der Antrieb eine saubere Rampe fahren kann, und nimmt dann erst STO.

Das deckt sich mit der Aussage von LarsVader. Das ist machbar, wenn man den Zeitpunkt vom STO gezielt steuern kann. Im Falle von Schutztüren welche keine Zuhaltung haben, weiß man das aber nicht im Voraus.
Die Pilz-Steuerung schaltet dann direkt den STO-Befehl, und über Profinet wird der SPS mitgeteilt, dass eine Schutztür offen ist. Mit diesem Signal wird die Freigabe vom MC-Power weggenommen

Ich denke drüber nach, ob wir Pilz-seitig eine kleine Verzögerung beim STO-Befehl einbauen sollen. 50ms oder so. Damit könnte die SPS dann schneller sein. Geht halt dann auf die Reaktionszeit des Systems

 

[LarsVader]

Das deckt sich mit der Aussage von LarsVader. Das ist machbar, wenn man den Zeitpunkt vom STO gezielt steuern kann. Im Falle von Schutztüren welche keine Zuhaltung haben, weiß man das aber nicht im Voraus.
Die Pilz-Steuerung schaltet dann direkt den STO-Befehl, und über Profinet wird der SPS mitgeteilt, dass eine Schutztür offen ist. Mit diesem Signal wird die Freigabe vom MC-Power weggenommen

Ich denke drüber nach, ob wir Pilz-seitig eine kleine Verzögerung beim STO-Befehl einbauen sollen. 50ms oder so. Damit könnte die SPS dann schneller sein. Geht halt dann auf die Reaktionszeit des Systems

Stimmt. Unsere Türen sind mit Zuhaltungen ausgestattet. Das vereinfacht einiges.
Ich habe nochmal in meinen MotionControl Unterlagen geschaut. 421 ist die normale Reaktion, wenn STO ausgelöst wird.
Dies kannst Du im DB des TO auslesen. Es gibt dort den Eintrag ErrorDetail.
Den Fehler kann man über MC-Reset wieder quittieren.