TIA Meldungsverlängerung

[Rob87]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi,

ich habe immer wieder Anlagen in denen Meldungen bereits nach 1-3 Zyklus wieder aus sind(z.b. Druckpieks) -> Keine Anzeige im HMI(WinCC Classsic /Unified /Advanced-Panel).
Jetzt könnte ich für jede Meldung einen Timer bauen , da ist mir aber eig. zu Resourcenfressend.

Hab Ihr da eine elegantere Lösung?

danke.

 

[SPS-Bitschubser]

Bei uns werden alle Meldungen in der SPS mit einen RS-Glied gespeichert.

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bei uns werden alle Meldungen in der SPS mit einen RS-Glied gespeichert.

 

[winnman]

Normalerweise strukturiert man seine Meldungen, zB,

Alarm- / Störmeldungen -> müssen Quittiert werden -> bleiben also solange anstehend bis irgendjemand die Quittiert
Betriebsmeldungen -> serden mit kommend / gehend angezeigt -> hier verwschwindet auch nichts, lässt sich im Archiv filtern, betrachten, . . .

Meldekonzepte gibt es sehr viele verschiedene, man kann die auch entsprechend strukturieren, filtern, . . .

Vermutlich musst du dir mal Gedanken über das Meldkonzept machen und ev. auf verschiedenen Seiten das jeweils interessante anzeigen lassen.
Wenn ud das richtig eingerichtet hast, "verschwindet" da nichts, es wir dann halt als gekommen / gegangen angezeigt, . . .

 

[Onkel Dagobert]

Bei uns werden alle Meldungen in der SPS mit einen RS-Glied gespeichert.

Diese verwendet man im Programm für Verriegelungen. Wenn man diese gespeicherten Meldungen am HMI verwendet, kann man nur "Kommend" und "Gehend" anzeigen. Das wäre die einfache Version, bei der man das beschriebene Problem logischerweise nicht hat.

... Vermutlich musst du dir mal Gedanken über das Meldkonzept machen ...

Rob87 ist schon drei, vier Schritte weiter.

... Wenn ud das richtig eingerichtet hast, "verschwindet" da nichts, es wir dann halt als gekommen / gegangen angezeigt, . . .

Meinst du, das geht irgendwie? Wie umgehst du das in #1 beschriebene Phänomen?

@Rob87
Was hast du für eine Zykluszeit? Und wie sind die Meldeereignisse, die du am HMI anzeigst, in der SPS abgelegt, in einem STRUCT mit Symbolik für jedes Meldebit oder in einem ARRAY of .. ?

 

[DerOnkel]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi,

ich habe immer wieder Anlagen in denen Meldungen bereits nach 1-3 Zyklus wieder aus sind(z.b. Druckpieks) -> Keine Anzeige im HMI(WinCC Classsic /Unified /Advanced-Panel).
Jetzt könnte ich für jede Meldung einen Timer bauen , da ist mir aber eig. zu Resourcenfressend.

Hab Ihr da eine elegantere Lösung?

danke.

Um welche Meldungen handelt es sich bei Dir? Störmeldungen?Hinweis?Empfehlung?
Wie wirkt sich das auf dein Programm aus?

Ein kurzer Anstieg im Druck, wenn er relevant ist, bei 1-3 Zykluszeiten erscheint mir nicht verlässlich, der könnte auch verloren gehen.

 

[Ludewig]

Ich nutze hierfür eine kleinen FB, der einen TOF enthält. Ausgang ist der TOF bei kurzen Ereignissen OR der Eingang bei längeren. Der FB heißt "Mindestimpulsdauer". Die Zeit passe ich an die jeweilige Pollrate an. (t +1s)

Du siehst dann halt im HMI immer ein kommendes und ein gehendes Ereignis, dessen Abstand >= der parametrierten Mindestdauer ist.

 

[PN/DP]

Bei uns werden alle Meldungen in der SPS mit einen RS-Glied gespeichert.

Und wie/wann werden die wieder zurückgesetzt? Jemand muss irgendwie quittieren, dass er die Meldung gesehen hat. Und solange noch nicht quittiert wurde, kann/darf genau genommen die Ursache der Meldung nicht weggehen und wiederkommen, weil das wird dann nicht in der Meldung sichtbar.

