TIA Meldungen mit Program_Alarm

Was mit eben Kopfschmerzen bereitet ist das Umschichten zur PLS
Die zu kommunizieren Signalen in ein UDT packen. Diese UDT im Auggangsschnittstelle des FB/FC benutzen.
Datenbaustein anlegen mit dem UDT. Für jedes Ventil 1 UDT.
Dann einfach rangieren.

Das PLS ist sowieso oder hochstwarscheinlich kein Zeitfolge Richtiges melden für deine Steuerung
 
Am Ende empfiehlt selbst Siemens nach Möglichkeit ProDiag anstatt ProgramAlarm zu verwenden...
(...)

Ja, weil ProDiag eine zusätzliche Lizenz benötigt und die Kasse beim Siemens klingeln lässt. Da wird nämlich eine im Endeffekt uralte, schon lange, lange abgeschriebene Technik zu reinem Gold umgewandelt ;)

Der Vorteil beim Program_Alarm wurde ja schon benannt. Ich packe den in einen geschlossenen Baustein, gebe ihm alle möglichen Fehler mit und muss in allen angeschlossenen HMIs und Diagnosepuffern nix mehr weiter machen, als die Meldeklasse anzuhaken und das Panel einmal zu laden, schon hab ich alle Alarme/Störungen/Infomeldungen.
Keiner muss in den Baustein reingreifen können, die Program_Alarm purzeln da einfach raus...

Allerdings eignet sich das in der Form nur für Leute, die keinen Meldungsregen aus Fehler und Folgefehler haben wollen.
Wer beim Ausfall einer ET200SP auch noch alle 200 Folgefehler für die I/O bekommen möchte, weil Temperaturen, Strommesswerte, Eingänge, Ausgänge, Drahtbrüche, Spannungseinbrüche, usw. pro Kanal 2, 3, 4 Folgefehler erzeugen... der ist mit dem Program_Alarm schlecht bedient.

Wer seine Anlage sinnvoll strukturiert und dann einen Program_Alarm zum Beispiel für die Sicherungen im NSHV-Schrank hat, einen pro Ventil, einen pro Antrieb... der kann mit 10, 15, vielleicht 50 Program_Alarm Bausteinen hunderte bzw. eher tausende Störmeldungen abdecken.
Wer mehr braucht, der programmiert sich einen Alarm-Stack, aus 3 oder 5 Program_Alarm-Bausteinen.

Egal welcher Kunde. Bisher konnte man jedem den Zahn ziehen, dass er bei einem Fehler grundsätzlich alle, wirklich alle Folgefehler sehen wollte.
Denn das hilft nicht. Wenn die Hauptsicherung für die "Müllergasse" gefallen ist, dann ist das die Fehlerursache und es interessiert niemanden, dass in den Häusern Müllergasse 1-78 die Spannung weggebrochen ist...
Nachtrag:
Der Program_Alarm würde in dem Fall 78 Einträge für die Müllergasse 1-78 bekommen und einen Eintrag für die Hauptsicherung. Die Wahrscheinlichkeit, dass in 1-78 gleichzeitig eine Sicherung auslöst, die ist gering, das nehmen wir in Kauf.
In dem Fall würde der ProgramAlarm nach Behebung in Haus Nummer x eben die nächste Störung in Haus Nummer y zeigen. Wer das nicht möchte, baut sich einen AlarmStack für die Zahl Fehler, deren gleichzeitiges unabhängiges Auftreten er für realistisch hält.

PS:
Der SINAMICS macht das übrigens nicht anders. Der gibt im Störcode standardmäßig die erste gekommene Störung aus.
Denn der Rest... der ist Folgefehler und interessiert niemanden...
 
Zuletzt bearbeitet:
einen pro Antrieb... der kann mit 10, 15, vielleicht 50 Program_Alarm Bausteinen hunderte bzw. eher tausende Störmeldungen abdecken.
Wer mehr braucht, der programmiert sich einen Alarm-Stack, aus 3 oder 5 Program_Alarm-Bausteinen.
Wie kann man denn pro Program_Alarm mehrere Meldungen generieren, oder habe ich das falsch verstanden?
Bisher habe ich einen Baustein pro Meldung.

Was ist ein Alarm-Stack?


Ein Update:
Das Prozessleitsystem soll scheinbar eine PCS7 sein. Macht es das in irgendeiner Form einfacher?

Ich habe heute etwas mit Program_Alarm und Get_Alarm gespielt.
Meldungen absetzen die Abhängig vom Instanznahmen benannt werden funktioniert jetzt und der Get_Alarm sammelt diese Meldungen auch ein.

