IBackgroundTask.TaskDisableWatchdog (METH) ¶ METHOD TaskDisableWatchdog : BOOL Disable watchdog for this task Note Can be called nested. First call disables the watchdog InOut: Scope Name Type Comment Return TaskDisableWatchdog BOOL TRUE => Operation successful, FALSE => Operation failed

IBackgroundTask.TaskEnableScheduling (METH) ¶ METHOD TaskEnableScheduling : BOOL Enable scheduling for this task InOut: Scope Name Type Comment Return TaskEnableScheduling BOOL TRUE => Scheduling is enabled, FALSE => Operation failed

IBackgroundTask.TaskEnableWatchdog (METH) ¶ METHOD TaskEnableWatchdog : BOOL Enable watchdog for this task Note Can be called nested. Last call enables the watchdog InOut: Scope Name Type Comment Return TaskEnableWatchdog BOOL TRUE => Operation successful, FALSE => Operation failed

IBackgroundTask.TaskResetStatistics (METH) ¶ METHOD TaskResetStatistics : BOOL Reset the task statistics of this task InOut: Scope Name Type Comment Return TaskResetStatistics BOOL TRUE => Statistic is reseted, FALSE => Operation failed

IETrigTl (ITF) ¶ INTERFACE IETrigTl EXTENDS IETrig , ITimeLimited , ITimingControlled In order to build a function block with an ETrigTl behaviour, its action provider has to be decorated with this interface. This will determine the state machine which then forces the function block to the appropriate ETrigTl behaviour. See Decorators for more information about the concept. A state chart for function blocks with ETrigTl behaviour Starting : ⇒ StartAction is running, until xComplete is TRUE , xBusy ⇒ TRUE At its beginning the SampleAction is probably executed one time. Executing : ⇒ CyclicAction is running until xComplete is TRUE Cleaning : ⇒ CleanupAction is running. At its end the ExitAction is probably executed one time. After a Ready Condition as input, only the output states Done ( xComplete is TRUE ) or Error ( eErrorID ≠ ERROR.NO_ERROR ) are possible. After a Error Condition as input, only the output state Error ( eErrorID ≠ ERROR.NO_ERROR ) is possible. Done : xDone ⇒ TRUE , xBusy ⇒ FALSE Error : xError ⇒ TRUE , eErrorID ≠ ERROR.NO_ERROR , xBusy ⇒ FALSE Resetting : ⇒ ResetAction is running, until xComplete is TRUE . After that: - the outputs xDone and xError will be set to FALSE . - The output eErrorID will be set to ERROR.NO_ERROR . Methods: StartAction , inherited from IStartActionProvider

IETrigTlTo (ITF) ¶ INTERFACE IETrigTlTo EXTENDS IETrigTl , ITimeOutConstraint In order to build a function block with an ETrigTlTo behaviour, its action provider has to be decorated with this interface. This will determine the state machine which then forces the function block to the appropriate ETrigTlTo behaviour. See Decorators for more information about the concept. A state chart for function blocks with ETrigTlTo behaviour Starting : ⇒ StartAction is running, until xComplete is TRUE , xBusy ⇒ TRUE At its beginning the SampleAction is probably executed one time. Executing : ⇒ CyclicAction is running until xComplete is TRUE Cleaning : ⇒ CleanupAction is running. At its end the ExitAction is probably executed one time. After a Ready Condition as input, only the output states Done ( xComplete is TRUE ) or Error ( eErrorID ≠ ERROR.NO_ERROR ) are possible. After a Error Condition as input, only the output state Error ( eErrorID ≠ ERROR.NO_ERROR ) is possible. Done : xDone ⇒ TRUE , xBusy ⇒ FALSE Error : xError ⇒ TRUE , eErrorID ≠ ERROR.NO_ERROR , xBusy ⇒ FALSE Resetting : ⇒ ResetAction is running, until xComplete is TRUE . After that: - the outputs xDone and xError will be set to FALSE . - The output eErrorID will be set to ERROR.NO_ERROR . Methods: StartAction , inherited from IStartActionProvider

