Einführung

Als Beispiel diene folgende einfache Aufgabenstellung: Es soll auf eine KNX-Adresse TRUE gesendet werden, sobald mindestens eine von drei Türen geöffnet wird.

Für diese Logik kann ein OR-Logik-Modul verwendet werden. Die fertig erstellte Logikzelle wird im Logikeditor wie folgt dargestellt:

Die Logik verwendet die drei KNX-Objekte K-1186, K-1187 und K-1187 als Eingänge, verarbeitet die dort erhaltenen Informationen in der Form einer ODER-Verknüpfung und gibt das Resultat an das KNX-Objekt K-1196 weiter.

Für den Anwender besteht eine Logik somit auf den ersten Blick aus drei Elementen:

• Eingang resp. Auslöser (wird auf der linken Seite dargestellt): im Beispiel die drei KNX-Objekte, welche die drei Türzustände (offen/geschlossen) repräsentieren und an die drei Variablen “Input 1”, “Input 2” und “Input 3” übergeben werden; jede Wertänderung an einem dieser Eingänge löst die Abarbeitung der Logik aus.

• Kernfunktion (ist bei bei einem Logikmodul fest vorgegeben oder wird bei einer Custom-Logik individuell vom Anwender codiert): im Beispiel die logische ODER-Verknüpfung.

• Ausgang (wird auf der rechten Seite dargestellt): im Beispiel die Variable “Output”, welche an das KNX-Objekt für den gesammelte Türzustand (offen/geschlossen) übergeben wird.

Dieses Grundwissen reicht aus, um einfache Logiken anzulegen. Zudem sollte der Anwender verstehen, wie in welchen Schritten die Bearbeitung einer Logik intern abläuft, damit er weiss, wie er allenfalls den Bearbeitungsprozess beeinflussen kann. Wichtigster Merkpunkt für das Verständnis des Bearbeitungsprozesses ist die Erkenntnis, dass eine Logik (nur) abgearbeitet wird, wenn sie ausgelöst wird. Sie benötigt somit einen Trigger. Im obigen Beispiel “triggert” jede Wertänderung an einem der drei Eingänge die Logik.

Wer sich später etwas vertiefter mit der Logikfunktion des TWS auseinandersetzen wird, wird rasch erkennen, dass der Logikeditor innerhalb der drei oben vorgestellten Hauptelemente (Eingang, Auslöser, Kernfunktion und Ausgang) viel weitere Funktionen, resp. Einstellungsmöglichkeiten verfügt.

In diesem Kapitel werden die verschiedenen Elemente der Logikfunktion vorgestellt. Für einen ersten Überlick sind die Kapitel

• Bearbeitungsprozess einer Logik

• Kernfunktion einer Logik

• Eingänge

• Ausgänge und

• Triggerfunktion

dienlich. Die weiteren Kapitel beschreiben Funktionen, die erst bei vertiefteren Auseinandersetzung mit der Thematik eine Rolle spielen.

Bearbeitungsprozess einer Logik

Aus Anwendersicht - und daher vereinfacht dargestellt - vollzieht sich die Bearbeitung einer Logik in sechs Prozessschritten:

Nicht zum eigentlichen Bearbeitungsprozess der Logik gehört die Aktivierungsfunktion. Diese wird in der GUI in der unteren rechten Ecke der Logikbox über die nachfolgenden Symbole bedient. Der Aktivierungsstatus wird ebenfalls in der Logikbox (oben in der Mitte) angezeigt.

Anhalten

Starten

Es ist selbsterklärend, dass der Bearbeitungsprozess nur durchgeführt wird, wenn die Logik aktiviert( gestartet) ist. Zwischen dem Anhalten auf der Aktivierungsebene und dem Abbruch im Rahmen der Abbruchsfunktion besteht jedoch ein ganz wesentlicher Unterschied: Eine pausierte Logik liest keine Daten an den Eingängen, bei einer abgebrochenen Logik bleiben die die Eingänge weiterhin aktiv und lesen die Daten mit; eine abgebrochene Logik wird somit nach ihrer Freischaltung mit den zwischenzeitlich aktualisierten Werten weiterarbeiten, eine pausierte Logik kennt diese zwischenzeitlich erfolgten Wertänderungen nicht.

