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.

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

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:

• Upon the occurrence of an input event, only those transitions out of the active step that are associated with the event will be evaluated.
• Upon completion of the actions associated with the active step, those transitions out of the step that are not associated with an event will be evaluated.

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.

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.

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.

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.

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.