TIA program_alarm aus 1515

[derwestermann]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin!

In dem Projekt, an welchem ich so programmiere, verwende ich ständig durch flankentrigger aufgerufene program_alarm.
Das funzt auch prima. Jetzt habe ich das selbe nochmal gemacht und habe das Phänomen, dass die Meldung kommt, ich sie aber nicht quittieren kann.
Auf dem TP1500 bleibt diese Meldung bis zum CPU-Neustart.
Was habe ich diesmal falsch gemacht?
Also der Aufruf des program_alarm funktioniert so wie er soll, dass habe ich durchgetestet.
Das tut eine Meldung generieren, die auf dem TP1500 stehen bleibt.


Das hier generiert eine quittierbare Meldung:

 

[TP-Inc]

Ich hab Program_Alarm noch nie verwendet, aber bist du sicher dass EN beschalten wird? Ich denke SIG löst die Meldung aus?? Steht zumindest im ersten Beispiel welches ich bei Google gefunden habe.

 

[TheQuest]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie @TP-Inc schon geschrieben hat, der EN darf nicht beschaltet werden. Die Quittierung funktioniert nur, wenn der betroffene Prg Alarm auch aufgerufen wird.

 

[oliver.tonn]

Sicher das EN nicht beschaltet werden darf? Für mich sieht das nach einer Möglichkeit aus den Alarm zu deaktivieren und wenn diese Option nicht genutzt werden soll wäre es für mich logisch, wenn der Eingang dauerhaft auf TRUE gesetzt wird.

 

[MFreiberger]

Moin,
EN darf schon beschaltet werden. Aber SIG ist eigentlich das Triggersignal. Wenn EN und SIG true sind (werden), wird die Meldung erzeugt.

Wenn EN = true und SIG true => false, geht der Alarm.
Wenn EN = false und SIG macht, was es will, wird der Baustein nicht bearbeitet und es geht kein Alarm, es kann aber auch kein neuer kommen.

Also, jedesmal, wenn man mit dem Program_Alarm ein Alarm erzeugen oder beenden will, muss der Baustein mit EN = true aufgerufen werden.

EN = true & SIG = true >> Alarm wird erzeugt (kommen)
EN = true & SIG = false >> Alarm wird erzeugt (gehen)
EN = false >> nichts passiert.

VG

MFreiberger

 

[derwestermann]

Zuviel Werbung?
-> Hier kostenlos registrieren

Jo, das Problem ist, dass SIG weiter auf true bleibt, dann geht die Meldung auch nicht weg.
So funzt es:

 

[derwestermann]

Ich hab Program_Alarm noch nie verwendet, aber bist du sicher dass EN beschalten wird? Ich denke SIG löst die Meldung aus?? Steht zumindest im ersten Beispiel welches ich bei Google gefunden habe.

Intern wertet program_alarm SIG auch flankengetriggert aus. Man kann die Zykluszeitlast durch den flankengetriggerten Aufruf sehr niedrig halten.

 

[oliver.tonn]

Jo, das Problem ist, dass SIG weiter auf true bleibt, dann geht die Meldung auch nicht weg.
So funzt es:
Anhang anzeigen 62829

Was ich immer noch nicht verstehe ist, warum Du EN so verschaltet hast. Wenn der Alarm über SIG immer ausgewertet werden soll kann EN doch fest auf TRUE gesetzt bleiben. Ist der Alarm deaktivierbar eine entsprechende Logik an EN legen, aber EN immer nur dann auf TRUE setzen, wenn der Alarm auftritt macht keinen Sinn für mich.

 

[derwestermann]

Zuviel Werbung?
-> Hier kostenlos registrieren

Senkung der Zykluszeit.

 

[MFreiberger]

Senkung der Zykluszeit.

!!!

Das machen wir in einer IF-Abfrage (SCL). Nur, wenn sich das Triggersignal ändert, wird der Baustein aufgerufen.
Dazu machen wir das noch in einer Schleife mit >100 Program_Alarm-Aufrufen.

