Verständnisfragen zu TC3 EventLogger & EventListener

[Jörn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin,

ich hätte - mal wieder - ein paar Verständnisfragen. Diesmal zum event handling.

Ich kann in der SPS mit FB_TcAlarm.CreateEx(Tc_Event.ClassName.Alarm, ...) einen Alarm erzeugen, welcher dann im EventGrid in der HMI auftaucht. Dort kann ich ihn dann z.B. Bestätigen oder Löschen. Bis zu diesem Punkt bin ich bereits erfolgreich dabei.

Was ich bisher nicht gefunden habe, ist, wie / ob ich mit FB_TcAlarm.CreateEx(...) und Raise() mehrere Alarm gleichzeitig bedienen kann. Aktuell sieht es für mich so aus, als könnte ich immer nur einen Alarm mit CreateEx() kreiere und diesen dann mit Raise() absetzen. Mir fehlt aktuell die Möglichkeit mehrerer Alarme gleichzeitig zu händeln, wenn z.B. eine Station der Gesamtanlage wegen eines Alarmes steht und es daraufhin zu Folgefehlern in einer zuführenden oder nachfolgenden Station kommt.

Interpretiere ich das Infosys richtig, daß ich auf der SPS-Seite die Methoden des FB_ListenerBase überschreiben muss, damit ich die Bestätigung / Löschung der Alarme aus der HMI heraus mitbekomme und entsprechend reagieren kann?

Fast vergessen: Kann ich den cache des EventLoggers eigentlich irgendwo / irgendwie löschen?

Gruß
Jörn

 

[Jörn]

WTF? Bis gerade eben war es noch so, daß ich ein HRESULT von 16#98110712 (ADSERR_DEVICE_INVALIDSTATE) zurück bekam, wenn ich zweimal den gleichen Alarm nacheinander mit Raise() erzeugt habe.

Jetzt wird der erste automatisch auf cleared gesetzt, sobald ich einen zweiten mit Raise() erzeuge?! Unabhängig davon, ob es zwei unterschiedliche Alarme sind oder zweimal der gleiche Alarm.

Gruß
Jörn

 

[roboticBeet]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wir haben einen eigenen Alarmhandler auf Basis des FB_TcAlarm geschrieben. Dieser steuert alle wesentlichen Eigenschaften und Zustände der Meldung, angefangen bei der Initialisierung mit CreateEx(), dem Aufrufen der jeweiligen Alarmzustände (Kommt, Geht, Quittiert) und fügt der Meldung ggf. ein Argument hinzu. Für jede Meldung gibt es dann eine eigene Instanz des Alarmhandlers. Die Alarmhandler-Bausteine nutzen wir in einem Array, weil dadurch noch ein paar zusätzliche Auswertungen vereinfacht werden.

 

[Jörn]

Moin roboticBeet,

ich hab heute mit dem Support von Beckhoff telefoniert und es läuft ziemlich genau auf Deine Lösung hinaus. Für jede Nachricht und jeden Alarm wird es einen FB geben, alle Nachrichten und alle Alarme jeweils in ein Array gepackt. Create(), Send(), Raise(), Confirm(), ... wÃürde ich über die nEventId machen, welche gleichzeitig der Index des Arrays ist. Ich überlege noch ein ENUM mit Klartexten für die EventIds anzulegen, damit man sie nicht auswendig lernen muss.

Das mit dem Listener hat sich gottlob - vorerst - erledigt, da das EventGrid wohl schon einen Listener mitbringt, der irgendwo / irgendwie mit den FBen verknüpft ist. Ich befürchte nur, ich muss mich dennoch in naher Zukunft damit beschäftigen, weil wir mehrere Clients haben werden. :-(

Wie funktioniert denn das Hinzufügen eines Argumentes? Das steht auch noch auf meinem Zettel.

Gruß
Jörn

 

[roboticBeet]

Zum Hinzufügen von Argumenten musst du im Text der jeweiligen Meldung einen Platzhalter einfügen. Der erste Platzhalter wird mit {0} eingefügt ein eventuell zweiter mit {1} usw. Die Zählung beginnt für jede Meldung wieder von vorne, d. h. wenn du maximal ein Argument in einer Meldung hast, brauchst du immer nur {0} einfügen.

Im SPS-Programm müssen die Argumente der Meldung nach der Initialisierung mit CreateEx() aber vor dem Raise() bzw. Send() eingefügt werden. Dies geht mit folgendem Code für ein Argument (hier als Word vorliegend):

fbAlarm.ipArguments.Clear().AddWord(argValue);

Hat deine Meldung zwei Argumente ({0} und {1}) würde das Beispiel lauten

fbAlarm.ipArguments.Clear().AddWord(argValue).AddString(argString);

wobei das Word für den Platzhalter {0} und der String für den Platzhalter {1} ist.

 

[Das Bit ist gekippt...]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich arbeite wie folgt mit Eventlogger:

Jede Station besitzt ein Meldearray aus einer Struktur, welche alle relevanten Daten für den Eventlogger enthält (Eventklasse, Severity, ID usw.).
Jeder Baustein greift via IN/OUT auf dieses Array zu und trägt seine Meldung einfach auf den nächsten freien Platz ein.

Dann gibt es einen Handlingsbaustein, der eben dieses Array abarbeitet und die Meldungen entsprechend absetzt.
Bei dem Baustein kann dann optional angewählt werden wie viele Meldungen angezeigt werden sollen. Oder ob nur die Höchste Meldung mit der höchsten Severity angezeigt werden soll usw...
Der Baustein gibt dann raus, ob ein kritischer fehler, ein Fehler oder nur eine Warnung aktiv ist.
Wie dann in der Station darauf reagiert wird ist ja eine andere Geschichte
Das quittieren erfolgt dann ebenfalls in diesem Baustein.

In einer großen Anlage würde also jede Station ihre eigenen Meldungen verwalten.

 

[Jörn]

Jede Station besitzt ein Meldearray aus einer Struktur, welche alle relevanten Daten für den Eventlogger enthält (Eventklasse, Severity, ID usw.).
Jeder Baustein greift via IN/OUT auf dieses Array zu und trägt seine Meldung einfach auf den nächsten freien Platz ein.

Dann gibt es einen Handlingsbaustein, der eben dieses Array abarbeitet und die Meldungen entsprechend absetzt.

...

In einer großen Anlage würde also jede Station ihre eigenen Meldungen verwalten.

Moin,

wie groß ist denn das Array? Und wie verhindert Ihr einen Überlauf? Werden die Messages/Alarm dann verworfen? Oder ist das Array dynamisch?


Das klingt aber, als wäre es recht aufwändig. Gottlob ist unsere Anlage recht klein. "Nur" ~70 Förderbänder und 5 Roboter, die aber auf nur 11 Stationen verteilt sind. Da wäre Dein Ansatz vielleicht mal eine Überlegung wert. Nutzt Ihr das EventGrid, oder habt Ihr was eigenes gestrickt?

Gruß
Jörn

 

[Das Bit ist gekippt...]

Die größere des Arrays als globaler Parameter definiert (bei uns so 64).
Ein Überlaufen in dem Sinne gibt es nicht. Wenn das Array voll sein sollte, wird einfach keine weitere Meldung mehr eingetragen.

Entscheidend ist eigentlich auch nur wie viele Meldungen der Handlingsbaustein absetzen soll. Das sind ja bei weitem nicht so viele.

Ja, am Anfang war das recht aufwendig, was aber auch zum Teil einfach am Eventlogger liegt.
Aber nun funktioniert es sehr gut.

Für die HMI nutzen wir das EventGrid.

Wenn man was eigenes bauen würde, müsste man die ganzen Meldetexte ja als STRING vorliegen haben.
Dann wird es mit mehreren Sprachen wieder schwierig.

 

[ap538]

Zuviel Werbung?
-> Hier kostenlos registrieren

Meine Herrn,

Habe jetzt auch am ende die Events am Laufen.
Das mit die Meldearray Hört sich gut ann, begreife es noch nicht.
Vieleigt kann "Das Bit ist gekippt" etwas mehr darüber Erzählen ?
Bin sehr interessiert.