The state machine of a workflow node and process functions is implemented according to the ISA-S88-Standard. The states are symbolized according to the following color scheme:

 

[Terms] that are set in rectangular brackets are commands that you execute using the context menu.

Attention: Not every workflow node supports all states and transitions.

 

Reset command

The Reset command ("reset") is allowed in most states. This will lead the workflow node to the "Idle" state.

 

Important:

1. Never reset any workflow nodes that have started a function on the physical model! To do this, open the visualization and the corresponding monitor image with the process module occupied by the workflow group (you can see the address in the ToolTip when you move the mouse over the workflow group). Transfer the active function to the "Idle" state using the Cancel- or Stop- command.
2. Never reset workflow groups that have occupied a process module on the physical model and whose functions are still active! First, perform step 1 so that no function is active on the process module. You can then reset the workflow group.
3. For a better understanding: Be aware that workflow nodes and functions are not the same. Both have their own state that have nothing to do with each other!

Important workflow group states

Idle (blue/grey): 

The workflow group has not yet started or has already been processed.

 

 Starting (matt green): 

The workflow group is in a starting state (A) and is waiting for the process module to be released that it wants to connect to. Causes why the workflow group node is waiting:

• In most cases, the process module is already occupied by a different workflow and that's why the workflow group node is waiting.
• Other workflow groups waiting for the same process module types are a higher priority. The prioritization algorithm searches for all workflows whose workflow groups are also waiting and sorts them by the oldest workflow start date (when the workflow was started). The workflow group, whose workflow has the oldest start date, is the first to occupy the process module and then switches to the "Running" state. With the "Set highest Priority" context menu command, you can undermine the prioritization algorithm and force the workflow group to occupy the free process module for itself.

 

 Running (light green):

The process module was occupied by the workflow group (B). The cursor tooltip allows you to view the connected process module. Once a workflow group has become active, it starts its child elements or the starting node (white bar at the top).

 

Substate

A workflow group also has a „Sub-state“ (F). These sub-statuses can move process behavior to a different mode. This can be seen by the fact that the symbol (F) appears at the top right.

You can view your sub-state by cursor tooltip. There are the following sub-states:

• "SMBC": Break all active workflownodes and finally unload the workflow (batch breakout).
• "SMEM": Break all material receiving nodes and drive the plant empty.
• "SMDTNC": Break all material receiving nodes and transport the unfinished intermediate product to a special target and repeat the components or material-inputs.
• "SMID": Perform an intermediate emptying/removal because the maximum capacity of the machine (e.g. scales) is reached. Then work again the remaining material-inputs.
• "SMLB", "SMLBEM": This is the last batch. No new batch is to be started. The order is to be terminated. Workflow groups are put into these modes
  
  • either through user interventions e.g. dosing aborts, lack of material acknowledgements
  • or by a specially implemented logic.

A sub-state can be reset by context menu with the "Reset substate" command.

Important workflow node states

 Idle (blue/grey): 

The workflow nodes have not yet started or have already been processed. The fact that a workflow node has already been processed is recognizable by the fact that a tick is set at the top right (D). If workflow nodes are built into loops, then they can be executed several times. How many times a workflownode has been performed shows the counter at the bottom right.

 

 Starting (matt green): 

The workflow node has been started and is waiting (E) for the "running" state. He waits in the background until a certain starting condition has occurred. In this state, a notice/alarm often appears as a warning triangle at the top right.

 

Running (light green):

The workflow node has been successfully started and is running (C).

Depending on workflow class implmentation, workflow nodes work in different ways:

• Delegating: As mentioned before, workflow groups occupies a suitable process module. A process module is the representation of a physically existing part of the system. This part of the system provides functions (e.g. dosing, emptying, mixing...) that are ultimately performed in the PLC. A workflow node that functions in a delegating way virtually delegates its task to the physical model and starts a function. That's why there is the "Method" tab in the control dialog. Here are the parameters that are transmitted to the PLC at the start. After a "Method"-call has been made by workflow nodes, a workflow node does nothing more and waits for the process function to be processed. If an alarm occurs during this waiting period (as long as the process function is running), the workflow node remains green. The process function, on the other hand, displays the alarm in the visualization or  monitor visualizaion images.
• Stand-Alone: The workflow node does not have to call up functions on the physical model, but handles the task independently (e.g. waiting times, ANDgates, OR gates). Here the "Methods" tab is hidden and only "configuration" parameters can be entered. Configuration parameters therefore refer only to the workflow node itself. Therefore, delegating workflow nodes also have configuration parameters, because this can influence the behavior of his logic before it makes the method call on the process module.

For more information, see the Physical Model chapter.

Workflow's are processed according to the event-oriented programming paradigm. This means that workflow nodes notify other workflow nodes when a particular state occurs. In order for one workflow node to notify another, it needs so-called "event points". Event points can be "Event Receiver" ("Entry-Point") (A) or "Event sender" ("Exit-Point") (B). Both are connected to each other in the workflow designer via connecting lines called workflow edges:

 

Event sender located below the workflow node send the "finished/end" event. Event sender, that are located at the side sends the Running-Event (C). These events are forwarded to the event receiver (A) via the workflow edges. If event receivers receive signals via multiple workflow edges, they will be treated "AND." This means that each signal must have come once before starting a workflow node. After an event receiver starts the workflow node, it resets all of its receiving counters so that in the event of a loop, all signals must be sent again before it can be restarted. If you want a workflow node to start when only one of the signals has arrived, then you have to put an OR gate in front of it (see the picture above).

These signals can also be triggered manually via context menu to start certain workflow nodes or disable workflow groups.

There are the following commands:

• "Raise output event": The „Event-Sender“ (B) sends his signal.
• "Raise running event": This sends the Running Event (C).
• "Reset input events": This resets the counter of reveceived events on a Entry-Point  (A).

Workflow nodes can also be started without the reception events via context menu ("Start"-command). They can also be reset by "Reset" command.

 

Unload workflows

Workflows automatically unload when the last end node has received its receiving events.

If you want to unload a workflow early, you need to make sure that

1.  all workflow nodes are idle  and

2. all workflow groups do not occupy a process module (also idle).

Then go to the last workflow groups whose output events are associated with the end node of the workflow. There, please raise the output events. After that, the workflow unloads.

If you want a workflow node not to start even though it had received all its input events, then you can use the context menu to execute the "set breakpoint" command.

The "STOP" icon appears on the workflow node:

"Brekapoint is set".

 Conversely, you can remove the breakpoint again with the "Remove breakpoint" command.