ALARM_S. Kann es ein „Quittiert“ Rückmeldung zum SPS geben?

Beiträge
8.300
Reaktionspunkte
1.888
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo.

Gibt es jemand mit Erfahrung mit ALARM_S ?

Ich benutze Bit-triggered Alarmmeldungen mit WinCC Flexible im Augenblick.
Aber ich bin empfohlen worden, um auf ALARM_S zu schauen, da dieses eine Anzahl von Vorteilen geben sollte.

Ich denke, daß ich eine ernste Beschränkung gefunden habe.
Alle Kommunikation geht vom S7 SPS zum HMI. Nicht die andere Richtung. Es gibt keine Informationen vom HMI zu S7 SPS, daß eine Alarmmeldung bestätigt worden ist.
Folglich z.B. kann ich nicht einen Start einer Maschine blockieren, bevor alle Alarmmeldungen bestätigt worden sind. Ich habe diese gewünschte Funktionalität mit der anderen Methode.

Habe ich etwas mißverstanden oder etwas vermißt?

Danke im voraus.
 
Für Alarme welche quittiert werden müssen nimmst du "Alarm_SQ" (SFC 17)
Den Quittierzustand frägst du mit "Alarm_SC" (SFC 19) einzeln (EV_ID - bezogen) ab...

Mache ich allerdings nicht so.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Mit dem Alarm_SC kannst du zwar den Alarm_S als auch den Alarm_SQ abfragen - nur liefert der Alarm_S automatisch "quittiert" zurück - also SQ verwenden...

Warum ich das nicht so mache ?
-> weil es total umständlich ist... (Mach das mal für 500 Meldungen einzeln!)

Du erzeugst z.B. einen Global-DB in dem alle deine meldungsauslösenden Bits eingebettet sind -> Wenn keine einzige Störung ansteht sind alle Bits "False" (kannst du wort oder Doppelwortweise abfragen).

Wenn es eine Störung gibt dann erzeugt ja sowieso deine SPS die Störung - also weiss sie auch daß es eine gibt -> du gehst dann in einen "Sicheren Zusatnd" oder behandelst das dem Ereignis entsprechend...

Die Quittierung am Panel ist in erster linie wichtig um zu erzwingen daß der Bediener sie liest bevor er ACK drückt (das Meldefenster im Vordergrund vorausgesetzt...).

Nun nimmst du eine extra Taste am Panel um einen Reset zu erzeugen.

Wenn alle Bedingungen für den Reset erfüllt sind machst du ihn wenn nicht bleibt das ganze blockiert bis die Bed. erfüllt sind.

Bei erfolgreichem Reset überschreibst du dann den DB mit den meldungsauslösenden Bits komplett mit "0" -> Ergebnis: Grundzustand hergestellt...

Somit bist du nicht gezwungen jede einzeln abzufragen sondern siehst anhand des Vergleichs ob irgendeine Störung ansteht - das reicht, zu dem kannst du ja noch Prioritätsgruppen bilden.

Das Meldenummernverfahren (so heißt das) hat für mich den Vorteil daß alles in der SPS passiert - einschließlich der Meldetexte (sogar Übersetzung möglich).

Am HMI brauchst du lediglich noch den Haken für die jeweilige Verbindung setzen und der Rest geht "von selbst"

Sicher ist das ganze auch da eben der Bediener neben der ACK für jede Meldung auch den Reset bestätigen muss - also kann automatisch nichts unbeabsichtigt wieder anlaufen...
 
Im Augenblick versuche ich nur, heraus darzustellen, was möglich ist und was nicht ist.
rs-plc-aa schrieb:
Warum ich das nicht so mache ?
-> weil es total umständlich ist... (Mach das mal für 500 Meldungen einzeln!)
Ich hoffe, die langwierigste Arbeit zu vermeiden, indem ich die Alarmfunktionen in eine Bibliothek von Standard FBs programmiere.

