Skip to Content

SiePortal

Die integrierte Plattform für Produktauswahl, Einkauf und Support - und Verbindung von Industry Mall und Online Support

SiePortalEnglish

Suche

Home
Support Support
{{(apiData.Support | filter:{'rank':1}:true)[0].title}} Support
- Menü derzeit nicht verfügbar
- Menü derzeit nicht verfügbar
- Menü derzeit nicht verfügbar
- {{item.title}}

Produkte & Services
- Menü derzeit nicht verfügbar
- Menü derzeit nicht verfügbar
- {{item.title}}
Support Support
{{(apiData.Support | filter:{'rank':1}:true)[0].title}} Support
- Menü derzeit nicht verfügbar
- Menü derzeit nicht verfügbar
- {{item.title}}
MySiePortal MySiePortal
{{(apiData.MySiePortal | filter:{'rank':1}:true)[0].title}} MySiePortal
- Menü derzeit nicht verfügbar
- Menü derzeit nicht verfügbar
- {{item.title}}
Warenkorb ({{apiData.CartCount}})

Navigation

AlarmS quittiert sich selber

Erstellt von: Luciferius am: 25.06.2012 13:43 (7 Antworten)

Bewertung (0)

Dank 0

8 Einträge

25.06.2012 13:43	Bewerten (0)
Luciferius Beiträge: 14 Bewertung: (0)	Guten Tag, Ich habe in meinem Programm AlarmSQ/S/DQ und D verwendet. Nun habe ich so gut wie alle vier Alarmtypen auf fast die gleicher Weise programmiert. Folgendes passiert: Wenn ich AlarmSQ aufrufe wird die Meldung angezeigt und ich kann sie entweder auf der Oberfläche quittieren oder durch die Funktion AcknowledgeMessage() in einem C-Skirpt. Gleiches passiert bei AlarmDQ. Hingegen wenn ich AlarmS/D auslöse, kommt die Meldung und wird sofort quttiert. Ich sehe die Meldung noch nicht einmal auf der HMI. Auch wenn ich die Meldung nochmal als gegangen dannach sende wird nichts angezeigt. Die Funktion AcknowledgeMessage() wird dabei nie ausgeführt und selbst wenn, dafür wird es zu schnell quittiert. Außerdem erhält es nicht den Zustand, vom System wuittert, als alsob der Benutzer selber die Meldung so schnell quittiert. Ich bin ehrlich gesagt mit meinem Latein am Ende und hab keine Ahnung, was ich noch probieren könnte, außer ein Minimalbeispiel zu schreiben, was mir aber zu lange dauert und ich mir nicht viel von verspreche. Ich hoffe mir kann jemand helfen. Viele Dank schon mal im Voraus und viele Grüße.
Luciferius Beiträge: 14 Bewertung: (0)
Vorschlag Bedanken Zitat Antwort

26.06.2012 12:29	Bewerten (0)
Bizur Beiträge: 1530 Bewertung: (59)	Hallo Luciferius, das klingt ja mysteriös. Deine Idee mit dem Minimalbeispiel finde ich sehr gut, auch wenn es für Dich Aufwand bedeutet. Das Problem als solches ist mir (zumGlück)nicht bekannt. Da hätte es ja bestimmt schon große Aufregungen gegeben, wenn WinCC selbständig die Alarme quittieren würde. Kann es sein, daß die Quittierung irgendwie automatisch gestartet wird, in dem Moment, in dem ein bestimmter Alarm eintritt? Mit welcher WinCC Version arbeitest Du denn? Bitte laß' es die Forum-Gemeinde wissen, was bei Deinem Test herauskommt. Viele Grüße Bizur
Bizur Beiträge: 1530 Bewertung: (59)
Vorschlag Bedanken Zitat Antwort

26.06.2012 15:27	Bewerten (0)
Luciferius Beiträge: 14 Bewertung: (0)	Dann muss es wohl an meinem WinCC liegen. Ich benutze die Version 7.0. Ich habe ein Minimalbeispiel gemacht und, wie ich nciht erwartete hatte, den gleichen Effekt bekommen. Die Meldung wird automatisch quittiert und ich sehe sie nicht einmal aufblizen. Wie ich bereits gesagt habe wird die AcknowledgeMessage() Funktion nicht ausgeführt. Wäre das geschehen, hätte ich eine Ausgabe im Debugfenster gehabt. Viele Grüße.
Luciferius Beiträge: 14 Bewertung: (0)
Vorschlag Bedanken Zitat Antwort

