Behaviour Model¶

The two basic types of function blocks in the Common Behaviour Model library are the Edge Triggered function blocks and the Level Controlled function blocks. They are defined by their different inputs: Edge Triggered function blocks have a xExecute input whereas Level Controlled function blocks have a xEnable input.

Please take a look to a more detailed description of

• Edge Triggered Function Blocks

• Level Controlled Function Blocks

The CODESYS Common Behaviour Model Library provides a full-fledged implementation of the PLCopen Behaviour Model. The function block BehaviourModel implements in a central place all the Requirements of a behaviour model. One main part of the behaviour model is the implementation of a state machine according to the following state chart.

The state chart implemented by the BehaviourModel function block

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.

After a Abort Condition as Input, only the output states

Aborted (xAbort is TRUE) or Error (eErrorID ≠ ERROR.NO_ERROR) are possible.

(xBusy is still TRUE!)

Done:

xDone ⇒ TRUE, xBusy ⇒ FALSE

Error:

xError ⇒ TRUE, eErrorID ≠ ERROR.NO_ERROR, xBusy ⇒ FALSE

Aborted:

xAborted ⇒ TRUE, xBusy ⇒ FALSE

Resetting:

⇒ ResetAction is running, until xComplete is TRUE.

After that:

- the outputs xDone, xError and xAborted will be set to FALSE.

- The output eErrorID will be set to ERROR.NO_ERROR.

A BehaviourModel instance has among others an input variable itfActionProvider of the type IActionProvider. An action provider implements the operations that shall be executed in the related states of the state machine. The decoration of an action provider determines the behaviour of the state machine. If an action provider for example should follow the requirements for an LConC behaviour it should be decorated with the ILevelControlled and the IHasContinuousBehaviour decorator. The state machine of the behaviour model forces the action provider then to an appropriate behavior. In the example it is only possible to transit form the state Executing over Cleaning to the states Error or Resetting. The states Done and Aborted are inaccessible. In fact a concrete decoration of the action provider will transform the original state chart to a specialized state chart, which fulfills the specific requirements.

A specialized state chart, “transformed” by the decorators ILevelControlled and IHasContinuousBehaviour ⇒ LConC

To simplify the programming, there is the appropriate definition for each behavioral model. See the definition of the following interfaces:

ILCon, ILConTl, ILConTo, ILConTlTo, ILConC, ILConTlC, IETrig, IETrigTo, IETrigTlTo, IETrigA, IETrigATl, IETrigATo, IETrigATo, IETrigATlTo

Furthermore the function block BehaviourModel implements the interfaces IBehaviourModel These 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 code example at IBehaviourModel might be useful for handling a common behaviour model via an interface reference variable.