TIA S7-1500: Melden mit Program_Alarm

H

hub

Level-1
Beiträge
251
Reaktionspunkte
17
Zuviel Werbung?
-> Hier kostenlos registrieren
Beim Program_Alarm kann man ja nur die Meldeklasse "Acknowledgement" und "No Acknowledgement" auswählen.
Womit ich am Terminal nur 2 Farben für Meldungen zur Verfügung habe.

Was mach ich, wenn ich z.B. auch Warnungen und Betriebszustände melden will?

Eine Kombination aus Program_Alarm und Bitmeldeverfahren?
Oder besser nur Bitmeldeverfahren ohne Program_Alarm?
 
Auf welchem Terminal hast du nur zwei Farben für Meldungen? Was meinst du mit Terminal?
Grundsätzlich kannst du ja mehr Alarm Klassen anlegen. Ich nutze die Meldeklasse "Acknowledgement" und "No Acknowledgement" für meine Zwecke gar nicht. Ich habe eigene Meldeklassen "Alarm" "Meldung" "Info" etc.
Idealerweise legst du die Meldeklassen global unter gemeinsame Daten an. Dann erben Panel und Co. diese ebenfalls.

mfG René
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Habe Comfort-Bediengeräte.

Mein Fehler war, dass ich die Meldeklasse unter HMI / HMI-Meldungen / Meldeklassen angelegt hatte.
Nachdem ich eine passende Meldeklasse unter "gemeinsame Daten" angelegt habe, konnte ich die Meldeklasse auch am Program_Alarm auswählen.
Danke für den Tip mit den gemeinsamen Daten.

Noch kurz eine Frage zum Program_Alarm:
Habe schon viel Negatives zu diesem Baustein hier gelesen, obwohl mich die Vorteile eigendlich überzeugen.
Ich möchte in einem Ventilbaustein alle Zustände und Störungen melden, und habe dies bisher mit dem Bitmeldeverfahren gemacht.
Macht es Sinn, auf den Program_Alarm umzusteigen?
Zyklusbelastung ist bei mir (noch) kein Problem.
 
Grundsätzlich ist Program_Alarm eine Tolle Sache. Aber man muss halt die Systemgrenzen beachten und die stehen halt nur in den Technischen Daten der CPU.
Eine 1515er kann z.B. 600 Meldungen gleichzeitig generieren, keine einzige mehr. Ein Drumherumarbeiten ist mit den Möglichkeiten die Program_alarm bietet nicht möglich.

600 Meldungen hören sich nach viel an. Wenn man allerdings z.B. auch Handschalter per INFO melden will dann ist das auch ne Meldung, genauso wie ne Rückmeldung eines Schützen wenns in die Meldeliste des Panels soll.

Wenn man die Grenze überschreiten will. Ist der Weg eigentlich Prodiag. Baut auch auf Program_Alarm auf, ist aber nicht an diese Systemgrenzen gebunden.

Das Bitmeldeverfahren halt halt viele Nachteile. Man muss Alarmlisten an mehreren Orten Nachführen. Die Meldungen müssen Kommuniziert werden und zwar Wortweise, das heisst es ist n haufen Mapping auf der CPU nötig. etc.
Aber das Mapping muss man womöglich sowieso machen wenn man mit nem WinCC OA drangeht oder mit einem FremdSCADA.
 
Moin hub,

ich hatte auch bedenken bzgl. der Zykluszeit. Allerdings haben wir uns alle Störungen in einem Array[0..n] of bool angelegt. Dann durchlaufen wir eine Schleife und bearbeiten Program_Alarm nur, wenn ein Triggerbit true ist. Das funktioniert sehr gut. Da wir es mit der Menge an Meldungen (2100) aber nicht auf einem anderen Weg versucht haben, kann ich Dir keine Auskunft darüber geben, ob der Einzelaufruf die Zykluszeit deutlich höher belasten würde.

VG

MFreiberger
 
hub schrieb:
nur aus Interesse:
Wo legt der Baustein "Program_Alarm" seine Variablen ab?
Warum kann er nicht in einer FC verwendet werden?
Zum Vergrößern anklicken....

In seiner Instanz legt er seine Variablen ab.
Und er kann nicht in einem FC verwendet werden, weil er eine Instanz benötigt. Bzw er kann in einem FC verwendet werden, dann muss er aber einen eigenen Globalen InstanzDB bekommen, was recht sinnfrei ist.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
hub schrieb:
In der Instanz sehe ich keine Variablen vom Baustein.
Zum Vergrößern anklicken....

Was erwartest du denn da drin zu sehen? ich nehme an das ist systemintern. Wie bei den IEC Timern, da sieht man auch nix in der Instanz.