27.06.2012 11:17	Bewerten (0)
Bizur Beiträge: 1530 Bewertung: (59)	Hallo Luciferius, ich habe jetzt mal in der Dokumentation zum ALARM_S nachgeschaut. Dort steht Folgendes: Meldungen, die Sie mit der SFC 18 "ALARM_S" gesendet haben, sind immer implizit quittiert. In Deinem WinCC-Archiv müsstest Du den Alarm schon sehen, aber eben immer gleich quittiert. Du kannst natürlich auch mit den Selektionen im Alarm Control versuchen die Einstellungen entsprechend zu trefffen, so dass Du alles wie gewünscht angezeigt bekommst. Die einfachere Variante wäre jedoch für die Alarme, die Du unquittiert sehen willst, auch den entsprechenden Baustein zu verwenden. Viele Grüße Bizur
Bizur Beiträge: 1530 Bewertung: (59)	Zuletzt bearbeitet von: Bizur am: 27.06.2012 11:48
Vorschlag Bedanken Zitat Antwort

27.06.2012 11:33	Bewerten (0)
Luciferius Beiträge: 14 Bewertung: (0)	Das macht für mich keinen Sinn. Ich verstehe unter implizit quittiert, dass wenn ich den Meldezustand mit dem SFC 19 abrufe immer den Zustand quittiert bekomme, aber trotzdem in der Runtime die Meldung quittieren muss, damit sie nicht ehr angezeigt wird. Was macht es denn für einen Sinn eine Meldung zu generieren, die der Bediener nur dann sieht, wenn er zufällig mal in die Chronikliste der Meldungen guckt. Im übrigen, in der Chronikliste stehen die Meldungen, sie scheinen also wirklich zu kommen.
Luciferius Beiträge: 14 Bewertung: (0)
Vorschlag Bedanken Zitat Antwort

27.06.2012 13:22	Bewerten (0)
Bizur Beiträge: 1530 Bewertung: (59)	Hallo Luciferius, Du/Dein Kunde muss für das Projekt die Entscheidung treffen, welche Alarme wo und wann quittiert werden müssen und welche nicht. Je nachdem wählst Du einen bestimmten Baustein für das Steuerungsprogramm aus und legst das Vorgehen in WinCC fest. Es gibt ja auch Alarme, die der WinCC Bediener gar nicht mitbekommen muss, die nur intern im Steuerungsprogramm entstehen und gehandelt werden. Da kann man dann zum Beispiel entscheiden, ob die Bearbeitung eines Bausteins weitergeführt oder abgebrochen werden soll. Viele Grüße Bizur
Bizur Beiträge: 1530 Bewertung: (59)	Zuletzt bearbeitet von: Bizur am: 27.06.2012 13:26 Zuletzt bearbeitet von: Bizur am: 27.06.2012 13:23
Vorschlag Bedanken Zitat Antwort

27.06.2012 14:27	Bewerten (0)
Luciferius Beiträge: 14 Bewertung: (0)	Vielen Dank für die Information. Ein Frage habe ich aber noch. Was genau kann ich unter "implizit quittiert" verstehen. Ich kann mit dem Ausdruck nicht viel anfangen. Ich habe es eben so verstanden, dass das System die Meldung automatisch quittiert. Dann müsste der Meldezustand aber 13 (Quittiert durch System) und nicht 3 (Quittiert) sein. Eine andere Möglichkeit wäre, dass bei Aufruf des Bausteins zwei Meldungen gesendet werden (einmal mit Zustand 1 und einmal mit Zustand 3). Der Alarmtyp ist ja bei AlarmS und bei AlarmSQ jeweils alarm_s, somit hat WinCC eigentlich gar keine Möglichkeit die beiden Arten zu unterscheiden. Grüße, Luciferius
Luciferius Beiträge: 14 Bewertung: (0)	Zuletzt bearbeitet von: Luciferius am: 27.06.2012 14:27
Vorschlag Bedanken Zitat Antwort

28.06.2012 11:37	Bewerten (0)
Bizur Beiträge: 1530 Bewertung: (59)	Hallo Luciferius, Impliziert quittiert heißt, dass das Quittierbit vom System mit gesetzt wird. Meldezustand 13 bezieht sich auf WinCC, oder? Vielleicht hilft Dir das weiter: Welche Zustände kann eine Meldung zur Runtime durchlaufen? Du hast recht mit Deiner Ausssage, daß WinCC nicht zwischen ALARM_S und ALARM_SQ unterscheiden kann. Das muss es aber auch nicht. Beim ALARM_SQ-Baustein hast Du die Möglichkeitden Alarm zuquittieren. Dies kann auch über WinCC geschehen. Bei ALARM_S gibt es diese Möglichkeit nicht. Viele Grüße Bizur
Bizur Beiträge: 1530 Bewertung: (59)
Vorschlag Bedanken Zitat Antwort

|

Teile diese Seite:

Teile diese Seite auf...

Folgen Sie uns auf