Edge Triggered Function Blocks¶

Edge Triggered function blocks in the context of this document are defined as follows:

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

A rising edge detected at the input variable xExecute (start condition) starts the operation defined by this particular edge triggered function block.

All inputs other than xExecute and the eventually present variable xAbort are sampled with this rising edge. Their values will be stored locally. Thus, later changes of these inputs can not influence the defined operation while it is running [1].

The input variable xExecute can be set to FALSE after the status TRUE was seen on the output variable xBusy.

A falling edge detected at the input variable xExecute will not abort the defined operation. The defined operation is running normally to its ready condition, abort condition or error condition.

Only the status TRUE detected on the eventually present input variable xAbort cancels the defined operation (abort condition).

If the eventually present input variable xAbort and the input variable xExecute have the same value TRUE the abort condition is reached immediately.

Only one of the output variables xDone, xBusy, xError or the eventually present output variable xAborted can have the status TRUE at the same time.

If a abort condition was detected, the output variable xAborted is set to TRUE after setting the output variable xBusy to FALSE.

With the falling edge of xBusy the input variable xExecute 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 xExecute input variable is already set to FALSE. In this case (reset request is TRUE) the internal state of the function block is reinitialized automatically. In the other case (xExecute is still TRUE) the function block is waiting for a falling edge of the input variable xExecute before reinitializing the function block (standard handshake).

The status of any output variables other than xDone, xBusy, xError, xAborted or eErrorID are valid only while xDone has the status TRUE [2][3].

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

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.