WinCC Programm Alarm vs. Bit Alarm

[Tmbiz]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich stehen gerade vor der Entscheidung, ob ich mein System mit dem Programm Alarm oder dem Bit Alarm programmieren soll. Es geht um eine Verpackungsmaschine; 1515 CPU; TP700. zu 95 Prozent ist es immer nur ein Hmi an der Anlage. Es können aber auch 2 sein.

Was würdet ihr nutzen? Wo sind die Vor- und Nachteile der System? Gibt es bei den Programm Alarmen eine Möglichkeit einen Hilfstext anzuzeigen? Also wenn z.B. eine Meldung kommt, könnte man dann nach dem Drücken einer Taste einen durch die Meldung selektierten Text anzeigen?

 

[de vliegende hollander]

Programmalarm benutzen.
Vorteil ist bearbeitung und texten im SPS.
Zeitstempel aus der SPS. (Zeitfolge richtig Melden).

Bei Bitmeldungen bearbeitest du die Meldungen doppelt. Im SPS und Visu.
Und die Zeitstempel ist so genau wie die aktualisierung der Meldevariable.

 

[faust]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

...
Vorteil ist bearbeitung und texten im SPS.
...

für mich genau umgekehrt:
Nachteil bei Program-Alarm, dass ich Meldetexte im Steuerungsprogramm pflegen muss.


Meine grundsätzlichen Gedankengänge hierzu:
+ Alles, was mit Prozess-Steuerung zu tun hat -> SPS-Projekt
+ Alles, was mit Anzeige/Bedienung zu tun hat -> getrenntes HMI-Projekt
+ Bezüglich Meldungen: Solange nichts anderes einfach plattform-UNABHÄNGIG projektiert werden kann -> Bit-Meldeverfahren

Hat für mich/uns in der Firma folgende Vorteile:
+ Es können die jeweiligen Spezialisten (Steuerungsprogrammierer und HMI-Experten) unabhängig an ihrem Teil des jeweiligen Projektes arbeiten.
+ Beide Seiten müssen sich nur um eine jederzeit "saubere" HMI-PLC-Schnittstelle kümmern.
+ Ein Wechsel der jeweiligen Hard- oder Software-Plattform ist m.M.n. einfacher möglich, da mindestens eine proprietäre Technik weniger eingesetzt wird.


Konkret das Bit-Meldeverfahren betreffend gibt es natürlich auch Nachteile:
+ An sich gleiche Meldetexte müssen mehrfach behandelt werden, auch wenn sich "nur" der Störungsort (Maschine, Modul, Funktion, Bauteil) unterscheidet.
Eine gleichzeitige Triggerung des gleichen Meldetextes mit dynamisch eingebundenen Werten für die o.g. Infos funktioniert nämlich (LEIDER!!!!) nicht.


Gruß, Fred

 

[acid]

Eventuell sollte man sich im Zuge dieser Entscheidung auch mal ProDiag ansehen, das nimmt einem schon verdammt viel Arbeit ab und erleichtert die Diagnose der Anlage (Schrittketten, Verriegelungen, ...) ungemein. Es muss natürlich immer zur Anlage passen, es gibt sicher keine allgemeingültige Empfehlung welches Verfahren nun besser ist.

 

[JSEngineering]

Ich sehe das auch eigentlich eher wie Fred in #3.
Vor allem: Wie läuft das bei Sprachumschaltung? Dann müßte ich ja alle Sprachen im SPS-Programm pflegen. oder geht das überhaupt mit dem Program-Alarm?

 

[Ludewig]

Zuviel Werbung?
-> Hier kostenlos registrieren

@ #5
Ist auch mein Problem:
Bei Anlagen im Ausland arbeite ich immer dreisprachig, Zielsprache, Englisch und Deutsch. Dann muss ich mir die aktuelle Sprache aus dem HMI fischen und mir den richtigen Meldetext raussuchen?
Außerdem geht die HMI-Tablle als *.ods/xlsx an den Übersetzer und zurück ins HMI.

 

[ducati]

Den S7-1500 Programm Alarm gibts ja unter Step7-Classic als ALARM_S ALRAM_DQ ALARM_8 ja schon länger.

Unter PCS7 muss man da eigentlich garkeinen Meldetext mehr projektieren. Im Pumpenstandartbaustein werden die Alarmtexte einmalig definiert, z.B. Betrieb oder FU-Störung. Durch den Aufruf des Pumpenbausteins in der technologischen Hierarchie wird der Rest des Meldetextes automatisch zusammengebaut. Also "Standortname-Anlagenname-Teilanlagenname-Pumpe4711-FU-Störung"

Wenn man das im TIA auch so ähnlich automatisiert hinbekommt, hat das schon Vorteile...

 

