Edge Triggered Function Blocks¶

Flankengesteuerte Funktionsbausteine werden im Kontext dieses Dokuments wie folgt definiert:

Die Eingangsvariable xExecute definiert den Typ dieses Funktionsbausteins.

Eine steigende Flanke an der Eingangsvariable xExecute (start condition) startet die Bearbeitung dieses speziellen flankengetriggerten Funktionsbausteins.

Alle Eingänge außer xExecute und die optional vorhandene Variable xAbort werden mit dieser steigenden Flanke abgetastet. Ihre Werte werden lokal gespeichert. Somit können spätere Änderungen dieser Eingänge die definierte Funktionalität nicht beeinflussen, während sie läuft [1].

Die Eingangsvariable xExecute kann auf FALSE gesetzt werden, nachdem die Ausgangsvariable xBusy TRUE wurde.

Eine fallende Flanke an der Eingangsvariablen xExecute bricht die Bearbeitung nicht ab. Die Bearbeitung läuft normal bis zu ihrer ready condition, abort condition oder error condition weiter.

Nur der Wert TRUE, der an der optional vorhandenen Eingangsvariablen xAbort angelegt wird, bricht die definierte Bearbeitung ab (abort condition)..

Wenn die optional vorhandene Variable xAbort und die Eingangsvariable xExecute den Wert TRUE haben, wird die Abbruchbedingung sofort erreicht.

Nur eine der Ausgangsvariablen xDone, xBusy, xError oder die optional vorhandene Ausgangsvariablen xAborted` kann den Zustand TRUE haben.

Wenn eine Abbruchbedingung entdeckt wurde, wird die Ausgangsvariable xAborted auf TRUE gesetzt, nachdem die Ausgangsvariable xBusy auf FALSE gesetzt wurde.

Mit der fallenden Flanke von xBusy wird die Eingangsvariable xExecute gelesen und ihr invertierter Wert wird als reset request gespeichert.

Der Zustand der Ausgangsvariablen ist für mindestens einen Aufruf gültig, auch wenn der Zustand der Eingangsvariablen xExecute bereits schon auf FALSE gesetzt wurde. In diesem Fall (reset request ist TRUE) wird der interne Zustand des Funktionsbausteins automatisch neu initialisiert. In allen anderen Fällen (xExecute ist noch TRUE) wartet der Funktionsbaustein auf eine fallende Flanke an der Eingangsvariablen xExecute, bevor der Funktionsbaustein neu initialisiert wird (standard handshake).

Der Zustand aller Ausgangsvariablen außer xDone, xBusy, xError, xAborted oder eErrorID ist gültig, solange xDone den Zustand TRUE [2][3] hat.

Mit einem aktiven reset request und nachdem eine der Ausgangsvariablen xDone, xError oder xAborted TRUE wurde, kann die Eingangsvariable xExecute wieder auf TRUE gesetzt werden und der Funktionsbaustein kann die definierte Operation neu starten (quick handshake).

Gemeinsame Eigenschaften dieser Funktionsbausteintypen:

Wenn ein spezieller Aufruf eines Funktionsbausteins eine start condition entdeckt, wird die Ausgangsvariable xBusy sofort auf den Zustand TRUE gesetzt.
Solange die definierte Bearbeitung eines Funktionsbausteins läuft, hat die Ausgangsvariable xBusy den Zustand TRUE.
Wenn eine error condition entdeckt wurde, wird die Ausgangsvariable xError auf TRUE gesetzt und die Ausgangsvariable xBusy wird auf FALSE gesetzt. Zusätzlich wird einer der definierten Fehlercodes (ein Wert des lokalen Enumerationstyps ERROR) der Ausgangsvariablen eErrorID zugewiesen.
Wenn eine ready condition erfüllt wurde, wird die Ausgangsvariable xDone auf TRUE gesetzt und die Ausgangsvariable xBusy wird auf FALSE gesetzt.
Wenn die definierte Operation in einem Aufruf vollständig abgearbeitet werden kann, werden die ready condition oder die error condition sofort erreicht und an der Ausgangsvariablen xBusy erscheint nie der Wert TRUE.
Mit einer steigenden Flanke an xDone, wird der Zustand aller Ausgangsvariablen eingefroren.
Solange eine der Ausgangsvariablen xDone, xBusy oder xError den Status TRUE hat, ist die Bearbeitung dieses Funktionsbausteins noch nicht abgeschlossen. Weitere Aufrufe sind notwendig, um den Zustand Resetting abzuschließen.

Das Zeitverhalten dieser Funktionsbausteine

udiTimeLimit ([µs], 0⇒ keine Begrenzung der Bearbeitungszeit):

Ein Funktionsbaustein könnte zum Beispiel eine komplexe Task in einer Schleife abschließen. Je größer die Aufgabe ist, umso mehr Zeit wird beim Aufruf des Funktionsbausteins verbraucht. Der Parameter udiTimeLimit bestimmt, wie viel Zeit pro Aufruf für die Ausführung des jeweiligen Funktionsbausteins erlaubt ist. Funktionsbausteine mit einer Eingangsvariablen udiTimeLimit werden so implementiert, dass der aktuelle Aufruf beendet wird, wenn die Aufgabe beendet ist (Ready Condition), oder wenn die verbrauchte Zeit die Einstellung in udiTimeLimit überschritten hat.
udiTimeOut ([µs], 0: Keine Begrenzung der Bearbeitungszeit):

Bei der Ausführung seiner Operation kann ein Funktionsbaustein zum Beispiel gezwungen werden, auf ein externes Ereignis zu warten. Dies kann in einer internen Schleife (Busy Wait) geschehen, oder der FB kann bei jedem Aufruf überprüfen, ob seine Funktion vollständig ausgeführt werden kann. Der Parameter udiTimeOut kann definieren, wie viel Zeit für die Ausführung der definierten Bearbeitung erlaubt ist. Funktionsbausteine mit der Eingangsvariablen udiTimeOut werden so implementiert, dass der aktuelle Aufruf zur error condition über geht (xError``⇒ ``TRUE und eErrorID ⇒ ERROR.TIME_OUT), wenn das mit udiTimeOut definierte Zeitintervall überschritten wurde.

Fehlerdomänen und Fehlercodes (ERROR (Enum) und eErrorID (output)) und ihre Organisation in verschiedenen Domänen:

Jeder Funktionsbaustein dieses Dokuments hat einen booleschen Ausgang xError, der anzeigt, dass eine Fehlerbedingung aufgetreten ist. In diesem Fall wird die entsprechende Information zusammen mit dem Wert des Ausgangs eErrorID angezeigt. Die eErrorID ist ein Integer-Wert, der die Fehlerursache anzeigt. Oft wird dieser Integer-Wert als Eingang für einen zusätzlichen FB verwendet, der die Nummer in einen lokalisierten String der geeigneten Sprache umwandelt.