Level Controlled Function Blocks

Level Controlled function blocks in the context of this document are defined as following:

  • The input variable xEnable is the defining feature for this type of function block.

  • The status TRUE detected on the input variable xEnable (start condition) starts the operation defined by this particular level controlled function block. The defined operation is running to its ready condition or error condition while the input variable xEnable is TRUE. The status FALSE detected on the input variable xEnable is interpreted as an abort (abort condition). This means the internal state of the function block and all output variables will be reinitialized and it is then ready for a new start (standard handshake).

  • The input variables will not be stored locally and can so influence the current work flow of the defined operation.

  • Only one of the output variables xDone, xBusy or xError can have the status TRUE at the same time.

  • The status of all output variables are valid as long as the status of the output variables xBusy or xDone is TRUE 2.

  • With the falling edge of xBusy the input variable xEnable is sampled and its inverted value is stored as a reset request.

  • The state of the output variables will be valid for a minimum of one invocation even though the state of the xEnable input variable is already set to FALSE. In this case (reset request is TRUE) the internal state of the function block is reinitialized automatically. This can especially happen after an error condition while aborting the defined operation.

  • The status of the output variables other than xDone, xBusy, xError or eErrorID are valid only while xDone has the status TRUE 12.

  • With an active reset request and after the status TRUE of one of the output variables xDone or xError was seen, the input variable xEnable can be set to TRUE again and the function block will restart its defined operation (quick handshake).

Sometimes it is necessary to have a behavior model which never reaches its ready condition. Such a function block has no xDone output variable and no Done state. This behaviour is defined as a Continuous Behaviour. In the context of this document we refer to this kind of behavior models as LConC and LConTlC.

See the detailed descriptions of the reference implementation for the different level controlled function blocks: LCon (FB) | LConTl (FB) | LConTo (FB) | LConTlTo (FB) | LConC (FB) | LConTlC (FB)

Common properties of these types of function blocks:

  • If a specific invocation of a function block detects a start condition, the output variable xBusy is set to the status TRUE immediately.

  • As long as the defined operation of a function block is running the output variable xBusy has the status TRUE.

  • If a error condition was detected, the output variable xError is set to TRUE and the output variable xBusy is set to FALSE. In addition, one of the defined error codes (one value out of the local enumeration type ERROR) will be assigned to the output variable eErrorID.

  • If the ready condition is reached, the output variable xDone is set to TRUE and the output variable xBusy is set to FALSE.

  • If the defined operation can be fully processed in one invocation, the ready condition or the error condition is reached immediately and the TRUE status of the output variable xBusy is never seen.

  • With the rising edge of xDone, the status of all output variables will be frozen.

  • As long as one of the output variables xDone, xBusy or xError has the status TRUE the defined operation of this function block is not yet completed, so further invocations are necessary to complete the Resetting state.

Timing constraints of these function blocks:

  • udiTimeLimit ([µs], 0 ⇒ no operating time limit):
    A function block could, for example, complete a complex task in a loop. The larger the task is, the more time is consumed in the current invocation of this function block. The udiTimeLimit parameter can define how much time per invocation is permitted for consumption in the respective function block. Function blocks with a udiTimeLimit input variable are implemented in such a way that the current invocation is exited when the task is complete (Ready Condition), or when the consumed time for this invocation has exceeded the settings from udiTimeLimit.
  • udiTimeOut ([µs], 0 ⇒ no operating time limit):
    When processing its defined operation, a function block could be forced for example to wait for an external event. It can do this in an internal loop (Busy Wait) or it can check in each invocation whether its task can be fully completed. The udiTimeOut parameter can then define how much time is permitted for consumption for the defined operation. Function blocks with the udiTimeOut input variable are implemented in such a way that the current invocation is exited towards a error condition (xError ⇒ TRUE and eErrorID``⇒ ``ERROR.TIME_OUT) when the time interval as defined by udiTimeOut has been exceeded.

Error Domains and Error Codes (ERROR (Enum) and eErrorID (output)) and their organisation in different domains:

Every Function Block in this document has a Boolean output xError to indicate that there is an error condition reached. In that case the related information will be signaled with the value of the output eErrorID. The eErrorID represents an Integer, indicating the reason of the error. In many cases this integer value is used as input for an additional FB which converts the number to a related localized string in an applicable language.

1

Sometimes it is necessary to have additional output variables with a valid status while xDone is not set to TRUE. In this case, the special behaviour of these variables should be clearly documented.

2(1,2)

Sometimes it is necessary to have additional output variables which a valid only in combination with the status of some other output variables. In this case, the special behaviour and relationship of these variables should be clearly documented.