ich habe immer wieder Anlagen in denen Meldungen bereits nach 1-3 Zyklus wieder aus sind(z.b. Druckpieks) -> Keine Anzeige im HMI(WinCC Classsic /Unified /Advanced-Panel).

Das Problem hat man generell, wenn man Zustände oder Meldungen am HMI anzeigen will, die kürzer anstehen als die Aktualisierungszeit der Variable - diese kurzen Zustände werden nur angezeigt, wenn das HMI die PLC-Variable zufällig gerade dann liest.

Welchen Zweck oder Sinn hat es, Meldungen für so kurze Ereignisse zu erzeugen und dafür sorgen zu müssen, dass die auch garantiert angezeigt/registriert werden?
Soll ein lückenloses Ereignisprotokoll über bestimmte Vorgänge erzeugt werden? Dann entweder die Ereignisse (Kommen, Gehen, ...) aktiv zum HMI senden (z.B. mit Meldeverfahren "Programmalarm") oder ein Meldeprotokoll/Meldepuffer in der PLC führen und bei Bedarf aus der PLC auslesen.

Jetzt könnte ich für jede Meldung einen Timer bauen , da ist mir aber eig. zu Resourcenfressend.

Wenn man einfach nur die Meldung bzw. die Meldedauer verlängern will, dann muss man jede möglicherweise zu kurze Meldung individuell mit einem eigenen Zeitglied verlängern. Das kostet halt soviel Ressourcen wie nötig. Wenn es wirklich sehr viele Meldungen betrifft, dann macht es Sinn, dafür nicht die vorhandenen/limitierten S7-Timer zu verwenden, sondern beliebig oft instanziierbare Zeitglieder zu verwenden oder evtl. selbst zu programmieren (z.B. als FB).

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

PS: Wenn man verlängerte Meldungen zu kurzen Ereignissen erzeugt, dann bekommt man das Problem, dass erneute Ereignisse während der verlängerten Meldung nicht gemeldet werden. Das muss man bei Bedarf noch extra behandeln.

 

[PN/DP]

Ich nutze hierfür eine kleinen FB, der einen TOF enthält. Ausgang ist der TOF bei kurzen Ereignissen OR der Eingang bei längeren.

Das "OR der Eingang bei längeren" ist bei einem TOF unnötig. Der Ausgangs eines TOF ist mindestens so lange aktiv wie der Eingang + die TOF-Zeit.
Oder man will längere Signale nicht zusätzlich verlängern als die Mindestdauer, dann muss der Eingang des Mindestdauer-TOF mit einer Flanke getriggert werden (so dass er einen einmaligen verlängerten Puls erzeugt).

 

[Onkel Dagobert]

... Welchen Zweck oder Sinn hat es, Meldungen für so kurze Ereignisse zu erzeugen und dafür sorgen zu müssen, dass die auch garantiert angezeigt/registriert werden? ...

Man darf natürlich nicht vergessen, dass es sich um Störmeldungen handelt. Das Ereignisprotokoll ist dabei nur sekundär. Wenn jetzt eine Überdruckmeldung auch nur für einen einzigen Zyklus ansteht, dann wird man eine Störmeldung speichern und entsprechende Reaktionen auslösen. Keinesfalls wird man eine solche Reaktion verzögern wollen. Das HMI bekommt hingegen nur das Meldeereignis gemeldet, um alle Meldezustände anzeigen zu können. Wenn das HMI dieses Meldeereignis in dieser sehr kurzen Zeit nicht registriert hat, dann wird es nicht angezeigt und kann folglich auch nicht über das HMI quittiert werden.

Dieses Thema wurde hier übrigens schon mehrfach diskutiert.

 

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

PS: Wenn man verlängerte Meldungen zu kurzen Ereignissen erzeugt, dann bekommt man das Problem, dass erneute Ereignisse während der verlängerten Meldung nicht gemeldet werden. Das muss man bei Bedarf noch extra behandeln.

Man kann ja einen Zähler einbauen .
Eine Reaktion bis zur Störungsbehebung und Quittierung reicht dir nicht?

 

