TIA Grund für Auslösung von NotHalt aus einer VPS sicher erfassen

[uweschwarz]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo, wir arbeiten mit einer S7 1516 und TIA V17.

In unserer Anlage sorgt eine VPS (Verdrahtungsprogrammierte Steuerung) für die funktionale Sicherheit. Wir haben z.B. 4 Drucksensoren deren Signale von einem Grenzwertschalter ausgewertet werden und sobald eine Grenzwerte über- oder unterschritten wird, wird NotHalt ausgelöst. Leider gelingt es mir mit der SPS nicht, festzustellen welcher der auslösende Sensor war.
Meine Vermutung ist, dass die VPS zu schnell ist. Wenn z.B. ein Druck den Grenzwert übersteigt öffnet die VPS die Anlage und alle Drücke fallen natürlich sofort ab. Ich habe im SPS Programm zwar eine Grenzwertüberwachung programmiert, aber die kriegt die hohen Drücke gar nicht erfasst. Ich habe bereits die Dämpfungszeiten für die Grenzwertüberwachung in der SPS gesenkt und die Grenzwerte in der SPS leicht unter die Auslösedrücke der VPS gelegt. Das hat leider nicht geholfen.
Meine Idee ist nun an einen LBP MSg8 Baustein die eingestellten Grenzwerte direkt, also ohne Glättung oder Dämpfung, mit dem Prozesswert zu vergleichen und den Enable Eingang des Bausteins nur zu aktivieren, wenn die negative Flanke des NotHalt Signals anliegt. Also den Baustein nur einen Zyklus aufzurufen, damit ich nur das initiale Ereignis speichere. Das scheint zumindest mit der PLCSIM zu funktionieren.
Aber wie quittiere ich die Meldung wieder?
Wir haben am Schaltschrank einen Taster der in Kombination mit einem Schlüsselschalter die Sicherheitsrelais quittiert. Vielleicht könnte ich damit den Baustein nochmal für einen Zyklus aktivieren und mit dem gleichen Bit den Rest beschalten.
Das klingt für mich aber irgendwie nicht nach einer guten Lösung. Hat jemand eine bessere Idee?

Herzliche Grüße
Uwe

 

[DeaD_EyE]

Du könntest ein programmierbares Sicherheitsrelais verwenden. Wäre zumindest eine pragmatische Lösung.

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich würde generell den Eingang einlesen und in eine Hilfsvariable speichern. Mit der Flanke des Not-Halt schreibst du nun die Hilfsvariable in eine neue Variable - diese beinhaltet dann sicher den Wert (oder Zustand), der zum Auslösen geführt hat.
Den Baustein bedingt aufzurufen wäre so gar nicht mein Ansatz. So kannst du dann auch problemlos das Rücksetzen umsetzen ...

 

[uweschwarz]

diese beinhaltet dann sicher den Wert (oder Zustand), der zum Auslösen geführt hat.

Da bin ich nicht so sicher.
In der neuen Variable, nennen wir sie P_NotHalt, steht doch dann der Wert, der zum Zeitpunkt des NotHalt aktuell war und zwar für 4 Drucksensoren. Bitte habt im Hinterkopf, dass die 4 Drucksensoren nur ein Beispiel sind. In der Anlage handelt es sich um 11 Sensoren, die unterschiedliche Größen messen (neben Druck, Temperatur, Gaskonzentration, Wächtersignale von Brandmelder etc.).
Müsste ich den Wert, der in P_NotHalt steht nicht noch mit dem Grenzwert für die NotHalt Auslösung vergleichen? Wenn nur einer der 4 Drucksensoren im (NotHalt)Zyklus den Maximaldruck gesehen hat, funktioniert das, aber was mache ich, wenn 2 oder mehr Sensoren den Maximalwet überschritten haben. Könnte ich über einen Zeitstempel weiterkommen?

 

[Larry Laffer]

Naja ... da du ja schreibst, dass du mit der Not-Halt-Flanke keinen passenden Wert einliest mutmaße ich mal, dass du mit der Umsetzung deiner Programmierung etwas unglücklich gelöst hast.
Ich würde, wie schon geschrieben, die fraglichen Werte (jeden einzeln für sich) permanent zwischenspeichern und bei Not-Halt (Flanke !!!) dann umspeichern (auch wieder jeden einzeln für sich). Anschließend kannst du dann ja auswerten wer am Ende verantwortlich war.

 

