EC Transitions

Adding a Transition to an ECC

You can add a transition between any two states of an ECC using drag-and-drop editing in the same manner as connections in a function block diagram (FBD). The initial transition condition is unconditional ( 1 ), which may lead to a self-cycle or a guard-only cycle, so an EC Transition Dialog is opened to check for this possibility and correct the transition condition if necessary.

Deleting a Transition

You can delete a transition by using the Delete item of its popup menu.

Transition Priorities

At runtime, each ECC contains exactly one active step. Transitions out of an active step are evaluated in the order in which they are declared in the XML document, subject to the following rules:

To assist in determining the order of transition evaluation, the order in which the transition has been declared is shown in curly brackets {} preceding the transition condition.

The order in which a selected transition is declared (and hence its priority of evaluation at runtime) can be changed by using the Promote/Demote functionality of the Rosette.

The EC Transition Dialog

For editing an existing transition, you invoke this dialog by double-clicking an existing EC transition or clicking the Edit item of its popup menu. The dialog contains a drop-down list for selecting the event (if any) in the transition condition. An editable drop-down list lets you select a Boolean variable as a guard condition, or to type in a Boolean expression in the IEC 61131-3 ST (Structured Text) language as the guard condition (if any).

You can close the dialog without making any changes to the action by pressing the Cancel button or the in the upper right corner of the dialog. If you press the OK button, the requested changes (if any) will be made and the dialog will close.

The FBEditor does not detect whether the guard condition is a proper Boolean expression; this will only be caught by the compiler when the SaveAs... =>Java option is exercised.

Empty Transitions

If both the Event and Guard Condition fields are empty when you press the OK button, an error message will be displayed and the dialog will not close.

Self-Cycles

A self-cycle exists when there is a transition from an EC action back to itself. If there is no event associated with such a transition, there is a possibility that the process that is executing the ECC may enter an infinite loop (or, in the case of the FBRT runtime provided with the FBDK, cause a stack overflow).

Consider the following example, using the TEST_GUARDS FB type example, with the initial ECC shown below as a basis - note the transition priorities in curly brackets {}.

The transition dialog resulting from connecting a self-cycle at state INIT.
The self-cycle diagnosis resulting from trying to save the self-cycle (by pressing the OK button) with an unconditional transition.
The self-cycle diagnosis resulting from trying to save the self-cycle with a guard only.
A correct self-cycle, gated by an event and possibly also a guard condition.
The resulting ECC.
Note that the self-cycle is drawn with a double line.
Note also that this particular transition is irrelevant, since it is second in priority to an unconditional (1) transition.
Guard-Only Cycles

A guard-only cycle is the general case of a self-cycle, where a path exists from an EC state, through other EC states and back to itself through a path consisting of transitions with guard-only conditions (i.e., transitions not containing an event). This also poses the possibility that the process that is executing the ECC may enter an infinite loop or cause a stack overflow in the FBRT.

For instance, if an unconditional transition is attempted from the START to the ADD1 state in the TEST_GUARDS example above, the diagnostic message shown below results.