ElabNET Technik Forum

Link zu diesem Beitrag: Alles auswählen

[url=http://forum.timberwolf.io/app.php/kb/viewarticle?a=120&sid=55ee7f50eb92d1a0e63df60d315f8267]Knowledge Base - 4.6.2.0_ Details zum Triggerverhalten[/url]

Wiki: https://elabnet.atlassian.net/wiki/spac ... schrittene
Anmerkung: keine.

viewtopic.php?f=24&t=1232&p=12455&hilit=SPS#p12455

Der Dispatcher (Verteilungsmechanismus über alle Systeme am TWS) verteilt laufend die empfangenen Werte gezielt an die Empfänger zB. KNX Objekte, Logikeingänge etc. Je nach Einstellung an der Logikzelle wird deren Berechnung angestoßen und abhängig von den Sendeoptionen auch wieder an den Dispatcher zurückgeliefert.

Gibt es mehrere Empfänger eines Objektes, dupliziert der Dispatcher dieses Telegramm und sendet es nacheinander an die Eingänge der Logiken bzw. Objekte.

Daher kann die Reihenfolge der Empfänder eine Rolle spielen, die in manchen Anwendungsfällen zu beachten ist.

Beispeil 1: Ein Objekt wird mehrfach als Eingang einer Logikzelle verwendet:

Der Dispatcher dupliziert das eintreffende Telegramm und sendet es nacheinander an die Eingänge, wobei die Sendereihenfolge der Eingangsnummerierung folgt.
Die Logik wertet jedes Telegramm einzeln aus, d.h. der Wert wird an dem entsprechenden Eingang übernommen und abhängig von dem eingestellten Eingangs-Triggerverhalten wird die Logik ausgeführt - also eventuell sogar auch mehrfach.
D.h. die Logik wird bei Triggeroption a oder c (also nicht bei u) zuerst mit neuem Wert am ersten Eingang berechnet (Eingang 2 hat da noch den alten Wert) und unmittelbar danach erneut am 2. Eingang getriggert und ausgeführt.
Dies kann in Verbindung mit "Inhibit" durchaus gewünscht sein (daher ist inhibit auch immer der letzte Eingang). Die Logik wird mit dem Wert berechnet (inhibit hat dabei noch den alten Wert) und anschließend triggert der Eingang "Inhibit" mit dem neuen Wert und sperrt die Logik.

Ist obiges Verhalten nicht gewünscht, d.h. es sollen erst beide Eingänge den neuen Wert bekommen, bevor die Logik ausgeführt wird, gibt es zwei Möglichkeiten:

Man setzt die Trigger-Option am ersten Eingang (an den ersten Eingängen) auf "U" (update only). Hier übernimmt der Eingang nur den neuen Wert, die Logik wird aber nicht ausgeführt. Nur der letzte Eingang, der mit dem gemeinsamen Objekt verbunden ist, bekommt die gewünschte Trigger-Option "C" (on Change) oder "A" (Always). Die Logik wird dann nur einmal ausgeführt, wenn der 2. Eingang das Telegramm erhält.
Bemerkung: In diesem Beispiel muss auch die Sendeoption auf "A" stehen, so das die Logik nur den Wert True auf den Ausgang schreibt (weil sie bei false gesperrt ist) und bei "C" (on change) daher nie gesendet wird.
Oder man macht per Custom-Logik nur einen Eingang, den man dann intern aufteilt.

Beispeil 2: Ein Objekt wird in mehreren Logiken verwendet:

Der Dispatcher dupliziert das eintreffende Telegramm und sendet es nacheinander an die Logiken, wobei die Reihenfolge der Logik_ID entspricht, die aber nicht beeinflusst werden kann.
Die Logiken werden nacheinander abgearbeitet und senden ihre Werte.
Ein Sonderfall entsteht wenn die Ergebnisse dieser Logiken wieder in einer gemeinsamen Logik z.B. AND-Logik verarbeitet werden.
Um hier ein mehrfaches Triggern und ggf. vorzeitiges Senden mit falschen Werten zu vermeiden, sind in dieser Logikzelle die ersten Eingänge mit "U" (Update Only) zu setzen und nur der letzte Eingang (der vom ursprünglichen Telegramm abhängt) auf "C" oder "A".