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. |
|
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.
|
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.
|
|
|
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/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 ( 1 )
transition.
|
A guard-only
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.
|