[PN/DP]

Man darf natürlich nicht vergessen, dass es sich um Störmeldungen handelt.

Mir scheint, dass es sich beim Fragesteller nicht um Störmeldungen handelt, die einfach mit S/R gespeichert werden können. Sondern er will Meldungen zu kurzen Ereignissen mindestens so lange verlängern, dass sie am HMI auch angezeigt werden. Die sollen aber vermutlich von alleine wieder gehen, ohne quittiert werden zu müssen.

 

[PN/DP]

Eine Reaktion bis zur Störungsbehebung und Quittierung reicht dir nicht?

Es geht nicht darum, was mir evtl. reicht, sondern was der Fragesteller erreichen will.

 

[rostiger Nagel]

Zuviel Werbung?
-> Hier kostenlos registrieren

Man darf natürlich nicht vergessen, dass es sich um Störmeldungen handelt.

Das hat er nach geschrieben, ist es eine Störmeldung, dann hat
Sie meiner Meinung nach Speichernd zu sein und muss Quittiert werden.
Ist es nur eine Betriebsmeldung oder Warnmeldung, muss er Sie
entsprechend dem Erfordernissen des Prozesses behandeln.

 

[Onkel Dagobert]

Es geht nicht darum, was mir evtl. reicht, sondern was der Fragesteller erreichen will.

natürlich

Das hat er nach geschrieben, ist es eine Störmeldung, dann hat
Sie meiner Meinung nach Speichernd zu sein und muss Quittiert werden.

natürlich


Übt euch doch mal im verstehendem Lesen.

 

[Ludewig]

Zu Haralds Bemerkung: Natürlich habe ich da eine kleine Flanke drin.

Wir setzen meist aus Kostengründen Basic-Panels (keine Programmalarme) mit einem USB-Stick ein. Um da z. B. bestimmte Umschaltereignisse wie Hand / Auto / Fern auf den Stick zu bekommen, nehmen wir in Kauf, dass diese Meldung dann einmal kommen und 2 Sekunden später gehend angezeigt wird. Der Kunde kann so später bei Bedarf am HMI rekonstruieren, wann die Umschaltung erfolgte.

 

[Rob87]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi, Eure Kommentare haben mich auf ein Idee gebracht Simple aber SUPER!
-> 1. Meine Störungen sind in einem UDT mit 16bits und einem 2 WORD(Melde und Quittier WORD) strukturiert.
-> 2. "Foreach-Schleife" sortiert von Bit nach WORD und nimmt bei Quittierung ein weiteres bitt weg.
-> 3. [Jetzt kommt der Trick ] das ganz wird so umgebaut das OB1 die Meldungen IM WORD nur noch setzt und ein Weckalarm OB [Zeit = 2x Abtastzeit HMI] setzt die Meldungen IM WORD zurück und setz sie gleich danach wieder wenn die Bits noch aktiv sind.
-> Zusätzlich wir der Erfassungszyklus im HMI auf 500ms gesetzt und da die Meldungen nur mit ganzen Sekunden angezeigt werden fällt das noch nicht mal auf.
Ich hoffe das war jetzt verständlich... DANKE.

 

[PN/DP]

Außer dir muss das ja niemand verstehen

PS: woher weiß der Weckalarm, ob und welche Bits schon länger gesetzt sind?

 

[Rob87]

Hi,

Also der Ablauf ist folgender:
[UDT]:
X0 BOOL
...
X15 BOOL
MW -Word //Meldeword
[ENDE]


1. Ereignis setzt BIT X0
2. [FC1:Forschleife]im OB1 über alle UDT's: IF X0 THEN MW.%X0 := TRUE END_IF; // ANALOG für X1 bis X15
3. Ereignis geht -> X0 = FALSE
4. HMI LIEST [UDT]MW alle 500ms
5. [FC2: Ruecksetz-Forschleife] im OB31(1020ms //<-2x HMI Zyklus +1x OB1 Zyklusdurchschnitt ): IF NOT X0 THEN MW.%X0 := FALSE END_IF; // ANALOG für X1 bis X15

Fertig