Wie du beschreibst, ist es auch, wie mein anwesendes System funktioniert.
Ich stellte die gleiche Frage über bei Siemens' Forum. (Keine Antworten dort bis jetzt).
Dieses ist, wie ich beschrieb, wie mein anwesendes System mit den bit-triggered Alarm-meldungen arbeitet:
--------------------------------
In the PLC, for each alarm instance:
When an alarm condition is on it sets an alarm-bit (ALARM_RAW).
The alarm-bit sets a memory of the alarm (ALARM_MEM).
The PLC monitors the ALARM_ACK (see below) and stores it in ACK_MEM.
When ALARM_RAW is off, and ACK_MEM is on, then ALARM_MEM and ACK_MEM are reset.

In the HMI there are these standard functions for bit-triggered alarms:
ALARM_MEM is monitored to display the alarm messages.
A bit is reset when the the alarm is triggered, and when the alarm is acknowledged by the user the bit is set again (ALARM_ACK).

The important point is this:
ALARM_MEM is used for various interlocks, for example it will not be possible to start a machine before all critical alarms have been reset. It is not enough that the alarm conditions are off. The operator must have examined and acknowledged the alarms if there are any.
--------------------------------
 
Nun sei doch froh dass du nicht allzu viel umbauen musst.

Der wesentliche Unterschied ist der daß du einen FB erzeugst der für jeden Alarm einen Alarm_SQ aufruf enthält.

Das Triggerbit weist du aus deinem DB mit den Meldungsauslösenden Bits zu.

Beispiel für ein Netzwerk:
Code:
      L     0                           // falls ein DWORD ausreicht die restlichen 2 mit "0" auffüllen
      T     #begleitwert1
      T     #begleitwert2
      T     #begleitwert3
// Störung 1
      CALL  SFC   17
       SIG    :=DB320.DBX0.0            // Meldungsauslösendes Bit
       ID     :=W#16#EEEE               // Bleibt konstant gleich
       EV_ID  :=#Stoerung001            // Variable aus IN-Bereich welcher die Meldungsnummer zugeordnet ist
       SD     :=P#DB290.DBX192.0 BYTE 12    // Adresse des (der) Begleitwert(e) absolut ! siehe ***
       RET_VAL:=#retval
// *** = Begleitwert hat das "Any-Format", und muß absolut adressiert sein. die hier verwendete Adresse ergibt sich aus
// *** = der Anfangsadresse des STAT-Bereichs. Byte 12 bedeutet Länge 12 Byte ab der Startadresse.

Die Begleitwerte sind ebenfalls eine Eigenschaft die du nur mit diesem Verfahren hast.

Du gibst bei Bedarf einen Wert (bis zu 3) mit und Projektierst die Anzeige in der Meldetextmaske, es gibt dann Codierungen wie du das für die jeweiligen Datentypen definieren musst. (Hierzu gibt es Anleitungen von Siemens)

Du machst so viele Netzwerke wie du Störungen projektiert hast.
Ebenfalls musst du dem FB Attribute zuweisen daß dieser "Alarmfähig" wird.

Als IN-Parameter definierst du die Störungen (Alarmspeicherbereich).

Part_1.png

Part_2.png

Die EV_IDs werden wiederum CPU-weit (oder Projektweit=alte Methode) beim Aufruf des FBs an dessen Schnittstelle automatisch zugewiesen.

Es ist halt nur knifflig bis du es ein mal kapiert hast (die Zusammenhänge)...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Bin wieder da mit einer Frage/Ärger zum Thema.

In der on-line-Hilfe gibt es Beispiele auf, wie man wiederverwendbaren code mit ALARM-S kreiert.
Die ALARM-S Blöcke werden in deinem eigenen FBs eingebettet, und Instanz DBs werden diesen zugewiesen, wodurch einzelne Meldungen für jeden FB Aufruf definiert werden. Mit anderen Worten: Genau, was ich benötige.

Aber aber. Die on-line-Beispiele beschreiben nur, wie man dies mit den SFB's tun. nicht die SFC's. Und, die SFB's werden nicht auf das S7-300, nur das S7-400 gestützt.
So nah, und doch so weit.:sb7:

