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:
To assist in determining the order of transition evaluation, the order in which the transition has been declared is shown in curly brackets
The order in which a selected transition is declared (and hence its priority of evaluation at runtime) can be changed by using the Up/Down buttons on the menu bar.
|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).|
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.
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/TEST_GUARDS.fbt file with the initial ECC shown at right 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 (
cycle is the general case of a self-cycle, where a
path exists from an EC start, 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 at right results.