In diesem Artikel geht es nochmals um unseren Motek Use Case. Dabei wird ein Peakboard direkt mit einer Siemens S7 Steuerung gekoppelt, um dynamisch auf Ereignisse, der aus Fischertechnik gebauten Stanzmaschine, zu reagieren. Der konkrete Use Case wird im Artikel „Motek Use Case mit Fischertechnik“ diskutiert. Heute soll es nur um die Anzeige des Störungsbalkens gehen.


Die beiden folgenden Bilder zeigen den Störungsbalken. Es ist lediglich ein Textfeld mit einer definierten Hintergrundfarbe und einem Text.

Ein grüner Balken ist der fehlerfreie Normalzustand. Er soll rot hinterlegt sein, wenn die S7-Datenquelle von der Steuerung keine Daten empfängt, weil sie zum Beispiel gerade nicht im Netzwerk erreichbar ist. Ist dies der Fall, bleibt die S7-Datenquelle leer und auch das Refreshed-Ereignis, das die eigentliche Visualisierungslogik enthält, wird nicht aufgerufen. Hier ist die logische Abfolge, um sauber nachvollziehbar auf dieses „nicht abrufen“ von Daten zu reagieren:

  • Es gibt einen globalen Datentyp namens ZaehlerLetzterKontakt.
  • Im Refreshed-Event der Datenquelle wird ZaehlerLetzterKontakt auf 0 gesetzt.
  • In einem Timer-Event wird jede Sekunde ZaehlerLetzterKontakt um eins nach oben gezählt.
  • Wenn der Wert von ZaehlerLetzterKontakt einen gewissen Wert übersteigt (z. B. 10) wissen wir, dass es ein Problem gibt und blenden den roten Balken mit dem Störungstext ein. Wenn der Wert unter 10 bleibt ist noch alles in Ordung und der Balken ist grün.

Hier die globale Variable:

Die Verwedung der Variable im Refereshed-Event:

Und zuletzt der Timer, der je nach Status den Balken setzt:

Dieser Pattern ist gängig für den Fall, dass man innerhalb von Peakboard das Ausbleiben von Ereignissen nach einer gewissen Zeit behandeln möchte. Es funktioniert so natürlich auch für andere Datenquellen und Ereignisse.

Teilen:
FacebookTwitter