TIA S7-1500: Melden mit Program_Alarm

Zuviel Werbung?
-> Hier kostenlos registrieren
Moin EnCoder,

unser Aufbau ist quasi ein Zwitter aus Bitmeldungen (also wir haben ein Array[0..xy] of Bool, in dem jedes Bit für eine Meldung steht.
Mit diesen Bits stossen wir dann den Program_Alarm an.

Den Program_Alarm rufen wir in einer Schleife auf. Er wird nur aufgerufen, wenn das Triggerbit true ist. Die Texte für die Alarme stehen in einer Meldetextliste.
Anhand des Scheifenzählerwertes greifen wir auf den Text zu. Der Text ist dann ein Begleitwert.

VG

MFreiberger
 
Hallo und danke für die schnelle Antwort!

Ich überlege jetzt grade was sinnvoller ist:

- die Meldungen in einer oder mehreren Textlisten organisieren und Zusatzdaten (Meldeklasse o.ä.) per Begleitwert mitgeben
- für jede Meldung eine Instanz von Program_Alarm verwenden und alles im Meldeeditor eintragen

Wie ist euer vorgehen, wenn ihr Meldungen ergänzen müsst?
Super wäre natürlich wenn man in SCL die Länge einer Textliste ermitteln könnte, aber ich denke das geht nicht.

Besten Gruß
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.

???
Was mappst du da?
Alarmlisten an mehreren Orten? Meinst du für mehrere HMI?
 
???
Was mappst du da?
Alarmlisten an mehreren Orten? Meinst du für mehrere HMI?

Da man ja beim Bitmeldeverfahren im WinCC flex ja nur wörter angeben kann und man die Alarme ja meisten als einzelne Bits in verschiedenen Strukuren hat, muss man die ja irgendwann auf ein Wort kopieren, dass man dann im HMI angeben kann. Danach muss man im HMI die textlisten führen die auf die entsprechenden Triggerbits verweisen.

bei Programmalarm mach ich es mir einfach, der Alarm löst n programmalarm aus, als Text liegt entweder n anwenderdefinierter Text vor, oder ich stell den Text aus Instanzname, Fehlertext etc automatisch zusammen. Das alarmhandling ist also schon fertig wenn man den Baustein ins Programm zieht.

mfG René
 
Da man ja beim Bitmeldeverfahren im WinCC flex ja nur wörter angeben kann und man die Alarme ja meisten als einzelne Bits in verschiedenen Strukuren hat, muss man die ja irgendwann auf ein Wort kopieren, dass man dann im HMI angeben kann. Danach muss man im HMI die textlisten führen die auf die entsprechenden Triggerbits verweisen.

bei Programmalarm mach ich es mir einfach, der Alarm löst n programmalarm aus, als Text liegt entweder n anwenderdefinierter Text vor, oder ich stell den Text aus Instanzname, Fehlertext etc automatisch zusammen. Das alarmhandling ist also schon fertig wenn man den Baustein ins Programm zieht.

mfG René

Es geht auch ohne umkopieren, aber dann muß man mehr Aufwand für das Anlegen des HMI-Meldefeldes betreiben. Das macht man ohnehin nur einmal.
Ich habe für diese Meldungen Einzelbits in einem DB in der SPS inkl. SPS-Quitt und OP-Quitt. Das HMI greift darauf wortweise, aber darin wiederum auf die Einzelbis zu. Ist tatsächlich nur eine Frage der Definition der Variablen. Der DB allerdings ist in der SPS "nicht optimiert", ich weiß gar nicht, ob der auch optimiert sein kann, bei mir definitiv nicht, da ich im HMI ja wortweise auf je 16 Einzelbit zugreife, das geht dann nur absolut. Performanceprobleme habe ich bei den von mit genutzten 1500-er Steuerungen aber nicht feststellen können, aber alles unter 10ms reicht für unseren Sondermaschinenbau i.d.R. dicke aus.
Wir haben auch ein Kunden-Femework mit Alarmelde-Verfahren, das finde ich auch nicht so schlecht, aber die Frage, "Quittieren von SPS", "Quittiert von HMI" ist ein wenig kompliziert und ich glaube auch insgesamt frißt das Alarmelde-Verfahren viel mehr Performance als das Bitmeldeverfahren.

Ja, man kann viele Informationen beim Alarmmelde-Verfahren mit anhängen, aber wie ist denn die Realität? Immer, wirklich immer, wenn ich angerufen werde, weil eine Anlage einen Fehler hat, kann mir der Kunde nicht einmal die Nummer und den Text der Meldung korrekt durchgeben. Und ehrlich, viele der angehängten Infos sind schön, machen was her, sind aber sondt eher nutzlos. Die wichtigen, kann man aich im Bitmeldeverfahren mit anhängen.

Für mich insgesamt kein Grund, auf Teufel komm raus das Alarmmelde-Verfahren einzusetzen, das mich dann auf Siemens-Panels beschränkt. Aber auch ehrlich gesagt, wir setzen im Moment fast nur Siemens-Panels ein. Hat man viele Panels, dann ist das Alarmmeldeverfahren aber sicher schon wegen der Texte an einer Stelle ein echter Vorteil.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin Ralle,

Für mich insgesamt kein Grund, auf Teufel komm raus das Alarmmelde-Verfahren einzusetzen, das mich dann auf Siemens-Panels beschränkt. Aber auch ehrlich gesagt, wir setzen im Moment fast nur Siemens-Panels ein. Hat man viele Panels, dann ist das Alarmmeldeverfahren aber sicher schon wegen der Texte an einer Stelle ein echter Vorteil.

das erzeugen von Alarmen bzw. deren Auswertung etc. ist nicht unbedingt eine SIEMENS-Sonderlocke. Alarme können auch über OPC UA übermittelt werden. Und das ist bei SIEMENS für die 1500er und deren OPC UA-Server erst in Planung, aber noch nicht umgesetzt.

VG

MFreiberger
 
Nicht notwendigerweise. Wir nutzen auch ProgramAlarm, und für unsere Visu lesen wir diese wieder auf der SPS aus und versenden die Alarme per TCP/IP
Hallo, kann mir jemand sagen, wie man das macht? Ich habe auch ein fremdes SCADA System und muss Alarmmeldungen versenden. Wir hätten auch die Möglichkeit über OPC UA zu kommunizieren.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin Tmbiz,

Du kannst die Meldungen per Get_Alarm (Erweiterte Anweisungen > Meldungen) auslesen.

VG
MFreiberger

Ja, das stimmt. Das habe ich auch schon mal gesehen. Kann man mit der Funktion alle Meldungen aus einem Speicher übertragen oder nur eine spezielle Meldung?

Könnte ich damit meine gesamten Meldungen an den OPC übergeben und in welchem Format kommen sie dann an?
 
Moin Tmbiz,

im Prinzip kannst Du mit GET_ALARM alle Alarme auslesen. Dazu gehören dann auch Systemmeldungen.

Die Alarme werden in der Steuerung gepuffert und GET_ALARM liest einfach bei jedem Trigger den nächsten Alarm aus, bis kein aktiver Alarm mehr nicht ausgelesen ist. Alles, was ausgelesen wird (bis hin zum Alarmtext) kann man in einem DB speichern und von da weiterverarbeiten.

Wir machen das so, dass wir einen Ringpuffer mit 500 Einträgen haben. Dazu erzeugen wir dann noch eine eindeutige ID (DINT von 0 bis 2.nnn.nnn.nnn). Das übergeordnete System bekommt dann noch den Index des zuletzt eingetragenen Alarmtextes. Damit kann es, auch bei Kommunikationsausfall, die letzten Alarme auslesen.

VG
MFreiberger
 
Moin Tmbiz,

im Prinzip kannst Du mit GET_ALARM alle Alarme auslesen. Dazu gehören dann auch Systemmeldungen.

Die Alarme werden in der Steuerung gepuffert und GET_ALARM liest einfach bei jedem Trigger den nächsten Alarm aus, bis kein aktiver Alarm mehr nicht ausgelesen ist. Alles, was ausgelesen wird (bis hin zum Alarmtext) kann man in einem DB speichern und von da weiterverarbeiten.

Wir machen das so, dass wir einen Ringpuffer mit 500 Einträgen haben. Dazu erzeugen wir dann noch eine eindeutige ID (DINT von 0 bis 2.nnn.nnn.nnn). Das übergeordnete System bekommt dann noch den Index des zuletzt eingetragenen Alarmtextes. Damit kann es, auch bei Kommunikationsausfall, die letzten Alarme auslesen.

VG
MFreiberger
Ah okay. Das klingt schon mal interessant. Danke für die Rückmeldung.

Folgende Frage haben ich noch:
- In welchem Format werden die Meldungen dann von Get_Alarm versendet?
- Welche Kommunikation (neben TCP/IT) gibt es noch? Wir werden den OPC Server auf der SPS verwenden?
- Die Sprachumschaltung muss dann auf der SPS laufen und die Texte in verschiedenen Sprachen hinterlegt werden?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ah okay. Das klingt schon mal interessant. Danke für die Rückmeldung.

Folgende Frage haben ich noch:
- In welchem Format werden die Meldungen dann von Get_Alarm versendet?
sie liegen als WString vor.

- Welche Kommunikation (neben TCP/IT) gibt es noch? Wir werden den OPC Server auf der SPS verwenden?
per OPC UA können Alarme versendet werden. Allerdings muss man auf dem Client die Meldetext wieder zusammenbasteln, wenn die aus Begleitwerten erstellt wurden.

- Die Sprachumschaltung muss dann auf der SPS laufen und die Texte in verschiedenen Sprachen hinterlegt werden?
ich denke ja. Allerdings bin ich beim Thema Sprachumschaltung nicht sattelfest, da ich es nicht benötige. Auf jeden Fall liest der GET_ALARM die Meldung in der aktuell eingestellten Sprache aus. Diese können dann natürlich nicht mehr angepasst werden.
 
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.
Das Limit betrifft doch hoffentlich nur die gleichzeitige Meldung!?
Die sollte durch einen herkömmlich Meldeschwall hoffentlich nie erreicht werden.

Gibt es beim Program_Alarm auch eine herkömmliche Begrenzung der Anzahl der Meldungen?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wir machen das so, dass wir einen Ringpuffer mit 500 Einträgen haben. Dazu erzeugen wir dann noch eine eindeutige ID (DINT von 0 bis 2.nnn.nnn.nnn). Das übergeordnete System bekommt dann noch den Index des zuletzt eingetragenen Alarmtextes. Damit kann es, auch bei Kommunikationsausfall, die letzten Alarme auslesen.
Kannst du mir noch mal sagen, warum das das mit dem Ringspeicher machst? Kann "GET_Alarm" denn nicht einfach alles auslesen und dann über OPC übertragen?
 
Also wir machen das mittlerweile nicht mehr, da AGLink das auslesen nun unterstützt, aber wir hatten keinen Puffer auf der SPS eingebaut. Ich glaube (weiß es nicht mehr genau, und hab gerade keine TIA), mit dem GetAlarm Baustein meldest du dich am Meldesystem an, und wirst dann über alle noch anliegenden Alarme und kommenden Ereignisse benachrichtigt. D.h. wenn wir die Verbindung zur PLC verloren hatten, haben wir bei uns alle alarme als gegangen markiert und uns dann wieder am Meldesystem angemeldet. Ich glaube wenn man die Meldungen nicht chnell genug abruft, so das es zu einem überlauf kommen könnte, dann gibt der Baustein einen fehler aus, mit dem wir glaube ich die TCP Verbindung resettet haben.
 
Kannst du mir noch mal sagen, warum das das mit dem Ringspeicher machst? Kann "GET_Alarm" denn nicht einfach alles auslesen und dann über OPC übertragen?
Das übergeordnete System ist bei uns nicht echtzeitfähig. Zudem kann die Kommunikation manchmal etwas dauern und dadurch Meldungen verloren gehen.
Deswegen werden bei uns die Meldungen in der Steuerung gepuffert.

EDIT: Aber das gilt natürlich nur bei Systemen, die keine Alarme verarbeiten können.
 
Das übergeordnete System ist bei uns nicht echtzeitfähig. Zudem kann die Kommunikation manchmal etwas dauern und dadurch Meldungen verloren gehen.
Deswegen werden bei uns die Meldungen in der Steuerung gepuffert.
Das Meldesystem der Steuerung puffert ja auch, ist ja nur ne frage wie ihr dem baustein sagt ihr habt die Meldung ausgelesen. Bei uns wurde das gesetzt wenn wir per TCP verschickt hatten. Wenn die Meldungen nicht schneller reinkommen das der interne Puffer der S7 überläuft dan braucht man das nicht
 
Das gute an der TCP Variante bei uns war, das es auch für das gegangen einen PLC event gibt, uns daher die Uhrzeit (welche wir aus der PLC uhrzeit ins telegram eingertragen haben) stimmt. Wenn wir nun die AGLink schnistelle nutzen, gibt es zwar für das gekommen event einen zeitstempel der sps, für gegangen gibt es den aber nicht...
 
Zurück
Oben