# ProgramAlarm: wie legt Ihr die nötigen Signale an?



## Grimsey (2 Juli 2019)

Hallo zusammen,

ich bin gerade dabei ein Programm von einem Zulieferer umzugestalten, so dass z.B. die vielen Abkürzungen raus sind und es besser in unser System passt.
Dabei bin ich jetzt auf einige Meldungen gestoßen die über "ProgramAlarm" erzeugt werden.
Der Baustein benötigt ja ein zwei Signale am Ausgang "Error" und "Status".

Mir fällt aber nicht so wirklich was ein, wie man die a) etwas "besser" bezeichnen könnte und b) wie man die Struktur im statischen Bereich des aufrufenden FBs besser organisieren kann (siehe Bild).

Die Signale werden vom Lieferanten aber gar nicht weiter ausgewertet:?: (dann kann ich die doch auch weglassen oder werte sie aus)


Daher dachte ich mir, ich frage mal Euch wie Ihr das so handhabt? Würde da gerne noch was ändern und mich bilden.

Über ein paar Rückmeldungen würde ich mich freuen.

Habt vielen Dank!


----------



## Howard (2 Juli 2019)

Moin,
ich kann auf deinem Screenshot leider nichts erkennen :sad:


----------



## Grimsey (2 Juli 2019)

Oh sorry,

habe ich jetzt erst gesehen. Ich habe nochmal 2 größere Bilder angehängt


----------



## Howard (2 Juli 2019)

Also über die Namen kann man natürlich endlos diskutieren, da finde ich deinen Ansatz, den in "eure interne Firmen-Sprache" zu übersetzen, am sinnvollsten. Nur wenn der Error und der Status eh nicht ausgewertet werden, dann kannst du ihn natürlich auch gleich ganz weg lassen.

Ich persönlich beschalte solche FB-Ausgänge eigentlich eh nie, denn wenn ich sie verwenden will, dann greife ich in deinem Fall einfach auf #fb_err_ini_calm_on.Error direkt zu - so spart man sich dann eine Temp-Variable.
Grundsätzlich würde ich an deiner Stelle aber nochmal mit dem Lieferanten sprechen, denn es hat ja einen Grund warum an diesem Baustein ein Fehler rausfallen kann. Gerade beim Meldeschwall, also dem Gleichzeitigen erzeugen von vielen Meldungen, kann da mal was schief gehen.
bspw. Status 80c2 - Die maximale Anzahl von Meldungen pro Zeiteinheit wurde gesendet - versuchen sie es später nochmal.


----------



## Grimsey (2 Juli 2019)

@Howard,

danke für Deine Meinung.
Mit dem Lieferanten zu sprechen bringt leider wenig. Jedesmal wenn ich mit dem spreche, habe ich immer mehr das Gefühl das er noch nicht so oft SIEMENS-SPS programmiert hat und da ehrlich gesagt vermutlich gar nicht sagen kann, warum er das so und nicht anders programmiert hat. Das zeigen mir auch sehr viele andere Stellen im Programm. Aber das soll hier nicht Thema sein.

Ich hatte noch die Idee die ProgramAlarm-Bausteine in einem Array zu deklarieren. Über die Kommentare des Array kann man dem jeweiligen Baustein dann auch noch einen sinnvollen Namen mitgeben.
Ich müsste in meinem Fall dann nur die ganzen Meldetexte wieder konfigurieren und da habe ich (noch) keine Lust drauf.


----------



## Howard (3 Juli 2019)

Also ich verwende den Program_Alarm zur Zeit noch nicht, da er ja recht Ressourcen fressend sein soll. Aber in einem kurzen inhouse Test habe ich damit auch schon rumgespielt. Ich hatte dabei auch zwei Ansätze verfolgt. Zum einen habe ich die Einzelinstanzen so wie bei dir benutzt, bspw. in FBs die einen einzelnen Förderer steuern und durch den Program_Alarm dann ihre Fehler bilden. Diese Förderer-FBs sind alles Multi-Instanzen und müssen deshalb halt mit eigenen Instanzen vom Program_Alarm arbeiten. Zum anderen habe ich aber auch immer einen Programm-Teil der bspw. allgemeine Fehler bearbeitet, bspw. Hardware-Fehler, also ausgelöste Sicherungen oder so. Hier war mein Ansatz dann auch, den Program_Alarm als Array in einem Global-DB zu deklarieren und einen zweiten Global-DB mit der gleichen Anzahl an Elementen von Typ UDT bestehend aus Trigger-Bit und Meldetext. Dann konnte ich überall im Programm wo Störungen gebildet werden sollen, einfach das Bit aus dem Trigger-DB setzen und den Meldetext schreiben und am Ende des OB1 einen Baustein aufrufen, der in einer Schleife alle Program_Alarme mit indiziertem Trigger-Bit und indiziertem Meldetext aufruft. Das ganze habe ich dann noch verfeinert, indem ich nur noch die Program_Alarme aufgerufen habe, bei den sich mein Trigger-Bit und der Trigger-Eingang des Program_Alarm unterscheiden - um so wirklich nur noch den Baustein zu bearbeiten, wenn ein Trigger gekommen oder gegangen ist. Das hat auch tadellos funktioniert. So hunderprozentig hat mich das aber noch nicht überzeugt und liegt deshalb noch auf dem "muss ich nochmal drüber nachdenken"-Stapel