IETrigTo (ITF) ¶ INTERFACE IETrigTo EXTENDS IETrig , ITimeOutConstraint , ITimingControlled In order to build a function block with an ETrigTo behaviour, its action provider has to be decorated with this interface. This will determine the state machine which then forces the function block to the appropriate ETrigTo behaviour. See Decorators for more information about the concept. A state chart for function blocks with ETrigTo behaviour Starting : ⇒ StartAction is running, until xComplete is TRUE , xBusy ⇒ TRUE At its beginning the SampleAction is probably executed one time. Executing : ⇒ CyclicAction is running until xComplete is TRUE Cleaning : ⇒ CleanupAction is running. At its end the ExitAction is probably executed one time. After a Ready Condition as input, only the output states Done ( xComplete is TRUE ) or Error ( eErrorID ≠ ERROR.NO_ERROR ) are possible. After a Error Condition as input, only the output state Error ( eErrorID ≠ ERROR.NO_ERROR ) is possible. Done : xDone ⇒ TRUE , xBusy ⇒ FALSE Error : xError ⇒ TRUE , eErrorID ≠ ERROR.NO_ERROR , xBusy ⇒ FALSE Resetting : ⇒ ResetAction is running, until xComplete is TRUE . After that: - the outputs xDone and xError will be set to FALSE . - The output eErrorID will be set to ERROR.NO_ERROR . Methods: StartAction , inherited from IStartActionProvider

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 [ 1 ] [ 2 ] . 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. Continuous Behaviour without xDone Interfaces ILConC (Interface) ILConTlC (Interface) LConC (FunctionBlock) IBehaviourModel AbortModel (Method) GetModelState (Method) ResetModel (Method) StartModel (Method) _Execute (Method) LConTlC (FunctionBlock) IBehaviourModel AbortModel (Method) GetModelState (Method) ModelTimeLimit (Property) ResetModel (Method) StartModel (Method) _Execute (Method) Regular Behaviour with xDone Interfaces ILCon (Interface) ILConTl (Interface) ILConTlTo (Interface) ILConTo (Interface) LCon (FunctionBlock) IBehaviourModel AbortModel (Method) GetModelState (Method) ResetModel (Method) StartModel (Method) _Execute (Method) LConTl (FunctionBlock) IBehaviourModel AbortModel (Method) GetModelState (Method) ModelTimeLimit (Property) ResetModel (Method) StartModel (Method) _Execute (Method) LConTlTo (FunctionBlock) IBehaviourModel GetModelState (Method) ModelTimeOut (Property) _Execute (Method) LConTo (FunctionBlock) IBehaviourModel AbortModel (Method) GetModelState (Method) ModelTimeOut (Property) ResetModel (Method) StartModel (Method) _Execute (Method)

ETrigTo (FB) ¶ FUNCTION_BLOCK ETrigTo EXTENDS EdgeTriggeredTimingControlledBehaviourModelBase IMPLEMENTS IETrigTo Base implementation of the PLCopen Edge Triggered Behavior Model (see: |IETrigTo|). For use, this block should be extended and the specific inputs and outputs must be supplemented. The output ``eErrorID` of the application-specific enum type ERROR must be added. InOut: Scope Name Type Comment Input xExecute BOOL Rising edge: Starts defined operation FALSE : Resets the defined operation after ready condition was reached udiTimeOut UDINT Max. operating time for executing [µs], 0: No operating time limit Output xDone BOOL Ready condition reached xBusy BOOL Operation is running xError BOOL Error condition reached Properties: ActionController , inherited from TimingControlledBehaviourModelBase ModelTimeLimit , inherited from TimingControlledBehaviourModelBase ModelTimeOut Methods: _Execute AbortModel , inherited from TimingControlledBehaviourModelBase CleanupAction , inherited from TimingControlledBehaviourModelBase CyclicAction , inherited from TimingControlledBehaviourModelBase ExitAction , inherited from TimingControlledBehaviourModelBase GetConfiguration , inherited from TimingControlledBehaviourModelBase GetConfiguration2 , inherited from TimingControlledBehaviourModelBase GetModelState ResetAction , inherited from TimingControlledBehaviourModelBase ResetModel SampleAction , inherited from EdgeTriggeredTimingControlledBehaviourModelBase StartAction , inherited from TimingControlledBehaviourModelBase StartModel Structure: IBehaviourModel GetModelState (Method) ModelTimeOut (Property) ResetModel (Method) StartModel (Method) _Execute (Method)

IBehaviourModel ¶ GetModelState (Method) ModelTimeOut (Property) ResetModel (Method) StartModel (Method)