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)
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)
Interfaces ¶ ILConC (Interface) ILConTlC (Interface)
LConC (FB) ¶ FUNCTION_BLOCK LConC EXTENDS BehaviourModelBase IMPLEMENTS ILConC Base implementation of a PLCopen Level Controlled Behavior Model (see: ILConC ) 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 xEnable BOOL TRUE : Activates the defined operation FALSE : Aborts/resets the defined operation Output xBusy BOOL TRUE : Operation is running xError BOOL TRUE : Error condition reached Properties: ActionController , inherited from BehaviourModelBase ModelTimeLimit , inherited from BehaviourModelBase ModelTimeOut , inherited from BehaviourModelBase Methods: _Execute AbortModel CleanupAction , inherited from BehaviourModelBase CyclicAction , inherited from BehaviourModelBase ExitAction , inherited from BehaviourModelBase GetConfiguration , inherited from BehaviourModelBase GetConfiguration2 , inherited from BehaviourModelBase GetModelState ResetAction , inherited from BehaviourModelBase ResetModel StartAction , inherited from BehaviourModelBase StartModel Structure: IBehaviourModel AbortModel (Method) GetModelState (Method) ResetModel (Method) StartModel (Method) _Execute (Method)
IActionProvider (ITF) ¶ INTERFACE IActionProvider EXTENDS IStartActionProvider , ICyclicActionProvider , ICleanupActionProvider , IResetActionProvider Methods: StartAction , inherited from IStartActionProvider
IStartActionProvider.StartAction (METH) ¶ METHOD StartAction The StartAction is running until either the output xComplete is TRUE or iErrorID ≠ 0 (Zero). If xComplete is TRUE the state STATE.EXECUTING is reached. If there is a iErrorID ≠ 0 (Zero) the state STATE.CLEANING is reached. Note To sample the inputs in the first invocation of a function block the method SampleAction is the solution of choice. See: ISampleActionProvider.SampleAction InOut: Scope Name Type Output xComplete BOOL iErrorID INT
ICyclicActionProvider.CyclicAction (METH) ¶ METHOD CyclicAction The CyclicAction is running until either xComplete is TRUE or iErrorID ≠ 0 (Zero). If xComplete is TRUE or iErrorID ≠ 0 (Zero) the state STATE.CLEANING is reached. With itfTimingController ≠ 0 (Zero) it is possible to check the current invocation time (see: ITimingController.ControllerCheckTiming ). Function blocks with a udiTimeLimit input variable (see: IETrigTl , IETrigATl , IETrigTlTo , IETrigATlTo , ILConTl , ILConTlTo , ILConTlC ) should be implement in such a way that the current invocation is exited when the consumed time for this invocation has exceeded the settings from udiTimeLimit. Example REPEAT // working to reach the ready condition // ⇒ xComplete := TRUE // if the maximum invocation time is reached // ⇒ xTimeLimit := TRUE // if the maximum operating time is reached // ⇒ xTimeOut := TRUE // if an error condition is reached // ⇒ set iErrorID to a value other than 0 (Zero) itfTimingController.ControllerCheckTiming ( xTimeOut => xTimeOut , xTimeLimit => xTimeLimit ); xComplete := TRUE ; iErrorID := ERROR.NO_ERROR ; UNTIL xComplete OR xTimeOut OR xTimeLimit OR iErrorID <> ERROR.NO_ERROR END_REPEAT InOut: Scope Name Type Input itfTimingController ITimingController Output xComplete BOOL iErrorID INT
ICleanupActionProvider.CleanupAction (METH) ¶ METHOD CleanupAction CleanupAction is running until one of the following events occurs: When xComplete is TRUE the state STATE.DONE is reached. When xAbort is TRUE the state STATE.ABORTED is reached. When iErrorID ≠ 0 (Zero) the state STATE.ERROR is reached. After a Ready Condition as input ( iErrorIDProposed = 0 and xAbortProposed = FALSE ), only the output states DONE ( xComplete is TRUE ) or ERROR ( iErrorID ≠ 0) are possible. After a Error Condition as input ( iErrorIDProposed ≠ 0), only the output state ERROR ( iErrorID ≠ 0) is possible. After a Abort Condition as Input ( xAbortProposed = TRUE ), only the output states ABORTED ( xAbort is TRUE ) or ERROR ( iErrorID ≠ 0) are possible. Example (* common cleanup -- first steps *) IF xComplete THEN IF xAbortProposed THEN (* abort condition -- abort specific cleanup *) xAbort := TRUE ; xComplete := FALSE ; ELSIF iErrorIDProposed <> 0 THEN (* error condition -- error specific cleanup *) iErrorID := SEL ( xComplete , 0 , iErrorIDProposed ); xComplete := FALSE ; ELSE (* ready condition -- done specific cleanup*) END_IF END_IF (* common cleanup -- last steps *) InOut: Scope Name Type Input xAbortProposed BOOL iErrorIDProposed INT Output xComplete BOOL xAbort BOOL iErrorID INT
IResetActionProvider.ResetAction (METH) ¶ METHOD ResetAction The ResetAction is running until the output xComplete is TRUE . If xComplete is TRUE the state STATE.DORMANT is reached. InOut: Scope Name Type Output xComplete BOOL
BehaviourModel.StartModel (METH) ¶ METHOD StartModel : ERROR InOut: Scope Name Type Return StartModel ERROR Input xCommit BOOL