The processing of the network starts when a node is activated by an event. The procedure in the node is executed. After this a scanning of the network starts. The successive nodes are examined one by one in the programming order, if they are of G, L, D, E, R, or general type. The nodes of types I, A and C are skipped in the scanning. If the EL is non empty, the code is executed. When the last node in the program is scanned, the scanning continues with the first one, until the node activated at the beginning of the event is reached. If during this process a movement of messages occurred, then the scanning is repeated again. When in a cycle no message is moved, the event finishes and the next event in the FEL will be processed. This scanning makes possible to take into account the consequences that the original event produced in other nodes. Even if the original node do not move messages, the scan is necessary because it can modify restrictions that maintain certain nodes inactive. Although in most practical cases the programmer may be unaware of this process, in complicated situations may be important to consider the activation process. Some processes that would be simultaneous may fail to do so in certain cases.
Example: If in a point of time three variables must change
simultaneously, for instance X -> Z -> U and
the changes are in different nodes:
A :: Z := X + 6;
B ::
C :: X := X + 1;
D :: U := Z + 3;
E ::
then if the event starts in node C and no message is moved in the event,
the scanning will not produce the change of U due to the change of X.
This may be solved
by changing the order of the nodes or by a procedure ACT(A, 0) in
the node D. The user must decide from the nature of the problem
what chain of modification makes sense and what are the adequate
activations. Problems of this type may occur also in ordinary programming, but they are more easily avoided because the order of execution is more explicit for the programmer. Another consequence of the scanning of the network is that some instruction may be unnecessarily executed many times. This may produce waste of time or erroneous results.
Example:
Gate (G) :: IF (Class = Good) OR (LL(EL_Gate) > 3) SENDTO(Market) END;
Insp := Insp + 1;
The EL of Gate is examined and if the condition is fulfilled
the messages are sent to Market. In Insp it is supposed to
take into account the number of inspected messages. However, as
the EL may not be exhausted in one activation of the node (up to three
not Good items may remain) in a further activation in the same event
the remaining messages are inspected again given a false value of
the inspected number.
The user can avoid the effects of the repeated execution of some or all the instructions of a node using the instructions DONODE and DOEVENT (see 6.7 and 6.8). Example:
Gate (G) :: IF (Class = Good) OR (LL(EL_Gate) > 3) SENDTO(Market);
DOEVENT Insp := Insp + 1;
In this case the instruction Insp := Insp + 1 is executed
only the first time the node is activated.
The type C nodes activate themselves automatically each integration interval. For example, if a message must be sent when Level reaches or exceeds 123.0, the program
Tank (C) :: Level' := Inflow - K * Level;
IF Level = 123.0 THEN CREATE(Mess) SENDTO(Center);
may fail if Level do not reach exactly that value. If we put:
Tank (C) :: Level' := Inflow - K * Level;
IF Level >= 123.0 THEN CREATE(Mess) SENDTO(Center);
after the value is reached, a message is sent during each integration
interval. One solution may be:
Tank (C) :: Level' := Inflow - K * Level;
IF (MesNotSent and (Level > 123. 0) THEN
CREATE(Mess) BEGIN SENDTO(Control);
MesNotSent = FALSE
END;
MesNotSent is a boolean variable originally TRUE. When the condition
is fulfilled for the first time a message is sent and MesNotSent
becomes FALSE, so, no more messages are sent.