Kann den Baustein nicht in einer FC einfügen.
Zum Vergrößern anklicken....
Hm. also ich kann in SCL einfach programm_alarm eintippen, dann gehts einfügefenster auf, und da gibt man dann die durchgangsparameter an.
Den FC musst du dann wiederum in einem FB aufrufen. da der TYP Program_alarm nur in Static deklariert werden kann.

mfG René
 
vollmi schrieb:
also ich kann in SCL einfach programm_alarm eintippen, dann gehts einfügefenster auf, und da gibt man dann die durchgangsparameter an.
Den FC musst du dann wiederum in einem FB aufrufen. da der TYP Program_alarm nur in Static deklariert werden kann.

mfG René
Zum Vergrößern anklicken....

Hast du das wirklich mal probiert? Bei mir funktioniert das nicht!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
vollmi schrieb:
Was erwartest du denn da drin zu sehen? ich nehme an das ist systemintern. Wie bei den IEC Timern, da sieht man auch nix in der Instanz.
Zum Vergrößern anklicken....

Ich hätte erwartet, die Schnittstelle vom Program_Alarm zu sehen.
Bei den IEC-Timern ist diese auch zu sehen und belegt in der Schnittstelle und im Instanz-DB 16 Bytes.
Der Program_Alarm belegt im Instanz-DB Null Byte.

Deswegen mein Interesse:
wo werden die Variablen abgelegt?
 
Hab ich gleich mal probiert.
Ein paar Werte sind tatsächlich vorhanden.
Aber was ist mit dem Rest?
Und wo liegen jetzt die Daten wirklich?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
hub schrieb:
Hab ich gleich mal probiert.
Ein paar Werte sind tatsächlich vorhanden.
Aber was ist mit dem Rest?
Und wo liegen jetzt die Daten wirklich?
Zum Vergrößern anklicken....

Die Daten liegen ganz normal im Instanz-DB, TIA blendet diese nur aus, und beim Trace hat wohl jemand gepennt.
Z.B. mit WinCC 7.3 oder 7.4 kannst du auch den Variableninhalt einer 1500er browsen, und dir dann auch die in TIA unsichtbaren ProgrammAlarm Instanz-Variablen als Variable anlegen, denn beim Browsen meldet die SPS diese mit den Attributen HMI Visible+Accessible.
In dem Adress-String den du im WinCC bei den Variablen angezeigt bekommst drin steckt auch die Datenbausteinnummer mit drin, z.B. ...:80A0EABCD.... entspricht Datenbaustein DB 43981. Daran lässt sich sehen, dass das ganz normale Variablen sind.
 
Kann es mit WinCC 7.x nicht probieren.
Habe aber an der DB-Größe erkannt, dass die Daten im Instanz-DB liegen.

Kann man das bei eigenen Routinen auch machen, dass bestimmte Variablen im Instanz-DB nicht erscheinen?
 
MFreiberger schrieb:
Moin hub,

ich hatte auch bedenken bzgl. der Zykluszeit. Allerdings haben wir uns alle Störungen in einem Array[0..n] of bool angelegt. Dann durchlaufen wir eine Schleife und bearbeiten Program_Alarm nur, wenn ein Triggerbit true ist. Das funktioniert sehr gut. Da wir es mit der Menge an Meldungen (2100) aber nicht auf einem anderen Weg versucht haben, kann ich Dir keine Auskunft darüber geben, ob der Einzelaufruf die Zykluszeit deutlich höher belasten würde.

VG

MFreiberger
Zum Vergrößern anklicken....

MFreiberger, vielleicht könntest du euren Aufbau kurz skizzieren?
Die 2100 Meldungen habt ihr aber schon mit jeweils eigener Instanz im Meldeeditor angelegt, oder?
Verwendet ihr das Meldesystem auch in Bibliotheken? Wie sind da die Erfahrungen?

Ich versuche grade den "besten" Weg zu finden und übergebe aktuell die Program_Alarm Instanzen als Parameterinstanz falls das Triggerbit True ist.

Danke und Besten Gruß
 

Similar threads

D
TIA Program_Alarm nicht aufrufbar
Antworten
5
Aufrufe
663
Ralle
Ralle
M
TIA OPC UA Program_Alarm mit Textlistenreferenz senden
Antworten
4
Aufrufe
987
MFreiberger
M
G
TIA Begleitwerte definieren bei Verwendung Program_Alarm im Array
Antworten
3
Aufrufe
1K
maxder2te
M
R
Sonstiges Backup alternative für S7-1500?
2
Antworten
24
Aufrufe
2K
DeltaMikeAir
DeltaMikeAir
M
TIA Zeitschaltuhr mit einer S7-1500 realisieren
Antworten
4
Aufrufe
618
ducati
D
Zurück
Oben