Habt ihr Ideen und Anregungen wie ich die Daten von Get_Alarm aufbereite und dann an die PCS7 weitergeben kann? Brauchbar ist vermutlich der Alarmtext, State (kommend, gehend) und die PRIO.
 
Wie kann man denn pro Program_Alarm mehrere Meldungen generieren, oder habe ich das falsch verstanden?
Bisher habe ich einen Baustein pro Meldung.

Was ist ein Alarm-Stack?
Gemeint is (denke ich) ein Alarm 8P nach zu bauen.
Ein Stack ist ein Speicher.

Ein Update:
Das Prozessleitsystem soll scheinbar eine PCS7 sein. Macht es das in irgendeiner Form einfacher?
Das macht es tatsächlich einfacher.
Es ist an die PCS7 Seite zwar nicht PCS7 Komform. Aber scheiß drauf.

Du kannst die ProgramAlarm Meldungen mit Scada Export aus deiner 1500 exportieren.
Und dann im PCS7 importieren.
Dazu eine 1500er Treiber Verbindung anlegen und die Meldungen als AS importieren.
So quick und dirty erklärt.
 
Wie kann man denn pro Program_Alarm mehrere Meldungen generieren, oder habe ich das falsch verstanden?
Du kannst mehrere Instanzen des FBs haben, glaube das hat er gemeint.
=> 3 Programm_Alarm im FB deiner Baugruppe
=> 100 FB-Instanzen
=> Effektiv 300 Meldungen im Programm
Musst den Meldetext dann aber auch so gestalten, dass du auch die Info bekommst welche Instanz den Alarm geworfen hat, z.B. per Schlüsselwort oder Begleitwert (die waren aber, sofern sich nichts geändert hat, auf 512 Byte/CPU begrenzt).
 
Ein Update:
Das Prozessleitsystem soll scheinbar eine PCS7 sein. Macht es das in irgendeiner Form einfacher?
ich würd da auf jeden Fall mit dem Kunden vorher klären, wie und was Du da machen darfst oder sollst!!!

Normalerweise arbeitet PCS7 mit S7-400!!! Also im PCS7 wird nicht nur die Visu programmiert sondern auch die SPS und das ganze nach dem PCS7-Standard, der ziemlich restriktiv ist.

Wenn die 1500er für Dein Projekt bestätigt/freigegeben ist, würd ich trotzdem nachfragen, ob 1500er Program_Alarm Meldungen dort intergriert werden dürfen! Oder ob sogar die Meldungen über ne bestehende 400er als Datensammler eingekoppelt werden...

Was machst Du denn mit Messwerten usw.? Oder sollst Du wirklich nur Meldungen ans PCS7 übergeben?
 
Zuletzt bearbeitet:
Du kannst mehrere Instanzen des FBs haben, glaube das hat er gemeint.
=> 3 Programm_Alarm im FB deiner Baugruppe
=> 100 FB-Instanzen
=> Effektiv 300 Meldungen im Programm
Musst den Meldetext dann aber auch so gestalten, dass du auch die Info bekommst welche Instanz den Alarm geworfen hat, z.B. per Schlüsselwort oder Begleitwert (die waren aber, sofern sich nichts geändert hat, auf 512 Byte/CPU begrenzt).
Verstehe ich das richtig, ich habe z.b. 3 Aufrufe des Program_Alarm in meinem Ventil-Baustein und rufe ihn 100 mal auf.

Genau, ich habe in der Fehlermeldung den Instanznamen verwendet, so spare ich mir auch die Übergabe einer Ventilbezeichnung, wenn ich die Instanz richtig benenne.
 
ich würd da auf jeden Fall mit dem Kunden vorher klären, wie und was Du da machen darfst oder sollst!!!
Ja, das habe ich mir auch gedacht.
Bei uns weiß gefühlt keiner so richtig Bescheid. Habe gestern angestoßen, dass wir uns mit den Verantwortlichen für das PLS zusammensetzen.

Unsere Anlage ist als Blackbox ausgelegt. Deshalb mache ich mir um unsere internen Meldungen nicht so viele Sorgen.
Nur die Schnittstelle sollte mal geklärt werden.

Was machst Du denn mit Messwerten usw.? Oder sollst Du wirklich nur Meldungen ans PCS7 übergeben?
Scheinbar sollen sämtliche Daten, die bei uns auf der Visu angezeicht werden, auch an die PCS7 gehen. Also auch Messerwerte, Entlagen usw.
 
