TIA Program_Alarm Meldungen lassen sich nicht quittieren

[MFreiberger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin Zusammen,

wir haben gerade ein Phänomen bei Meldungen, die per Program_Alarm erzeugt werden.
Von >50 Meldungen, die beim Start der CPU gesetzt werden, können alle zurückgesetzt werden. D.h. der Eingang "SIG" am Program_Alarm ändert sich zu FALSE. Jetzt bleiben zwei Meldungen aktiv. Sie werden am Panel und in TIA angezeigt, obwohl der Trigger an "SIG" auch von TRUE zu FALSE gewechselt hat (und der Trigger HAT gewechselt!).
Setze ich die Trigger wieder und setze sie dann zurück, gehen die besagten Meldungen auch.

Es muss dazu gesagt werden, dass wir den Program_Alarm in einer Schleife nur dann für die entsprechende Meldung aufrufen, wenn es eine positive oder negative Flanke des Triggers gibt. Das funktioniert bei allen Meldungen einwandfrei, bis auf diese beiden. Und es sind immer explizit diese beiden Meldungen.

Das Phänomen haben wir auch bei einer produktiven Anlage mit TIA V16 (Da sind es nur andere Meldungen, die nicht funktionieren).
Ich teste mit TIA V17 Upd6 und PLCSIM.

Weil das Thema bei diesen unterschiedlichen Systemen gleich ist, denke ich, es muss ein systematischer Fehler sein. Begreifen tue ich es (noch) nicht.

Ich teste weiter, aber vielleicht kennt Jemand einen ähnlichen Fall und hat ggf. sogar eine Lösung dazu?

VG
MFreiberger

 

[UDP]

Passiert das Phänomen immer wenn eine bestimmte Anzahl an Meldungen überschritten werden?

Gibt der Program_alarm einen Status für diese beiden Meldungen aus? Die Fehlercodes 80C2 bzw. 80C3 klingen ein wenig nach dem Verhalten, dass du beschreibst.

 

[MFreiberger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin UDP,

vielen Dank für den Denkanstoß. Ich werde mal in diese Richtung forschen.

 

[UDP]

Nutzt du Get_alarm in dem Zusammenhang mit? Da bin ich mal über ein ähnliches Problem gestolpert.

 

[DOD666]

Wird der Programm Alarm Baustein auch abgearbeitet wenn der Zustand wechselt? Hört sich so an als wäre der Baustein nicht aufgerufen worden als der Trigger gewechselt hat.

 

[MFreiberger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin UDP,

nochmal Danke! Genau der Fehler 80C2 kommt. Jetzt muss ich nur noch gucken, wie ich damit umgehe...

 

[MFreiberger]

Wird der Programm Alarm Baustein auch abgearbeitet wenn der Zustand wechselt? Hört sich so an als wäre der Baustein nicht aufgerufen worden als der Trigger gewechselt hat.

Doch, das funktioniert einwandfrei.

 

[UDP]

Du könntest beim Status 80C2 dir merken, welche Meldung es betrifft und die Abarbeitung in diesem Zyklus abbrechen und im nächsten Zyklus dort weiter machen, wo du aufgehört hast.

Oder mal empirisch ausprobieren bei wie vielen Meldungen das Problem kommt und dann vielleicht die Abarbeitung auf eine gewisse Anzahl an Meldungen pro Zyklus begrenzen.

 

[R4m80]

Zuviel Werbung?
-> Hier kostenlos registrieren

Servus,

ich hatte das Problem mal als die Instanz des Program_Alarm zweimal aufgerufen wurde.
SIG hatte einmal geschalten und einmal nicht.
So wurde die Meldung pro Zyklus einmal getriggert und auch wieder zurückgesetzt.

Ist es möglich, dass diese Meldung in einem SPS-Zyklus mehrere Flanken an SIG hat?

 

[MFreiberger]

Du könntest beim Status 80C2 dir merken, welche Meldung es betrifft und die Abarbeitung in diesem Zyklus abbrechen und im nächsten Zyklus dort weiter machen, wo du aufgehört hast.

So ähnlich sieht meine Lösung aus. Ich verarbeite die Program_Alarm-Aufrufe in einer Schleife. Dabei merke ich mir in einem Bool-Array, bei welchem Aufruf es einen Fehler gab und stoße diesen Aufruf im nächsten Zyklus noch einmal an. Das funktioniert bisher wie erwartet und der "Bug" ist gefixt.