Frage: Ist etwas ähnliches mit dem SFCs möglich ?
 
Hallo,
schau doch noch mal meinen vorherigen Beitrag an...

Wie du dort siehst ist es die SFC17...

Diese kannst du sowohl für s7-300 als auch s7-400 verwenden.

Hier noch mal eine kleine Hilfestellung:

1.) Du legst einen neuen FB an (multiinstanzfähig sollte er sein)
2.) Die IN-Schnittstelle belegst du mit so vielen DWORD-Variablen wie du einzelne Störungen haben willst (es dürfen auch mehr sein -> Reserve) - Tip: die Anzahl sollte durch 8 oder besser 32 teilbar sein...
3.) Tip: leg erst nur eine an, denn alle müssen nachher die Attribute haben wie oben in den 2 Screenshots zu sehen, und kopiere dann diese -> dann musst du nur noch den Namen aber nicht mehr den Typ+die Attribute editieren.
4.) lege ebenfalls an der IN-Schnittstelle (hinter 3.) weitere (normale) DWORD Variablen an. Und zwar so viele wie du Alarme hast geteilt durch 32.
5.) danach setzt du noch optional Begleitwerte dahinter (Format passend zum Wert)
6.) Jetzt legst du im STAT-Bereich 3 DWORD Variablen an -> Begleitwert1,2 und 3 (mehr kannst du nicht mitschicken) [in der Hilfe steht zwar daß nur einer geht - habe aber schon 2 erfolgreich hinbekommen, also sollten 3 auch gehen]
7.) lies folgenden Thread durch -> am Ende kommt auch was interessantes: http://www.sps-forum.de/showthread.php?t=12714
Hier kriegst du die Lösung für die Begleitwerte...

Wenn du das alles hast meldest du dich am besten noch mal...

Vorweg: Du kannst quasi alles wiederverwendbar machen -> ausser die Meldetexte (es sei denn die sind auch immer gleich) - Diese gibst du am FB mit dem Kontextmenue <Spezielle Objekteigenschaften -> Meldung> ein.

Es müsste zwar auch das noch besser gehen in dem du "Anwendertextbibliotheken" verwendest, jedoch habe ich das bisher noch nicht getestet...
 
7.) lies folgenden Thread durch -> am Ende kommt auch was interessantes: http://www.sps-forum.de/showthread.php?t=12714
Hier kriegst du die Lösung für die Begleitwerte...
Ich benötige vermutlich nur 1 zusätzlichen Wert.

Wenn du das alles hast meldest du dich am besten noch mal...
OK. Aber I arbeite mit dieses zwisschen mehr dringender Jobs. Nicht überrascht sein, wenn ich nach einem Paar Jahren zurückkomme. ;)

Vorweg: Du kannst quasi alles wiederverwendbar machen -> ausser die Meldetexte (es sei denn die sind auch immer gleich) - Diese gibst du am FB mit dem Kontextmenue <Spezielle Objekteigenschaften -> Meldung> ein.
In den on-line-hilfe wird es erwähnt, daß mit dem eingebetteten SFBs, die Texte entsprechend einer „Schablone“ verursacht werden.

Dank für deine ganze Hilfe. :)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo, na ja wie du auch schon bemerkt hast ist dieses ganze Spektakel ziemlich unzureichend in der Hilfe beschrieben, daher kannst du dir wahrscheinlich ausmalen wie lange ich daran rumbebastelt habe...

Der "Durchbruch" aber gelang erst als ich die Begleitwerte indirekt zuweisen konnte -> dies ermöglichte die Hilfestellung vom Forum hier in Bezug auf den Pointer der auf den Eingang "SD" der SFC17 verweist.

Und am Parameter "SIG" weist du jetzt nicht mehr z.B. DB320.DBX0.0 (wie in meinem Beispiel) zu sondern nur DBX120.0 z.B. -> Interne Variable des FB´s.

Einbetten brauchst du die SFC übrigens nicht, da es sich ja um eine Standard-SFC handelt und immer sowohl Absolut als auch symbolisch angesprochen werden kann.