[Thomas_v2.1]

Der Programm-Alarm hat aber einige Nachteile wie hohe Zyklusbelastung. Außerdem scheint es einige Bugs zu besitzen, so dass - wenn man einigen Forenthreads hier Glauben schenken darf - viele sich nicht auf den Zeitstempel des Systems verlassen, sondern einen eigenen Zeitstempel als Begleitwert mitschicken müssen.
Und da Siemens mit ProDiag ein weiteres (kostenpflichtiges) System anbietet welches etwas anders funktioniert anstatt sich rein auf den Programm-Alarm zu verlassen, spricht nicht gerade dafür das Verfahren einsetzen zu müssen.

Und falls du gelegentlich kleine Anlagen mit einer S7-1200 oder einem Basic-Panel einsetzen möchtest, müsstest du weiterhin eine zweite Bausteinfamilie für das Bitmeldeverfahren pflegen, da Programm-Alarm mit beiden nicht funktioniert.

Wenn deine Maschinen immer nur aus 1500 und Comfort Panel bestehen, und ohne Kommunikation zu Fremdsystemen, dann wäre das eine Überlegung wert. Es gibt auch welche die beides vorhalten, also Meldungen mit Program-Alarm generieren und zusätzlich als Triggerbit für Bitmeldungen zur Verfügung stellen.

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Man braucht das Meldebit ja meist auch noch an weiteren Programmstellen in der SPS...

Also unter Step7 Classic hab ich viel Alarm_DQ im Zusammenspiel mit CFC und WinCC7 verwendet, das macht schon Spaß.
Unter TIA eigentlich immer nur Bitmeldungen

 

[Thomas_v2.1]

Man braucht das Meldebit ja meist auch noch an weiteren Programmstellen in der SPS...

Die Siemens Bediengeräte erlauben als Triggervariable für eine Meldung ja keine Bools sondern nur Word/Int.
Das habe ich nie verstanden warum das unbedingt so sein muss, denn nur dadurch muss ich ja mit AT-Überlagerungen, Slice Zugriffen arbeiten anstatt alles mit einem passenden Symbol zu erledigen. Das ist auch nur bei den Siemens Bediengeräten so.

 

[PN/DP]

Die Siemens Bediengeräte erlauben als Triggervariable für eine Meldung ja keine Bools sondern nur Word/Int.

Ich vermute, das ist/war vorteilhaft für hohe Kommunikations-Effizienz (bei langsamen HMI-Anbindungen), wenn man neben den im Bild verwendeten Variablen auch noch ständig hunderte Alarm-Bits lesen muß.

Harald

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Siemens Bediengeräte erlauben als Triggervariable für eine Meldung ja keine Bools sondern nur Word/Int.
Das habe ich nie verstanden warum das unbedingt so sein muss, denn nur dadurch muss ich ja mit AT-Überlagerungen, Slice Zugriffen arbeiten anstatt alles mit einem passenden Symbol zu erledigen. Das ist auch nur bei den Siemens Bediengeräten so.

Wir haben einen Global-DB mit aufeinanderfolgenden Bool mit wahlweise 1000 oder 10000 Meldungen...
Da kannst dann im Meldesystem der Visu schon absolut adressiert per Word drauf zugreifen
Nur brauchst die Meldungen aber in der Visu noch zusätzlich als Bool um das einfach ohne Bitzählerei in nem Bild zu verwenden...

Der Kommentar in dem Global DB ist dann auch gleich der Meldetext im Panel. Kannst also in einem Rutsch per Strg C Srtg V rüberkopieren...

Gruß

 

[Thomas_v2.1]

Ich vermute, das ist/war vorteilhaft für hohe Kommunikations-Effizienz (bei langsamen HMI-Anbindungen), wenn man neben den im Bild verwendeten Variablen auch noch ständig hunderte Alarm-Bits lesen muß.

Das könnte ja der Treiber optimieren wenn die Bools hintereinander liegen, und anstelle der Bools ein ganzes Byte lesen. So machen es auch alle Kommunikationstreiber, außer der von WinCC flexible / TIA Panels.

 

[faust]

...
Unter PCS7 muss man da eigentlich garkeinen Meldetext mehr projektieren. Im Pumpenstandartbaustein werden die Alarmtexte einmalig definiert, z.B. Betrieb oder FU-Störung. Durch den Aufruf des Pumpenbausteins in der technologischen Hierarchie wird der Rest des Meldetextes automatisch zusammengebaut. Also "Standortname-Anlagenname-Teilanlagenname-Pumpe4711-FU-Störung"
...

Dann wird der jeweilige Meldungstext aber doch auch im Steuerungsprogramm behandelt, halt nur als Text-FRAGMENTE, die dynamisch zusammengesetzt werden!!??


