Level Controlled Function Blocks

Zustandsgesteuerte Funktionsbausteine werden im Kontext dieses Dokuments wie folgt definiert:

  • Die Eingangsvariable xEnable definiert den Typ dieses Funktionsbausteins.

  • Der Status TRUE an der Eingangsvariablen xExecute (start condition) startet die Funktionalität, die mit diesem speziellen zustandsgesteuerten Funktionsbaustein definiert wurde. Die definierte Operation läuft bis zur ihrer ready condition oder error condition, während die Eingangsvariable xEnable TRUE ist. Der Status FALSE an der Eingangsvariablen xEnable wird als Abbruch interpretiert (abort condition). Dies bedeutet, dass der interne Zustand des Funktionsbausteins und alle Ausgangsvariablen neu initialisiert werden und er dann bereit für einen Neustart ist (standard handshake).

  • Die Eingangsvariablen werden nicht lokal gespeichert und können so den Ablauf der definierten Bearbeitung beeinflussen.

  • Es kann immer nur eine der Ausgangsvariablen xDone, xBusy oder xError den Zustand TRUE haben.

  • Die Zustände aller Ausgangsvariablen sind so lange gültig, wie der Zustand der Ausgangsvariablen xBusy oder xDone TRUE ist [2].

  • Mit der fallenden Flanke von xBusy wird die Eingangsvariable xEnable 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 xEnable schon auf FALSE gesetzt wurde. In diesem Fall (reset request ist TRUE) wird der interne Zustand des Funktionsbausteins automatisch neu initialisiert. Dies kann vor allem nach einer Fehlerbedingung während des Abbruchs der Bearbeitung auftreten.

  • Der Zustand der Ausgangsvariablen außer xDone, xBusy, xError oder eErrorID ist gültig, solange xDone den Status TRUE [1][2] hat.

  • Mit einem aktiven reset request und nachdem eine der Ausgangsvariablen xDone oder xError TRUE wurde, kann die Eingangsvariable xEnable wieder auf TRUE gesetzt werden und der Funktionsbaustein startet die Bearbeitung neu (quick handshake).

Manchmal ist ein Behaviour Model notwendig, das niemals seine ready condition erreicht. Ein solcher Funktionsbaustein hat keine Ausgangsvariable xDone und keine Zustand Done. Diese Verhalten wird als Continuous Behaviour definiert. Im Kontext dieses Dokuments heißen diese Behaviour Models LConC und LConTlC.

Für detaillierte Beschreibungen der Referenzimplementierung der unterschiedlichen zustandsgesteuerten Funktionsbausteine siehe: LCon (FB) | LConTl (FB) | LConTo (FB) | LConTlTo (FB) | LConC (FB) | LConTlC (FB)

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 Ausführungszeit):
    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 zu 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.