Aktuell sieht das so aus:
Code:
      L     #T_ABG_C_Zyl_17                  // Input
      T     #begleitwert1                       // STAT0
      L     0
      T     #begleitwert2                       // STAT4
      T     #begleitwert3                       // STAT8
// Störung 175
      CALL  SFC   17                            // muß nicht eingebettet sein
       SIG    :=DBX1045.6                     // BIT (Input)
       ID     :=W#16#EEEE                    // Konstant gleich
       EV_ID  :=#Stoerung175               // Input m. Attribut
       SD     :=#Begleitwerte                 // TEMP0 Typ Any
       RET_VAL:=#retval

Aber suche auch noch mal bei Siemens im Internet - hier findest du Infos wie du zumindest mal das Grundsätzliche ans laufen kriegst...

zb hier: http://support.automation.siemens.c...ction=cssearch&showoptions=false&firstload=no

Suchbegriff: alarm s flexible

Da kommt auch noch mehr...
 
Hallo,

ich verwende die SFCs 107/108. Die funktionieren wie die Alarm S Bausteine, aber belegte Instanzen in der CPU können wieder freigegeben werden.
Ich finde dieses Meldesystem ziemlich gut, da man die CPU-Zeit im Panel angezeigt bekommt, nicht die Pollzeit, bei der unterschiedliche Meldungen mit genau demselben Zeitstempel gemeldet werden können.

Nachteile sind meiner Meinung nach, dass man die Meldungen nicht über die SPS quittieren kann, und das beim Hilfetext keine Absätze gemacht werden können, obwohl das so beschrieben steht... Siemens halt.
Version FLEX2005 HF4

Schöne Grüße

Micha
 
Die SFCs 107/108 (Alarm_D/DQ) sind aber nicht für die S7-300 sondern nur für die 400er gedacht...

Sag bloß dass die auch mit der 300er funktionieren ?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ergänzung:

Wenn man die verwendete CPU online öffnet werden alle in Ihr enthaltenen SFBs und SFCs sichtbar.

Wenn dort keine SFC 107/108 drin ist kann man sie auch nicht verwenden...

Schaue ich morgen mal nach aber aus der Hüfte:
bei S7-300 so viel ich weiss nicht.
 
Hallo nochmal,

laut Siemens (S7-Hilfe - "Welche Meldebausteine gibt es") funktionieren die Bausteine auch mit S7-300er.
Hab ich aber noch nicht ausprobiert...

Gruß Micha
 
Hallo,

ich habe noch keine Zeit gehabt eine 300er CPU anzuschließen und mal reinzuschauen aber wenn im jeweiligen OS der CPU die SFCs nicht drin sind geht es auch nicht.

Es kann z.B. sein daß es mit einer 318er geht mit einer 315er aber nicht...

Wie gesagt wenn ich zeit hab schileß ich mal eine an.

Zu den Vor- und Nachteilen:

Die SFC 17/18 funktioniert genau gleich wie die 107/108 -> diese haben nur einen zusätzlichen Eingang der eine Gruppierung ermöglicht (für 400er CPUs da man dort wahrscheinlich davon ausgeht daß ein Vielfaches an Meldungen projektiert werden im Vergleich zu 300er Projekten)

Aber die Belegung der Systemresourcen ist die selbe -> wenn das meldungsauslösende Bit nicht toggelt wird auch nichts belegt.

Belegt wird in beiden Fällen ab steigender Flanke bis fallender Flanke und bei den "Q-Varianten" zusätzlich noch bis am HMI quittiert wurde - dann fliegen die wieder bis zur nächsten steigenden Flanke aus dem Speicher raus.

Wenn man die Bibliothek StdLibs mal öffnet und die jeweilige SFC markiert und dann F1 drückt ist jede beschrieben...

Mittlerweile habe ich mich auch ganz gut auf das Verfahren eingeschossen.

Wünschenswert wäre lediglich ein verbesserter Meldetexteditor in zukünftigen Step7 Versionen -> dieser ist ein bisschen "simpel" geraten...
 
Zurück
Oben