Dass die Program_Alarm-Baustein so gewaltige Zeitfresser sind, ist echt ein Unding. Aber wahrscheinlich können sie Vieles, was Niemand wirklich braucht...

VG

MFreiberger

 

[TP-Inc]

!!!

Das machen wir in einer IF-Abfrage (SCL). Nur, wenn sich das Triggersignal ändert, wird der Baustein aufgerufen.
Dazu machen wir das noch in einer Schleife mit >100 Program_Alarm-Aufrufen.

Dass die Program_Alarm-Baustein so gewaltige Zeitfresser sind, ist echt ein Unding. Aber wahrscheinlich können sie Vieles, was Niemand wirklich braucht...

VG

MFreiberger

Warum verwendet man dass dann überhaupt?

 

[MFreiberger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Warum verwendet man dass dann überhaupt?

- um die Meldetexte zentral verwalten zu können und nicht mehrere Panels separat anfassen zu müssen
- um Alarme über OPC UA versenden zu können

 

[derwestermann]

Oder man verwendet program_alarm in einem TEC-Baustein, zum Bleistift für ein Ventil, oder einen Antrieb und parametriert die benötigten Texte so an den Baustein, dass diese an die SD_x-Eingänge des program_alarm weitergereicht werden. Dann sind alle Störmeldungen, die in diesem Baustein generiert werden fertig. Keine Meldetextlisten, nix!

 

[Oberchefe]

Und für die chinesische Übersetzung muss dann das SPS Programm angepasst werden?

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Intern wertet program_alarm SIG auch flankengetriggert aus. Man kann die Zykluszeitlast durch den flankengetriggerten Aufruf sehr niedrig halten.

Warum muss man das um den Program_alarm denn herum programmieren? Bzw. was macht der Baustein denn noch alles so um die Zykluszeit so nach oben zu treiben wenn sich der Zustand von SIG nicht ändert, und er somit eigentlich nichts zu tun hat? Also irgendeine Funktion muss einem dann doch fehlen wenn der Baustein nicht aufgerufen wird. Oder da ist ein grober Fehler innerhalb von Program_alarm.

 

[xEs1710]

!!!

Das machen wir in einer IF-Abfrage (SCL). Nur, wenn sich das Triggersignal ändert, wird der Baustein aufgerufen.
Dazu machen wir das noch in einer Schleife mit >100 Program_Alarm-Aufrufen.

Dass die Program_Alarm-Baustein so gewaltige Zeitfresser sind, ist echt ein Unding. Aber wahrscheinlich können sie Vieles, was Niemand wirklich braucht...

VG

MFreiberger

Genau da bin ich auch gerade dran. Du rufst also Alarm_Prog auf mit Triggersignaländerung. -> Wie machst du das mit dem SIG Eingang bzw. mit dem eigentlichen quittieren. "Merkst" du dir den Fehler, dass dieser nicht mehr ansteht?

Ich habe Fehlermeldungen die müssen quittiert werden und manche sollen alleine gehen?!

Danke!

 

[MFreiberger]

Moin xEs1710,

Wir machen das so (Beispiel):

FOR #i := 0 TO msgMaxIndex DO
IF
    "DB".TRIGGER[#i]
THEN
    "DB".TRIGGER_aux[#i] := true;
END_IF;


IF
    "DB".TRIGGER_aux[#i]
THEN
    Program_Alarm[#i](SIG := "DB".TRIGGER[#i]
                    ...);
                    
                    
IF
    NOT "DB".TRIGGER[#i]
THEN
    "DB".TRIGGER_aux[#i] := false;
END_IF;                   

END_FOR;

So wird der Program_Alarm nur aufgerufen, wenn ein Trigger kommt, ansteht oder geht. Wenn der Trigger false ist, wird der Program_Alarm für diese Meldung nicht aufgerufen.
Das führt zwar einerseits zu Zykluszeitschwankungen (abhängig von der Menge der anstehenden Trigger), reduziert die Zykluszeit aber auch effektiv auf die aktiven Trigger.

Der Trigger ist quasi das Meldebit. Je nach Meldung wird es gesetzt/rückgesetzt (bei quittierpflicht) oder nur zugewiesen (also selbstquittierend).

VG

MFreiberger

 

[xEs1710]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin xEs1710,

Wir machen das so (Beispiel):

FOR #i := 0 TO msgMaxIndex DO
IF
    "DB".TRIGGER[#i]
THEN
    "DB".TRIGGER_aux[#i] := true;
END_IF;


IF
    "DB".TRIGGER_aux[#i]
THEN
    Program_Alarm[#i](SIG := "DB".TRIGGER[#i]
                    ...);
                   
                   
IF
    NOT "DB".TRIGGER[#i]
THEN
    "DB".TRIGGER_aux[#i] := false;
END_IF;                  

END_FOR;

So wird der Program_Alarm nur aufgerufen, wenn ein Trigger kommt, ansteht oder geht. Wenn der Trigger false ist, wird der Program_Alarm für diese Meldung nicht aufgerufen.
Das führt zwar einerseits zu Zykluszeitschwankungen (abhängig von der Menge der anstehenden Trigger), reduziert die Zykluszeit aber auch effektiv auf die aktiven Trigger.

Der Trigger ist quasi das Meldebit. Je nach Meldung wird es gesetzt/rückgesetzt (bei quittierpflicht) oder nur zugewiesen (also selbstquittierend).

VG

MFreiberger

Super ich danke dir!
Aufruf Program_Alarm und Trigger am SIG gleichzeitig funktioniert? Also ohne Flanke? Hatte ich anderes in Erinnerung.
Ich teste das so auch mal mal aus!

Sollte das klappen, werde ich das wahrscheinlich noch so anpassen, dass der Program_Alarm nach der Meldung nicht mehr aufgerufen wird und erst wieder beim quittieren.

Beste Grüße

 

[MFreiberger]

Moment. Mit "Quittieren" setzen wir das Triggerbit zurück.
Und ja: man braucht am SIG einen Zustandswechsel (Flanke).

Guck Dir den Programmcodeschnipsel noch mal genau an.

Program_Alarm wird mit dem "aux" aufgerufen. Das "aux" wird erst zurückgesetzt, wenn der Trigger einmal mit 'false' am SIG vom Program_Alarm vorbei gekommen ist. Damit erkennt der Program_Alarm die negative Flanke und ist wieder bereit, beim nächsten Aufruf (aux) am SIG ein 'true' aufzunehmen, um eine Meldung zu erzeugen.
Das funktioniert bei uns seit >6 Jahren robust.

Man kann naürlich darüber nachdenken, ob man den Program_Alarm quasi ein mal für das Setzen des Triggers (positive Flanke => Meldungserzeugung) und einmal für das Rücksetzen des Triggers (negative Flanke => Quittieren) aufruft.
Das haben wir aber soweit nicht ausprobiert.

 

[xEs1710]

Moment. Mit "Quittieren" setzen wir das Triggerbit zurück.
Und ja: man braucht am SIG einen Zustandswechsel (Flanke).

Guck Dir den Programmcodeschnipsel noch mal genau an.

Program_Alarm wird mit dem "aux" aufgerufen. Das "aux" wird erst zurückgesetzt, wenn der Trigger einmal mit 'false' am SIG vom Program_Alarm vorbei gekommen ist. Damit erkennt der Program_Alarm die negative Flanke und ist wieder bereit, beim nächsten Aufruf (aux) am SIG ein 'true' aufzunehmen, um eine Meldung zu erzeugen.
Das funktioniert bei uns seit >6 Jahren robust.

Man kann naürlich darüber nachdenken, ob man den Program_Alarm quasi ein mal für das Setzen des Triggers (positive Flanke => Meldungserzeugung) und einmal für das Rücksetzen des Triggers (negative Flanke => Quittieren) aufruft.
Das haben wir aber soweit nicht ausprobiert.

Ja das habe ich auch so verstanden. Wenn der Trigger da ist, wird AUX gesetzt und Program_Alarm aufgerufen und der SIG ist sofort gesetzt. Was ich mich frage: Zählt das hier auch als Flanke, das beim "erstmaligen" Aufruf der SIG schon auf TRUE ist?