Über die Funktion “Abkoppeln” kann in der GUI vorübergehend die Datenübernahme, resp. die Datenübergabe gestoppt werden; die Logik wird mithin von der Aussenwelt isoliert. Dies ist vor allem für Tests im Doktormodus sinnvoll. --------- Während der Dauer der Abkkoppelung erfolgte Wertänderungen sind der Logik “beim Wiederankoppeln” nicht bekannt. -----------

Kernfunktion einer Logik

Beim Anlegen einer Logik muss sich der Anwender entscheiden, ob er entweder eines der auf dem TWS fix installierten Logik-Module verwenden will, oder ob er eine eigene Custom-Logik codieren will.

Verwendung eines Logik-Modul

Aktuell stehen über 45 Logik-Module zur Verfügung; sie werden unter Eingebaute Logik-Module vorgestellt. Weil sie mit den Zusatzfunktionen der Ein- und Ausgänge kombiniert werden können, geht ihr Funktionsumfang wesentlich weiter, als dies im ersten Moment aufgrund der blossen Funktionsbeschreibung zu erahnen wäre. Auf diese Weise erhält bspw. bereits ein einfaches “AND”-Logik-Modul ein äusserst breites und umfassendes Einsatzfeld (Näheres dazu unter https://wiregate.atlassian.net/wiki/spaces/TSKB/pages/397803554/Die+Verwendung+der+Bausteine+am+Beispiel+des+AND-Moduls). Weitere Beispiele finden sich unter Mit Logik-Modulen gelöste Aufgabenstellungen (Beispiele).

Erstellung einer Custom-Logik / Verwendung einer zur Verfügung gestellten Custom-Logik

Reicht die Funktionalität der Logik-Module nicht aus, erstellt sich der Anwender eine Custom-Logik; diese setzt sich aus Modulbausteinen, welche ähnliche Funktionen aufweisen wie die Logik-Module, zusammen.
Zudem werden aus der Community Fertige Custom-Logiken (Beispiele)zur Verfügung gestellt.

Eingänge

Eine Logik kann zwischen 0 und einer beliebigen Zahl von Eingänge verfügen; dabei wird zwischen drei Arten von Eingängen unterschieden:

• Input (Wertübergabe-Eingänge): Sie übergeben der Logik die zu verarbeitenden Werte

  • entweder als dynamische Variable (durch Verknüpfung mit einem Objekt des Objektsystems)

  • oder als konstante Variable (durch Verwendung der Funktion “Parameter” bei den Einstellungen in der Logikbox).

• Inhibit (Sperr-Eingänge): Über ein TRUE auf diesem Eingang kann die Ausführung der Logik gesperrt werden, näheres dazu unten unter → Sperrfunktion)

• Trigger (Trigger-Eingänge): Sie definieren weitere Elemente, die dieser Logik als Trigger dienen; näheres dazu unten unter → Triggerfunktion.

Die Eingänge haben für die Abarbeitung einer Logik folgende Funktionen:

• sie übergeben Werte an die Logik (Wertübergabefunktion), wobei diese Werte

  • entweder von einem Objekt des Objektsystems stammen,

  • oder als Parameter für die konkrete Logik (im Sinne von Konstanten) vorgegeben sind;

• sie lösen die Abarbeitung der Logikzelle aus (Triggerfunktion), resp.

• sie beeinflussen das Startverhalten der Logik (Startfunktion),

• sie können einen vom einem Objekt des Obkektsystem übergebenen Wert vor der Bearbeitung in der Logik logisch negieren (Negationsfunktion),

