SPS-Logik für Erstwertmeldung: Experten-Challenge

Welcher Fehler kam wirklich zuerst? Was dein Code tun muss

In einem Entwurf, der sich übersetzen lässt, stecken drei Fehler. Bediener sehen nach dem Quittieren einen anderen Fehlercode, und kurze Ventilbewegungen lösen manchmal den Alarm aus. Mehrere Ursachen können im selben Zyklus kommen. Repariere die Zeitüberwachung, die Erfassung der Ursache und das Quittieren zusammen.

Start und Durchfluss

Eine neue Start-Flanke speichert ValveCmd mit Permit, ohne Stop und ohne Alarm. PumpOn ist nur TRUE mit ValveCmd AND ValveOpen. Stop/Verlust von Permit nimmt beide Befehle sofort weg; danach braucht es einen neuen Druck auf Start.

Drei Ursachen

TripCode 0 = frei; 1 = Fault; 2 = Level >= 95%; 3 = ValveCmd ohne ValveOpen durchgehend für 500 ms. Rufe Delay in jedem Zyklus auf; sein erster aktiver Aufruf beginnt bei null. Der nächste Aufruf bei 500 ms löst aus. Ein Zyklus früher oder später wird akzeptiert, weil die Position des Delay-Aufrufs ihn um einen Zyklus verschiebt. Ein unterbrochener Stellweg setzt die Verzögerung zurück.

Erste Ursache und Priorität

Tritt mehr als eine Ursache im selben Zyklus auf, gewinnt Fault, dann hoher Level, dann die Ventil-Zeitüberschreitung. Nach der Erfassung bleibt TripCode erhalten, auch wenn eine weitere Ursache auftritt. Alarm = TripCode <> 0. Beide Prozessbefehle müssen im Auslösezyklus OFF sein.

Horn und Ack

Eine neue Erfassung lässt Horn ertönen. Eine steigende Flanke von Ack schaltet nur Horn stumm. Wer Ack über einen gültigen Reset hinweg hält, kann den nächsten neuen Fehler nicht stumm schalten. Lass los und drück erneut.

Reset

Reset löscht TripCode, Alarm und Horn nur, wenn Start losgelassen ist, Fault FALSE, Level < 95% und ValveStuck FALSE. Das Ventil bleibt zu, und ein neuer Start ist nötig. Ein Reset bei aktiver Ursache kann sie nicht löschen.

Setze die Simulation zurück und wähle ValveStuck, bevor du SPS starten und Start drückst. Sieh zu, wie ValveCmd und ValveOpen sich widersprechen, während das Ventil zu bleibt. Teste die genaue Grenze der Zeitüberschreitung und spiele sie erneut ab. Halte über Eingänge Ack gedrückt, während du einen Fehler löschst und neu auslöst; ein neues Ereignis muss Horn trotzdem ertönen lassen.

Welcher Fehler kam wirklich zuerst? Eingänge und Ausgänge

Dein Programm liest 9 Eingänge und setzt 5 Ausgänge. Die Namen sind im Editor jedes Herstellers gleich.

In Siemens SCL schreibst du die eigenen Variablen eines Bausteins mit # davor, wie TIA Portal es tut: #Start. Rockwell und TwinCAT verwende einfach den Namen: Start.

Was die Prüfungen testen

1. T1TripCode erfasst die erste Ursache und ändert sich bis zu einem gültigen Reset nicht.
2. T2Die Öffnungsrückmeldung hat 500 ms; ein unterbrochener Befehl startet eine neue Wartezeit.
3. T3Ein gehaltenes Ack kann ein späteres Ereignis nicht stumm schalten. Alarm, Horn, PumpOn und ValveCmd werden in jedem Zyklus geprüft.

Die Prüfungen führen 7 Tests an der Maschine aus, Zyklus für Zyklus: Eine fehlerfreie Anlage kann nicht zurückgesetzt werden, solange Start noch gehalten wird; Die erste Ursache überlebt spätere Fehler; festgelegte Priorität bei gleichzeitigen Ursachen; Die Grenze für hohen Füllstand und ein gehaltenes Ack können das nächste Ereignis nicht stumm schalten; Rückmeldung kurz vor der Grenze verhindert eine Zeitüberschreitung; Eine Zeitüberschreitung von 500 ms löst aus, verriegelt und verweigert ein unsicheres Rücksetzen; Unterbrochener Stellweg bekommt eine neue Wartezeit; Rückkehr der Freigabe startet einen gehaltenen Start nie neu.

Wo du das findest

Ein Brauereitank hört nach einem Alarm auf zu füllen. Die Ingenieurin oder der Ingenieur muss wissen, welche Störung zuerst kam, bevor spätere Störungen sie verdecken.

Wenn spätere Störungen den ersten Fehlercode überschreiben, geht die Ingenieurin oder der Ingenieur zur falschen Anlage. Ack zu nutzen, um den Alarm zu löschen, könnte eine Anlage neu starten, die noch gestört ist.

Gelöst oder festgefahren? Besprich es in der Umkleide.