Zuletzt bearbeitet:
Bei uns weiß gefühlt keiner so richtig Bescheid
Mit PCS7 sind schon mehrere auf die Nase gefallen...
Scheinbar sollen sämtliche Daten, die bei uns auf der Visu angezeicht werden, auch an die PCS7 gehen. Also auch Messerwerte, Entlagen ususw.
Das wird spassig. Wie willst Du denn Deinen Messwert in nen PCS7-Messwert bringen?
Das geht eigentlich nur ordentlich, wenn Du Deine Daten von Deiner 1500er zu ner PCS7 400er rangierst und in der 400er dann die PCS7-Bibliotheken verwendest...

Nur mal zum Einstieg wie das aussieht:



Nen PCS7-Messwertbaustein/Objekt hat pro Messwert 100erte Variablen in SPS und Visu...
 
Unsere Anlage ist als Blackbox auausgelegt.
Da sollte es ja beim Kunden für sein Werk schon ein Konzept/Standard geben, wie 1500er Package Units angekoppelt werden können und sollen...

Das mit dem Program_Alarm würd ich Deinerseits nie im Leben favorisierten!!!
Mach 2 Global-DBs für Meldungen und Messwerte, wenn Du das beim Kunden so durchkrigst... Dann bleibt die Schnittstelle einfach und überschaubar! Und es ist egal, ob die 2 DBs dann zum WinCC oder zur 400er rangiert werden...

Ist halt die Frage, wie viel der PCS7-Funktionalität Du abbilden musst.
 
Naja, ich würd das mit dem Kunden klären, bevor ich hinterher alles nochmal mache. PCS7-Kunden sind ja in der Regel etwas größer und haben meist konkrete Vorstellungen, was sie wollen oder nicht wollen...
Unsere Anlage ist als Blackbox ausgelegt. Deshalb mache ich mir um unsere internen Meldungen nicht so viele Sorgen.
Nur die Schnittstelle sollte mal geklärt werden.
Natürlich erst mit dem Kunde klären.
Wie und auf welche Art und weise sind schon Fremdsteuerungen mit angebunden.
Signalaustauschliste erstellen. (Nach UDT Muster)

Interessehalber; Neubau oder Nachrüstung?

Das mit ein PCS7 komforme Datensammler kommuniziert wird is eine saubere Lösung.
Auch schon mal bei eine Kunde gemacht. (Wo wir aktuell komplett auf PCS7 umbauen)
 
Mit PCS7 sind schon mehrere auf die Nase gefallen...
Es bleibt spannend :D

Da sollte es ja beim Kunden für sein Werk schon ein Konzept/Standard geben, wie 1500er Package Units angekoppelt werden können und sollen...
Alles klar, da werde ich mal nachhaken

Interessehalber; Neubau oder Nachrüstung?
Es ist ein kompletter Neubau.
Ist eine Wasserstofferzeugung und wir liefern das VE-Wasser.
 
Zuletzt bearbeitet:
Da wird halt gleich wie immer in Deutschland schon am Anfang die Weiche so gestellt, dass alles im Chaos endet...

Wenn PCS7 gesetzt ist, was ja für ne Neuanlage u.U. auch ne gute Idee ist, dann sollten auch alle verfahrenstechnischen Teil-Anlagen damit gebaut werden und somit ziemlich einheitlich und standardisiert sein...

Vermutlich aus Kostengründen wird dann für jede Teilanlage was anderes hergenommen und man kann sich PCS7 gleich ganz sparen...

Wie groß ist die VE-Anlage, also Anzahl der Feldgeräte ungefähr?

Aber was reg ich mich auf, ist halt wie immer :rolleyes::sick:😭🙈🤷‍♂️

Letztens wurde hier bei nem Großkunden diskutiert in nem Bestandswerk mit 100erten bestehenden SPSn PCS7 als Leitsystem nachträglich oben drüber zu setzen🙈 Die Leute haben einfach überhaupt keine Ahnung, was PCS7 eigentlich ist. Es ist eben keine Visualisierung, sondern ein einheitlicher Programmierstandard für SPSn + Visu... Falls ich nur die Visualisierung (also Leitsystem, nicht Prozessleitsystem) brauche, sollte man WinCC 7 hernehmen...

Wenn man Fremdsysteme ans PCS7 anbindet, hat man halt nur ein Bruchteil der eigentlichen PCS7 Funktionalität, sollte man wirklich nur für kleinste Package Units von abgeschlossenen Miniteilgeräten machen...

Schau Dir mal die PCS7 Getting Started an, damit Du weisst, wovon ich rede:

 
Zuletzt bearbeitet:
Zurück
Oben