• sie können einen von einem Objekt des Objektsystems stammenden Wert umwandeln (Konvertierungsfunktion über “Innerhalb Bereich”),

• sie können einen von einem Objekt des Objektsystems stammenden Wert mit einer Vorgabe vergleichen (Vergleichsfunktion).

Ausgänge

Eine Logik muss mindestens einen Ausgang haben, je nach Kernfunktion der Logik stehen u. U. auch mehrere Ausgänge zur Verfügung. Weil der der Anwender einem Ausgang mehrere Objekte des TWS-Objektsystems zuordnen kann, ist es faktisch möglich, mit einer Logik gleichzeitig mehrere Objekte zu bedienen.

Die Ausgänge haben für die Abarbeitung einer Logik folgende Funktionen:

• sie übergeben Werte an Objekte des Objektsystems (Wertübergabefunktion),

• sie bestimmen,

  • bei welchem Ereignis die Ausgabewerte an das Objekt des Objektsystems übergeben werden soll (Sendefunktion), und

  • ob diese Übergabe unmittelbar oder verzögert erfolgen soll (Verzögerungsfunktion)

• sie können einen Wert vor der Übergabe an das Objekt des Obkektsystem logisch negieren (Negationsfunktion),

• sie können einen von einem Objekt des Objektsystems stammenden Wert umwandeln (Konvertierungsfunktion über “Mapping”).

Triggerfunktion

Eine Logik wird nur ausgeführt, wenn sie von einem Trigger dazu aufgefordert (d.h. “ausgelöst”) wird. Umgekehrt wird eine Logik jedes Mal ausgeführt, wenn ihr Auslöser gegeben ist; die kann nicht gewünscht sein, wenn bspw. während einem bestimmten Zeitraum (bspw. in der Nacht) ein bestimmter Zustand erhalten bleiben soll. Dementsprechend hat die Beeinflussung der Auslösefunktion eine wichtige Bedeutung; für diesen Zweck werden Trigger verwendet.

Als mögliche Trigger stehen zur Verfügung

• ein Wertübergabeeingang (Input), sofern seine Triggerfunktion auf A (always) oder C (on Change) gesetzt ist (näheres sogleich);

• ein spezieller Triggereingang, der abhängig von einem äusseren Ereignis die Logik triggert; als solche Trigger dienen können

  • ein Zeitintervall (bspw. alle 30 Sekunden),

  • ein Zeitpunkt (bspw. 08:25 Uhr) oder

  • ein “Data Value” --------- Was ist das? ---------;

• ein Trigger, welcher innerhalb einer Custom-Logik (bspw. über den Logikbaustein → Clocksignal) codiert wurde.

Triggerfunktionen über einen Input (Wertübergabeeingang)

In der GUI (am Eingang einer Logikbox) und im Input-Array einer Custom-Logik kann die Trigger-Funktion des jeweiligen Wertübergabe-Eingangs festgelegt werden.

Die GUI stellt die aktuell eingestellte Triggerfunktion des jeweiligen Eingangs dar und lässt diese auch ändern. Über die GUI kann auch die in einer Custom-Logik vorgenommene Definition übersteuert werden.

Ein Eingang kann zwei Triggerfunktionen annehmen. Es ist aber auch möglich, die Triggerfunktion des Eingangs auszuschalten:

• Einstellung “A” (always): Der Eingang funktioniert immer als Trigger ----- was bedeutet dies genau -----

• Einstellung “C” (on change): Der Eingang funktioniert nur bei einer Wertänderung als Trigger.

• Einstellung “U” (update): Der Eingang funktioniert nicht als Trigger, d.h. sein Wert wird einzig an die Eingangsvariable übergeben.

Bei der Definition im Input-Array einer Custom-Logik werden die entsprechenden Kleinbuchstaben verwendet (also “a”, “c” oder “u”):

  "Input": [
    ["Eingang 1 ","(mit Triggerfunktion always)","$In1","a" ],
    ["Eingang 2 ","(mit Triggerfunktion on change)","$In2","c" ],
    ["Eingang 3 ","(ohne Triggerfunktion)","$In3","u" ]
  ]