[uweschwarz]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Idee mit dem Messwertpuffer hatte ich auch schon. Ich kam nur nicht drauf, den aktuellen Messwert mit der Flanke des NotHalt wegzuschreiben. Das erscheint mir sehr logisch und besser als meine Lösung.
Ich versuche es erstmal so. Die Pufferung der Messwerte habe ich gewählt, damit wir den Verlauf kurz vor dem Ereignis noch auswerten können.
Was hältst du davon?

REGION Init
    // Statement section REGION
    //
    #Inst_R_TRIG_startUp(CLK := #SPS_Neustart);
    
    IF #Inst_R_TRIG_startUp.Q OR #Reset OR #statZykluszähler > 100 THEN
        #statZykluszähler := 0;
        #stati := 0;
        #statEnable := true;
        
    END_IF;
    
END_REGION

REGION Werte speichern
    // Statement section REGION
    //
    #stati := #statZykluszähler;
    IF #statZykluszähler < 101 AND #statEnable THEN
        #Messwertpuffer[#stati] :=#Pufferwert;
    END_IF;
    
END_REGION

REGION Zykluszähler
    // Statement section REGION
    //
    IF #statEnable THEN
        #statZykluszähler := #statZykluszähler + 1;
    END_IF;
    
END_REGION
REGION Auslösewert speichern und Aufzeichnung beenden
    
    //
    #inst_R_TRIG_Auslösewert(CLK := #Trigger);
    
    IF #inst_R_TRIG_Auslösewert.Q THEN
        // Wert der zum Zeitpunkt des Eintretens der Triggerbedingung aktuell war speichern
        #Auslösewert := #Pufferwert;
        //Aufzeichnung der Messwerte beenden, damit sie nicht von Werten nach dem Ereignis überschrieben werden
        #statEnable := false;
    END_IF;
        
        
END_REGION
REGION #Reset
    // Statement section REGION
    //
    IF #Reset THEN
        FOR #stati := 0 TO 100 DO
            #Messwertpuffer[#stati] := 0;
        END_FOR;
    END_IF;
    
END_REGION

 

[Larry Laffer]

Das du es so angehen willst hätte ich gar nicht vermutet - aber auf jeden Fall gut. Du solltest vielleicht überlegen, das Ganze als FIFO anzulegen (also quasi ein Array, dass sich aufschiebt) und das kontiniuierlich in einem Zeit-OB mit kurzem Intervall aufrufen. So hast du dann wirklich einen Verlauf, den du auch visualisieren könntest und in dem du, falls nicht der letzte Wert der Auslösewert war, denselben sogar suchen könntest.

Ich hatte sowas oft für Messwert-Aufzeichnung gemacht. Für die Messung habe ich den FB in einem Zeit-OB aufgerufen (wobei der dort wirklich nur was gemacht hat wenn Messung enabled war) und für die anschliesende Auswertung (also in meinem Fall nach der Messung) im zyklischen Programm den FB aufgerufen.
Für den FB war die Entscheidung, was er machen sollte, ein entsprechender IN-Parameter des Bausteins. Dazu gehörte dann auch der Reset (also recht ähnlich wie bei dir)

 

[PN/DP]

Wenn Traces nicht direkt in CPUs integriert verfügbar sind, dann programmiere ich mir bei kniffligen Problemen immer Ringpuffer für die relevanten Variablenwerte (wenn noch genug CPU-Arbeitsspeicher frei ist).

 

[uweschwarz]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn Traces nicht direkt in CPUs integriert verfügbar sind

Ich arbeite mit einer S7 1516, da sind Traces verfügbar. Leider habe ich nicht viel Erfahrung damit. Soviel ich das verstanden habe, müsste ich die aktiv zu Laufzeit beobachten oder kann ich die auch im Hintergrund mitlaufen lassen? Ich weiß ja nicht wann der nächste NotHalt ausgelöst wird.