----------



## ioStart (3 Juli 2019)

Hallo,

wir haben dieses Meldungssystem erfolgreich im Einsatz und sind recht zufrieden damit. Meiner Meinung nach wird dadurch ein übersichtlicherer Programmierstil ermöglicht, da die Beschaltung und die Definition des Meldungstextes im selben Ort/beim gleichen Arbeitsgang gemacht werden kann.  In diesem Fall ist FUP recht funktionell.

Außerdem ist die Wiederverwendbarkeit durch OOP genial.

Einziges Manko welches ich bis heute nicht klären konnte, ist ein Alarmzähler. Man kann nicht ohne weiteren Programmieraufwand eine Zahl erfassen, welche Aufschluss über die aktuell anstehenden Meldungen gibt. Es gibt zwar am HMI die klassische systemeigene Melde-icone mit der Anzahl, jedoch passt die bei uns nicht ins Bedienkonzept 

Die Ausgänge des Baustein verwenden wir nicht.


----------



## Fireman_Frank (4 Juli 2019)

Wo wir hier gerade beim ProgrammAlarm sind:
Ich habe diesen jetzt auch bei der ersten Anlage eingesetzt, und es funktioniert soweit ganz gut. Aber ich tue mich schwer damit eine Störung rückzuverfolgen. Gibt es einen Zusammenhang zwischen der im HMI angezeigten Meldenummer und der ID in den Meldungsinstanzen? Oder einfacher gefragt, wie komme ich anhand einer im HMI angezeigten Meldung zu der Stelle im SPS-Programm an der diese erzeugt wird?


----------



## ioStart (4 Juli 2019)

Hallo,

ja mit den ID`s wirds kniffliger. Man muss diese gezielt suchen. Wir geben im Meldungstext immer einen Bezug zur Maschinen-einheit an. Damit lässt sich Verwendungsstelle stark eingrenzen

Suche anhand der ID:


----------



## vollmi (8 Juli 2019)

ioStart schrieb:


> ja mit den ID`s wirds kniffliger. Man muss diese gezielt suchen. Wir geben im Meldungstext immer einen Bezug zur Maschinen-einheit an. Damit lässt sich Verwendungsstelle stark eingrenzen



Ich übergebe dem Meldetext den Instanznamen des Bausteins. Damit ist der Fehler dann recht gut zuzuordnen.

Was mit aber von ProgrammAlarm zu Prodiag umschwenken ließ, ist die geringe Anzahl ProgramAlarm die gleichzeitig aufgerufen werden können.
Bei einer 1512sp z.B. 300 gleichzeitiger Meldungen. Da ich aber ja nicht nur Alarme generiere sondern auch Betriebsmeldungen gibt (Schütz ein, Schalter Hand etc.) sind auch bei kleinsten Programmen schnell die anzahl Meldungen überschritten. Alternierendes Meldungen generieren geht ja auch nicht so ohne weiteres, weil man ja nicht abfragen kann, wie viele ProgrammAlarm schon laufen.

mfG René


----------



## ioStart (8 Juli 2019)

hallo vollmi

wenn ich fragen darf: was bezweckt ihr damit, wenn ihr Betriebsmeldungen dieser Art realisiert? Ein Logging für Auswertungen?
Bei unseren Maschinen legen wir viel wert darauf, dem Bediener möglichst wenige Meldungen zeitgleich anzuzeigen. Das bedeutet, dass eventuelle Folgefehler von beispielsweise einem Motorschutz-Alarm ausgeblendet/gesperrt werden

Gruß
ioStart


----------



## vollmi (8 Juli 2019)

Betriebsmeldungen landen natürlich nicht im Alarm/Störmeldebild. Aber sie können in einem Separaten Historikfenster dargestellt werden. Wir nutzen das vor allem bei Anlagen ohne übergeordnete Bedienung um die Schalthistorie nachzuvollziehen.

Beispiel:
Spannungsaufall Anlagenweit. das ist eine hochpriorisierte Alarmmeldung die dem Betreiber angezeigt wird.
Der Ausfall der Rios wird aber mit einem anderen Filter dargestellt (ebenfalls hochpriore Alarmmeldung). Das sind zwar Folgefehler, man will aber durchaus wissen wann die USV derselben die Grätsch gemacht haben.
Dass dann aber die Reservebeleuchtung angegangen ist, die normalerweise nur in der Nacht leuchtet, das ist nur eine Betriebsmeldung. Man kann aber später nachsehen ob diese Beleuchtung die als einzige über Notnetz verfügt auch wirklich Tagsüber wegen Stromausfall angegangen ist.
Im Fehlerfall kann man auch nachsehen ob der Trafoschütz auch wirklich abgeschalten hat BEVOR der Bypassschütz reingegangen ist.


----------