Triggerfunktion über einen Zeitintervall-Auslöser

Oft ist es gewünscht, eine Logik regelmässig in einem bestimmten Rhythmus durchlaufen zu lassen. In solchen Fällen muss ein Zeitintervall-Trigger angewendet werden.

In der GUI kann dies erreicht werden, indem ein Trigger-Eingang erstellt wird und diesem die Quelle “Intervall“ zugeordnet wird. Als Intervall kann eine beliebige Zahl von Sekunden eingegeben werden.

In einer Custom-Logik verwendet man hierfür den Logikbaustein → Clocksignal.

Will man das Zeitintervall nur zu bestimmten Zeiten (bspw. nur am Sonntag) laufen lassen, wählt man in der GUI als Source nicht “Intervall”, sondern “Zeit” und dort den Typ “Intervall”.

In einer Custom-Logik erreicht man dieses Ziel über ----------------------- ???? noch nicht versucht, ich vermute über “Cron” ---------------.

Triggerfunktion zu einem bestimmten Zeitpunkt

Will man ein Logik nur an einem bestimmten Zeitpunkt (bspw. jeden Tag um 08:15 Uhr ausführen lassen, kann ein Zeitpunkt-Trigger verwendet werden.

In der der GUI erstellt man hierfür wiederum einen Triggereingang und wählt als Quelle “Zeit”.

Die Eingabemaske erlaubt es, entweder eine Zeit einzugeben und über die jeweiligen Checkboxen die gewünschten Wochentage auszuwählen. Das obige Beispiel führt dazu, dass die Logik jeweils werkstags um 08:15 Uhr “getriggert wird.”

Werden komplexere Lösungen erforderlich, kann dies mit Hilfe der Cron-Syntax realisiert werden. Zu diesem Zweck wählt man in der vorstehenden Eingabemaske als Typ nicht “Zeit“, sondern “Cron-Syntax”. Man erhält so ein Eingabefeld, in welches man einen String eingeben kann. Dieser String muss der Cron-Syntax entsprechen.

Dies baut auf 6 Feldern auf, welche jeweils durch eine Leerschlag voneinander getrennt sind. Die Reihenfolge der Felder ist wie folgt vorgegeben:

┌───────────── Sekunde (0 - 59)
│ ┌───────────── Minute (0 - 59)
│ │ ┌───────────── Stunde (0 - 23)
│ │ │ ┌───────────── Tag des Monats (1 - 31)
│ │ │ │ ┌───────────── Monat (1 - 12)
│ │ │ │ │ ┌───────────── Wochentag (0 - 6)
│ │ │ │ │ │

*  *  *  *  * *

Das erste Feld repräsentiert somit, die Sekunden, das zweite die Minuten, dass dritte die Stunden und so weiter.

Weil intern immer die Cron-Syntax verwendet wird, werden auch alle über die GUI-Maske eingegebenen Zeitpunkt-Trigger in der Cron-Syntax behandelt. Dies sieht man in der obigen Eingabemaske. Dort wird unten das Ergebnis der Eingabe über die Felder wie folgt dargestellt: 0 15 8 * * 1,2,3,4,5 Dieser String lässt sich nun einfach übersetzen:

Weitere Erläuterungen zur Cron-Syntax (einer in der UNIX-Welt gebräuchlichen Notation) findet sich bspw. unter https://de.wikipedia.org/wiki/Cron; zu beachten ist, dass die Cron-Syntax des TWS zusätzlich auch ein Feld Sekunden (ganz links) vorsieht.

Über die Cron-Syntax können auch Intervalle definiert werden: Der String 0 0/30 0-5,21-23 * * * führt dazu, dass der Trigger jeden Tag, im Zeitraum zwischen 21 Uhr bis 05 Uhr jeweils zur ganzen Stunden und dann in einem Intervall von 30 Minuten ausgelöst wird.

In der GUI ist dies in einem etwas eingeschränkterem Rahmen auch möglich, in dem man in der Eingabemaske “Source” den Typ Intervall anwendet.

Triggerfunktion über einen Wertveränderung am Eingang

[--------- Das fehlt, ich habe dies noch nicht ausprobiert ----]

Abbruchfunktion

In bestimmten Situationen soll die Ausführung einer Logik abgebrochen werden, resp. die Logik soll schon gar nicht ausgeführt werden. Erfolgt ein Abbruch, wird nichts mehr an die Ausgänge gesendet.

In der GUI wird ein Abbruch erreicht, indem man einen Inhibit-Eingang erstellt. Sobald auf diesem ein TRUE eintrifft, wird die Ausführung der Logik abgebrochen oder umgekehrt, solange an allen Inhibit-Eingängen ein FALSE anliegt, wird die Logik ausgeführt.

In einer Custom-Logik verwendet man für einen Abbruch den Logik-Baustein → Break. Sobald einer seiner Eingänge - er kann mehrere haben - auf TRUE gesetzt wird, bricht auch hier die Ausführung der Logik ab.
Beim einem Abbruch werden keine im Code nachfolgenden Logik-Bausteine mehr berechnet und ausgeführt. Es wird auch kein Ausgang gesendet, selbst wenn die eine Variable, die einem Ausgang zugeordnet ist, bereits gesetzt worden ist.
Die Verwendung von ["Break", ["$VAR<Inhibit?>"]] erlaubt es, in der GUI beliebig viele Eingänge hinzuzufügen, die den Abbruch einer Custom-Logik triggern können.

Weitere (optionale) Funktionen der Ein- und Ausgänge

Die GUI des Logikeditors stellt bei den Ein- und Ausgängen verschiedene Optionen zur Verfügung. Diese Optionen stellen - funktional betrachtet - Erweiterung der Kernfunktion des jeweils gewählten Logik-Moduls um weitere Funktionen dar. Oder mit Worten ausgedrückt. Jede dieser Optionen fügt der betreffende Logik - neben ihrer Kernfunktion - eine zusätzliche Funktion hinzu; damit wird das Programmieren einfach gemacht oder - wieder mit anderen Worten - es können mehrere prozedurale Funktionen miteinander kombiniert werden- ohne dass eine Custom-Logik erstellt werden muss.
Die Leistungsbreite dieses Konzepts wird unter https://wiregate.atlassian.net/wiki/spaces/TSKB/pages/397803554/Die+Verwendung+vom+Logik-Modulen+am+Beispiel+des+AND-Modulsvorgestellt.

Wertübergabefunktion

Ein- und Ausgänge stellen die Schnittstellen der Logik zum Objektsystem des TWS dar.

Über diese Schnittstellen können Werte von und an die Logik übergeben werden. Voraussetzung ist, dass die Datentypen der Objekte und der Logik übereinstimmen. Ist dies nicht der Fall, stellt der Logikeditor →Konvertierungsfunktionen zur Verfügung. Im Rahmen der Wertübergabe können im Logikeditor gleichzeitig auch →Vergleichsfunktionen hinzugefügt werden.

Jedem Ein- und Ausgang können mehrere Objekte des Objektsystems zugeordnet werden. Auf diese Weise kann bspw. das Resultat einer Logik gleichzeitig an mehrere Objekte gesendet werden.

Konvertierungsfunktion

Jede Datenübergabe in der Informatik setzt voraus, dass die Datentypen übereinstimmen. Der Objektsystem des TWS und damit auch die Logikfunktionen arbeiten mit folgenden Datentypen:

• Boolean

• Integer

• Float

• String

Bei der Datenübergabe an Eingängen

Beispiel: Das AND-Logik-Modul arbeitet mit BOOLEAN-Daten. Soll es mit einem Wert vom Typ “Float” bedient werden, muss bei der Übergabe an die Logik eine Datenkonvertierung erfolgen.
Für diesen Zweck kann man in der GUI einem Eingang die Funktion “Innerhalb Bereich” zuordnen. Diese Funktion prüft, ob der Eingangswert im angegebenen Bereich liegt; falls ja, erhält der Eingang den Zustand "TRUE", anderenfalls "FALSE".

Bei der Datenübergabe an Ausgängen

Bei Ausgängen stellt die GUI die Funktion “Mapping” zur Verfügung. Sie erlaubt es, Werte umzuwandeln. Dies kann beispielsweise sinnvoll sein, wenn ein AND-Logik-Modul eine Objekt bedienen soll, welches vom Typ Integer ist. So kann bspw. ein Dimmwert von 60% an eine Leuchte gesendet werden, wenn das Ergebnis der Logik “TRUE” lautet.

In Custom-Logiken

In Custom-Logiken kann die Datenkonvertierung direkt im Code erfolgen. Dafür stehen - abhängig vom Anwendungsfall - verschiedene Modulbausteine (bspw. “Latch” oder “Multiplexer”) zur Verfügung.

Negationsfunktion

In der GUI des Logikeditors können Werte auch umgewandelt werden, indem sie negiert werden. Dies erfolgt indem das der kleine Kreis beim entsprechenden Ein- oder Ausgang angeklickt wird.

In Custom-Logiken erfolgt die Negation, indem einer Variablen (vor dem $-Zeichen, aber innerhalb der Anführungszeichen) ein “-” vorangestellt wird.

Vergleichsfunktion

In der GUI des Logikeditors kann festgelegt werden, dass die an den Eingängen übergebenen Daten einer Vergleichsoperationen unterzogen werden, bevor sie von der Logik verarbeitet werden. Der Eingang erhält so - je nach Anwendungsfall - entweder eine Filter- oder eine Wenn-Dann-Funktion. So kann bspw. geprüft werden, ob der übergebene Integer-Wert kleiner als “500” ist; trifft dies zu, wird der Logik ein boolean “TRUE” zur Verarbeitung übergeben.
In der GUI stehen folgende Vergleichsfunktionen zur Verfügung:

• “Innerhalb Bereich”: prüft, ob der Eingangswert im angegebenen Bereich liegt; falls ja, erhält der Eingang den Zustand "TRUE", anderenfalls "FALSE".

• Schwellwert unter: prüft, ob der vorgebene Schwellwert unterschritten ist; falls ja, erhält der Eingang den Zustand "TRUE", anderenfalls "FALSE".

• Schwellwert über: Wird der Schwellwert überschritten, dann nimmt der Eingang den Zustand "true" an.

• Schwellwert mit Hysterese: Wird die obere Grenze überschritten, dann nimmt der Eingang den Zustand "true" an, beim Unterschreiten des unteren Grenze schaltet der Eingang auf "false". Dazwischen verbleibt der Eingang im bisherigen Zustand.

Es kann bspw. verglichen

Startfunktion

Sendefunktion

Verzögerungsfunktion

Ab hier Steinbruch (, d.h. blosse Grundlage für die weitere redaktionelle Bearbeitung)

• Optionen für Eingänge

  • Parameter: Definiert für einen Eingang einen konstanten Wert. Achtung: Dieser wird nur beim Abspeichern in die Berechnung übernommen.

  • Innerhalb Bereich: Prüft ob der Eingangswert im Bereich liegt (wenn ja, dann bekommt der Eingang den Zustand "true", sonst "false").

  • Schwellwert unter: Wird der Schwellwert unterschritten, dann nimmt der Eingang den Zustand "true" an.

  • Schwellwert über: Wird der Schwellwert überschritten, dann nimmt der Eingang den Zustand "true" an.

  • Schwellwert mit Hysterese: Wird die obere Grenze überschritten, dann nimmt der Eingang den Zustand "true" an, beim Unterschreiten des unteren Grenze schaltet der Eingang auf "false". Dazwischen verbleibt der Eingang im bisherigen Zustand.

    • Der untere Schwellwert darf damit nicht 0 sein: https://forum.timberwolf.io/viewtopic.php?f=24&t=1043&hilit=logikeditor…

• Optionen für Ausgänge

  • Mapping: Damit kann den Werten true/false ein beliebiger Wert zB Szenennummer oder Float-Zahl zugeordnet werden.

  • Einschaltverzögerung: Das Einschalten von 0 auf 1 wird um eine definierte Zeit verzögert gesendet.

  • Ausschaltverzögerung: Das Ausschalten von 1 auf 0 wird um eine definierte Zeit verzögert gesendet.

  • Ein- und Ausschaltverzögerung: Das Umschalten von 0 auf 1 und 1 auf 0 wird verzögert. Es können getrennte Verzögerungszeiten für das Ein- bzw. Ausschalten definiert werden.

  • Hinweis: Man kann einem Ausgang mehrere Ziele zuordnen! Zu diesem Zweck einfach in der Zielauswahl (DOS) eine weitere Auswahl treffen.

• Neuberechnung, sobald

  • entweder sich ein Eingangsinal ändert

  • oder ein Triggereingang betätigt wird.

  • Nicht bei Wertänderung eines Parameters (bspw. im Doktor-Modus)

• Trigger-Optionen an den Eingängen

  • "a" (always): Jedesmal wenn ein Telegramm am Eingang empfangen wird.

  • "c" (on change): wenn ein Telegramm mit geändertem Wert empfangen wurde

  • "u" (update only): kein Trigger der Logikzelle, aber der Wert wird in die Logik übernommen. Wird die Logik durch einen anderen Eingang oder Trigger später ausgeführt, wird der letzte an diesem Eingang empfangene Wert verwendet. "u" ist eigentlich selten notwendig, insbesondere aber, wenn ein Objekt mehrfach an eine Zelle angeschlossen ist zB. Eingang + Inhibit. Ausführlicheres siehe hier: https://forum.timberwolf.io/app.php/kb/viewarticle?a=120

• Sende-Optionen an den Ausgängen

  • "a": jedesmal (always)

  • "c": nur bei Wertänderung

  • "t": wenn ein Timer abgelaufen ist (on timer);
    Die Option "t" ist nicht selektiv, d.h. werden mehrere Timer in einer Custom Logik verwendet, dann führt jeder abgelaufene Timer dazu, dass der Ausgang gesendet wird. Zu beachten ist, dass bei Verwendung eines Timers die Berechnungen weiterhin durchgeführt werden (abhängig von der Optionen der Eingänge), nur eben nichts gesendet wird. Mögliche Timer-Module sind:

    • Monoflop (single shot timer): Triggert nach Ablauf der Zeitdauer

    • Clock (zyklischer Timer) : Triggert jedesmal nach Wechsel des Taktzustandes

    • Cron (Uhrzeit abhängiger Timer): Triggert jedesmal bei erreichen der eingestellten Zeit(en)

• Trigger-Definition

  • Intervall: zyklisches Senden

  • Data Value: Zusätzliches Eingangsobjekt, dass als Trigger dient.

  • Zeit: Trigger zu einem bestimmten Zeitpunkt (auswählbar Wochentage und Uhrzeit)

• Unterschied Start / Stop (unten rechts) / Inhibit / Abkoppeln (am Ein- oder Ausgang)

  • "Stop" führt zu einem Pausieren, d.h. es werden keine Werte an den Eingängen gelesen

  • Ein Inhibit-Eingang führt dazu, dass die übrigen Eingänge zwischenzeitlich weiter aktualisiert werden

  • Abkoppeln ist vor allem für Tests mit dem Doktormodus geeignet.