In this tutorial task, you'll learn some of the basics about building a sub flow in the Process Flow tool. A sub process flow is a separate process flow that begins running when it is triggered by another activity or event in a different process flow. Think of sub flows as chunks of self-contained logic that will get executed when they are triggered by certain events in the simulation model or general process flow.
Sub flows can cut down on the need to create a certain block of process flow activities in multiple places throughout your process flows. You could use sub flows to perform calculations or to simulate more complex procedures that are triggered by specific activities or events in the main process flow. See Process Flow Sub Flows for more information about the key concepts related to sub flows.
In this tutorial, you'll build an internal sub flow to dynamically determine a processor's processing time. When you're finished, your 3D model and process flow will look similar to the following image:
Sub flows begin when a Create Tokens or Run Sub Flow activity sends a token to a Start activity on the sub flow. The sub flow ends when it moves through all the activities in the sub flow and reaches a Finish activity.
When a Create Tokens or Run Sub Flow activity sends a token to a sub flow, it usually creates a new token. Based on your own unique model logic requirements, you will have to decide what kind of relationship this newly created token in the sub flow should have with the token that created it in the main process flow. There are three basic options:
In this tutorial task, you'll work primarily with child and parent tokens. The child token in the sub flow will need to have access to the labels on the parent token in the main process flow.
In this step, you'll build a basic 3D model. When you're finished, your 3D model should look similar to the following image:
To build this model:
Check to make sure that your model looks similar to the image shown in the beginning of this section.
In this step, you'll add activities to a general process flow to build a process flow that will change the processor's process times.
When you're finished, your process flow should look similar to the following image:
For now, you'll merely add and connect these activities to the process flow. You'll edit the properties to add the functionality in a later step.
To add and connect these activities:
|Source||Source: Start Simulation|
|Assign Labels||Assign Labels: Set to Fast|
|First Run Sub Flow||Run Sub Flow: Fast Time 1|
|Second Run Sub Flow||Run Sub Flow: Fast Time 2|
|Third Run Sub Flow||Run Sub Flow: Fast Time 3|
|Assign Labels||Assign Labels: Set to Slow|
|First Run Sub Flow||Run Sub Flow: Slow Time 1|
|Second Run Sub Flow||Run Sub Flow: Slow Time 2|
|Start||Start Sub Flow|
|Wait for Event||Wait for Event: Process Time|
|Finish||Finish and Override Process Time|
Consider saving your simulation model.
In this step, you'll edit the properties for the activities in the process flow. The following is an overview of how each activity will function:
|Source: Start Simulation||This Scheduled Source activity will create one token as soon as the simulation starts and sends the token to the Assign Labels activity. After it creates this token, it won't create any additional tokens. The one token will simply loop continuously through the other activities until the simulation ends. You'll use the default properties for this activity.|
|Assign Labels Activities||Both of the Assign Labels activities will create and set a label called
processTime that will be referenced by the sub flow as it controls the
processor's process time. The first Assign Labels activity will set the label to
|Run Sub Flow Activities||The Run Sub Flow activities will create a child token in the Start sub flow activity. The parent token will remain in the Run Sub Flow activity until the child token reaches the end of the sub flow. When the child token finishes the sub flow, the token will move to the next downstream activity.|
|Start Sub Flow||All Sub Flows need to begin with a Start activity, which receives the child token created by the Run Sub Flow activities. It then releases the child token to the next activity.|
|Wait for Event: Process Time||Wait for Event activities are event-listening activities. That means a token will wait at this activity until the event that is being listened to occurs. This activity will listen to the processor for the process time event. When the processor is ready to begin the process time, the token will get released to the Finish activity. You'll also set this activity to override the process time.|
|Finish and Override Process Time||The Finish activity will provide the processor with a process time return value. After it has provided this return value, it will destroy the child token and alert its parent token in the Run Sub Flow activity that the child token has finished the sub flow.|
To edit these properties:
2.00to represent 2 simulation time units.
10to represent 10 simulation time units.
Consider saving your simulation model.
Reset and run the model.
You'll notice that Source creates a token at time 0, then the token enters the Set to Fast Time activity and its processTime label is set to 2. The token then moves to the first Fast Time 1 activity where a child token is created and sits at the Wait for Process Time activity in the sub flow.
As soon as the processor in the model receives an item, the Wait for Event releases the token and the process time is overridden. The child token is then destroyed and the parent token moves to the next Run Sub Flow activity to start the sub flow over again. This will continue as each item enters the processor. Once the token finishes Slow Time 2, it will move back to the top to continue the pattern again.
If you were to pause the simulation and click one of the tokens in the sub flow, you'd see a blue line showing the parent-child connection between tokens:
Not only was the logic easily created without any coding, but you can also visibly see where the processor is in its set of process times. This can be a valuable debugging tool or it can be useful for collecting statistics. Statistics could be gathered separately or collectively for an activity or area to record how long the processor spent in any given state.
In the next tutorial task, you'll learn about another way to build sub flows by adding multiple finish activities. Continue on to Tutorial Task 3.2 - Add Multiple Finish Activities.