Das "Zusammenbauen" funktioniert ja auch bei Bitmeldungen (Textlisten- oder Variableneinbindung), nur leider werden die dynamischen Bestandteile bei gleichzeitiger Triggerung einer Meldung mit unterschiedlichen Werten nicht korrekt in der Meldungsanzeige behandelt.

Szenario:
1. Triggerung des Meldungsbits "Störung Antrieb" mit "Teigherstellung - Kneter 1 - Bottichantrieb" als dynamische Ortsangabe
-> in der Meldeanzeige erscheint
-------------------------------------------------------------------------------------------------------
11.03.2021 18:38 Teigherstellung - Kneter 1 - Bottichantrieb: Störung Antrieb
-------------------------------------------------------------------------------------------------------

2. Triggerung des Meldungsbits "Störung Antrieb" mit "Teigherstellung - Kneter 2 - Spiralantrieb" als dynamische Ortsangabe (Meldung 1 ist immer noch aktiv!!!!)
-> in der Meldeanzeige erscheint
-------------------------------------------------------------------------------------------------------
11.03.2021 18:40 Teigherstellung - Kneter 2 - Spiralantrieb: Störung Antrieb
11.03.2021 18:38 Teigherstellung - Kneter 2 - Spiralantrieb: Störung Antrieb
-------------------------------------------------------------------------------------------------------

Wenn die Meldeanzeige eingehende Meldungen "einfrieren" würde...


Gruß, Fred

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja, das sind mit dem Alarm DQ ja auch mehrere Meldungen die fürs WinCC dann angelegt werden. Nur muss ich den Text eben nirgends händisch eintippen.

Bei Bitmeldungen hab ich mit dynamischer Textgenerierung nie experimentiert...

 

[faust]

...
Nur muss ich den Text eben nirgends händisch eintippen.
...

???
Mindestens der Text "Störung" muss in deinem Beispiel doch irgendwo herkommen. Oder verstehe ich da etwas falsch?

 

[ducati]

???
Mindestens der Text "Störung" muss in deinem Beispiel doch irgendwo herkommen. Oder verstehe ich da etwas falsch?

Nee...
In der technologischen Hierarchie werden einmalig die Namen der Anlage, Teilanlage festgelegt.
Im Bibliotheksbaustein für die Pumpe werden einmalig die Texte Betrieb Störung Sicherungsfall Repschalter usw. eingetragen.
Beim Aufruf des Pumpen-Bausteins wird nen Bausteinkommentar vergeben Pumpe4711

Daraus wird der Meldetext automatisch zusammengebaut "Anlage - Teilanlage - Pumpe4711 - Repschalter"

Bei der nächsten Pumpe steht im Bausteinkommentar Pumpe4712. Daraus wird dann automatisch die Meldung "Anlage - Teilanlage - Pumpe4712 - Repschalter"

Aber wie gesagt, das ist für PCS7 bzw. Step7 classic. Wie und ob das unter TIA geht, weiss ich nicht.

 

[faust]

Zuviel Werbung?
-> Hier kostenlos registrieren

Aber fast alle Texte, die du jetzt genannt hast, sind doch sprachabhängig??

Und der Bausteinkommentar sollte doch eigentlich nicht mit irgendwelchen Bildschirmausgaben zusammenhängen.


Aber nochmal: meine Fragen resultieren wahrscheinlich aus Unwissenheit, habe bis jetzt nie mit PCS7 zu tun gehabt.


PS:
Zur Verdeutlichung, warum ich etwas ungläubig reagiere: wir haben Maschinen, wo ich im standardisierten HMI-Projekt ca. 20 verschiedene Sprachen, demzufolge ca. 30 verschiedene Locales (Sprach-Länder-Kombinationen) pflege...

 

[ducati]

Aber fast alle Texte, die du jetzt genannt hast, sind doch sprachabhängig??

Und der Bausteinkommentar sollte doch eigentlich nicht mit irgendwelchen Bildschirmausgaben...

Verschiedene Sprachen kannst auch festlegen...
Und irgendwo musst den Namen der Pumpe ja eingeben und da bietet sich der Bausteinkommentar im CFC an...
Grundsätzlich funktioniert vieles vom PCS7-Konzept auch unter Classic mit CFC und WinCC7...
Hab mir halt dafür mal ein PCS7light gebaut, da ich ursprünglich aus der PCS7-Welt komme...

 

[ducati]

Die 20 Sprachen machens nicht einfacher Hab mal deutsch englisch chinesisch gemacht, da krigst das Kotzen
Aber Prozessautomatisierung unterscheidet sich in den Anforderungen auch vom Maschinenbau...