TimingController.CurrentControllerTime (PROP) ¶ PROPERTY CurrentControllerTime : UDINT

TimingController.StartInvocationTimer (METH) ¶ METHOD StartInvocationTimer

TimingController.StartOperationTimer (METH) ¶ METHOD StartOperationTimer

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 ). See the detailed descriptions of the reference implementation for the different edge triggered function blocks: ETrig (FB) | ETrigTl (FB) | ETrigTo (FB) | ETrigTlTo (FB) | ETrigA (FB) | ETrigATl (FB) | ETrigATo (FB) | ETrigATo (FB) | ETrigATlTo (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 input variables which can influence the internal work flow. In this case, the special behaviour of these variables should be clearly documented. [ 2 ] 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. [ 3 ] 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. ETrig (FunctionBlock) IBehaviourModel GetModelState (Method) ResetModel (Method) StartModel (Method) _Execute (Method) ETrigA (FunctionBlock) IBehaviourModel AbortModel (Method) GetModelState (Method) ResetModel (Method) _Execute (Method) ETrigATl (FunctionBlock) IBehaviourModel AbortModel (Method) GetModelState (Method) ModelTimeLimit (Property) ResetModel (Method) StartModel (Method) _Execute (Method) ETrigATlTo (FunctionBlock) IBehaviourModel GetModelState (Method) ModelTimeOut (Property) _Execute (Method) ETrigATo (FunctionBlock) IBehaviourModel AbortModel (Method) GetModelState (Method) ModelTimeOut (Property) ResetModel (Method) StartModel (Method) _Execute (Method) ETrigTl (FunctionBlock) IBehaviourModel GetModelState (Method) ModelTimeLimit (Property) ResetModel (Method) StartModel (Method) _Execute (Method) ETrigTlTo (FunctionBlock) IBehaviourModel GetModelState (Method) ModelTimeOut (Property) _Execute (Method) ETrigTo (FunctionBlock) IBehaviourModel GetModelState (Method) ModelTimeOut (Property) ResetModel (Method) StartModel (Method) _Execute (Method) Interfaces IETrig (Interface) IETrigA (Interface) IETrigATl (Interface) IETrigATlTo (Interface) IETrigATo (Interface) IETrigTl (Interface) IETrigTlTo (Interface) IETrigTo (Interface)

Interfaces ¶ There are four types of interfaces in this library. There is the IActionProvider , the IActionController , the IBehaviourModel and the ITimingController . Each one has a different function. The IActionProvider carries its behaviour to the state machine. By using the IActionController certain actions can be set up between the action provider and the state machine. The ITimingController is used whenever the time has to be controlled, for example in order to set a specific time limit. The function block BehaviourModel implements the interface IBehaviourModel . This interface provides all methods and properties which are necessary for controlling a BehaviourModel instance via interface reference variables. IActionController (Interface) ControlCleanupAction (Method) ControlCyclicAction (Method) ControlExitAction (Method) ControlResetAction (Method) ControlStartAction (Method) IActionController2 (Interface) ControlSampleAction (Method) IActionProvider IActionProvider (Interface) ICleanupActionProvider (Interface) CleanupAction (Method) ICyclicActionProvider (Interface) CyclicAction (Method) IExitActionProvider (Interface) ExitAction (Method) IResetActionProvider (Interface) ResetAction (Method) ISampleActionProvider (Interface) SampleAction (Method) IStartActionProvider (Interface) StartAction (Method) IBehaviourModel (Folder) AbortModel (Method) ActionController (Property) GetModelState (Method) ModelTimeLimit (Property) ModelTimeOut (Property) ResetModel (Method) StartModel (Method) IConfigurationProvider (Interface) GetConfiguration (Method) IConfigurationProvider2 (Interface) GetConfiguration2 (Method) ITimingController (Interface) ControllerCheckTiming (Method) ControllerTimeLimit (Property) ControllerTimeOut (Property) CurrentControllerTime (Property) StartInvocationTimer (Method) StartOperationTimer (Method)

IActionController (ITF) ¶ INTERFACE IActionController EXTENDS __SYSTEM.IQueryInterface The behaviour of an action provider can mostly be influenced by an action controller. An action controller implements the IActionController interface and can be connected to a BehaviourModel instance via the ActionController property of the IBehaviourModel interface. If an action controller is connected to a BehaviourModel instance, the state machine will call the methods of the action controller instead of the methods of the action provider. The methods of the action controller will be called from the state machine parameterized with the related action provider method. So the action controller can encapsulate the original methods of the action controller and so create some specific modifications of their behaviour. The exemplary implementation of the method ControlCleanupAction of an ActionController function block instance 1 METHOD ControlCleanupAction 2 VAR_INPUT 3 itfCleanupActionProvider : ICleanupActionProvider ; 4 xAbortProposed : BOOL ; 5 iErrorIDProposed : INT ; 6 END_VAR 7 VAR_OUTPUT 8 xComplete : BOOL ; 9 xAbort : BOOL ; 10 iErrorID : INT ; 11 END_VAR 12 13 (* Do some specific action before calling the original CleanupAction *) 14 15 itfCleanupActionProvider.CleanupAction ( 16 xAbortProposed := xAbortProposed , 17 iErrorIDProposed := iErrorIDProposed , 18 xComplete => xComplete , // signal ready contition 19 xAbort => xAbort , // signal abort condition 20 iErrorID => iErrorID // signal error condition 21 ); 22 23 (* Do some specific action after calling the original CleanupAction *) Methods: ControlCleanupAction ControlCyclicAction ControlExitAction ControlResetAction ControlStartAction Structure: ControlCleanupAction (Method) ControlCyclicAction (Method) ControlExitAction (Method) ControlResetAction (Method) ControlStartAction (Method)

IActionController2 (ITF) ¶ INTERFACE IActionController2 EXTENDS IActionController Methods: ControlSampleAction ControlCleanupAction , inherited from IActionController ControlCyclicAction , inherited from IActionController ControlExitAction , inherited from IActionController ControlResetAction , inherited from IActionController ControlStartAction , inherited from IActionController Structure: ControlSampleAction (Method)

IActionProvider ¶ It is the task of the IActionProvider to transfer its behaviour to the state machine. The different types of action providers are listed below. Each type has its own function. IActionProvider (Interface) ICleanupActionProvider (Interface) CleanupAction (Method) ICyclicActionProvider (Interface) CyclicAction (Method) IExitActionProvider (Interface) ExitAction (Method) IResetActionProvider (Interface) ResetAction (Method) ISampleActionProvider (Interface) SampleAction (Method) IStartActionProvider (Interface) StartAction (Method)

IBehaviourModel (ITF) ¶ INTERFACE IBehaviourModel EXTENDS __SYSTEM.IQueryInterface Implemented by the function block BehaviourModel . This interface provides all methods and properties which are necessary for controlling a BehaviourModel instance via interface reference variables. When operating via an interface reference variable it should be possible to decide exactly when the state machine is called. For this the methods StartModel , AbortModel , ResetModel and GetModelState has a parameter xCommit . Calling one of these methods with the value xCommit:=FALSE will only prepare the state changes and will not trigger the state machine to execute the related actions for changing the state. Calling one of these methods with the value xCommit:=TRUE will prepare the state changes and will then trigger the state machine to execute the necessary action to reach the next stable state. It is important to know, that the state machine sometimes needs more than one invocation to transit from on state to the next stable state. With this in mind the following code example might be useful for handling a common behaviour model via an interface reference variable. A code example for handling a common behaviour model via an interface reference variable 1 VAR 2 itfBehaviourModel : CBML.IBehaviourModel ; 3 eState : CBML.STATE ; 4 /// Some variable to trigger the abort of the behaviour model 5 xSignal : BOOL ; 6 END_VAR 7 8 CASE eState OF 9 CBML.STATE.DORMANT : 10 (* Prepare execting *) 11 itfBehaviourModel.StartModel ( xCommit := FALSE ); 12 13 CBML.STATE.DONE : 14 (* Handle the ``Done`` state *) 15 itfBehaviourModel.ResetModel ( xCommit := FALSE ); 16 17 CBML.STATE.ABORTED : 18 (* Handle the ``Aborted`` state *) 19 itfBehaviourModel.ResetModel ( xCommit := FALSE ); 20 21 CBML.STATE.ERROR : 22 (* Handle the ``Error`` state *) 23 itfBehaviourModel.ResetModel ( xCommit := FALSE ); 24 END_CASE 25 26 IF xSignal AND 27 eState = CBML.STATE.STARTING OR 28 eState = CBML.STATE.EXECUTING 29 THEN 30 itfBehaviourModel.AbortModel ( xCommit := FALSE ); 31 END_IF 32 33 itfBehaviourModel.GetModelState ( xCommit := TRUE , eState => eState ); There is a very important aspect of this code example: The state machine should definitely be called/triggered only once in a PLC cycle! Properties: ActionController ModelTimeLimit ModelTimeOut Methods: AbortModel GetModelState ResetModel StartModel Structure: AbortModel (Method) ActionController (Property) GetModelState (Method) ModelTimeLimit (Property) ModelTimeOut (Property) ResetModel (Method) StartModel (Method)

IConfigurationProvider (ITF) ¶ INTERFACE IConfigurationProvider EXTENDS __SYSTEM.IQueryInterface Allows to identify the current configuration of an action provider Methods: GetConfiguration Structure: GetConfiguration (Method)