In this tutorial task, you'll learn how to use a fixed resource process flow to design the custom logic for a fixed resource. You'll add a BasicFR object to the model and attach it to a fixed resource process flow that will receive and process flow items in a batch. This tutorial will also cover common problems and pitfalls that come from designing custom fixed resources. When you're finished, your model will look similar to the following image:
BasicFR objects are a blank slate, which means that they do not have their own logic for receiving and releasing items. You will need to explicitly add this logic to the BasicFR object by creating a fixed resource process flow. You'll use the Receive Item and Release Item picklists on event-listening activities to handle this logic.
Be aware that if you were going to attach a standard fixed resource to a process flow (such as a queue or a processor), you wouldn't use the Receive Item and Release Item picklists. Instead, you would use the Close Ports and Open Port picklists. See Tutorial 2 - Task Sequences for an example of these picklists in context.
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:
Object | New Name |
---|---|
Source1 | Source |
BasicFR1 | Batch |
Operator1 | Operator |
Sink1 | Sink |
Plane | Break Room |
3.00
1.50
0.50
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 fixed resource process flow to build a custom fixed resource that will receive three flow items, process the items in a batch, and then release them to the next downstream resource. 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:
Activity | New Name |
---|---|
Source | Source: Start Simulation |
First Wait For Event | Wait for Event: Receive Item 1 |
First Delay | Delay: Process Item 1 |
Second Wait For Event | Wait for Event: Receive Item 2 |
Second Delay | Delay: Process Item 2 |
Third Wait For Event | Wait for Event: Receive Item 3 |
Third Delay | Delay: Process Item 3 |
Fourth Delay | Delay: Process All Items |
Fourth Wait For Event | Wait for Event: Release Item 1 |
Fifth Wait For Event | Wait for Event: Release Item 2 |
Sixth Wait For Event | Wait for Event: Release Item 3 |
Consider saving your simulation model.
In this step, you'll edit the properties for the activities that handle receiving items in the process flow. You'll have to first attach the Batch as an instance to the process flow. This will make it possible for you to use the current keyword to dynamically refer to the Batch. This makes it easier to scale more complex models: you can add additional BasicFR objects as attachments to the process flow without having to copy the process flow for each object.
The following is an overview of how each activity will function:
Activity | Explanation |
---|---|
Source: Start Simulation | This Scheduled Source activity will create one token as soon as the simulation starts and sends the token to the Wait for Event 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. |
Wait for Event: Receive Items | 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. In this process flow, the first three Wait for Event activities will listen to the Batch for the On Entry event. Because the Batch is a BasicFR object, you'll need to explicitly direct it to receive flow items. When the Batch receives a flow item, you'll assign a label named Item1, Item2, or Item3 that will store a reference to the flow item that triggered the event. |
Delay: Process Times | You'll add a delay of 5 seconds to represent the amount of time the batch will process each flow item. |
To edit these properties:
current (No Instance)
.Item1
.5.00
.Consider saving your simulation model.
In this step, you'll edit the properties for the activities that handle releasing items in the process flow. The following is an overview of how each activity will function:
Activity | Explanation |
---|---|
Delay: Process Times | You'll add a delay of 5 seconds to represent the amount of time the batch will process each flow item. |
Wait for Event: Release Items | The last three Wait for Event activities are the mirror image of the first three Wait for Event activities. These three activities will listen to the Batch for the On Exit event. Because the Batch is a BasicFR object, you'll need to explicitly direct it to release the flow items after they've been processed. To make sure that the Batch releases the correct item, you'll need to reference the labels named Item1, Item2, or Item3 that were created by the first three Wait for Event activities. |
To edit these properties:
10.00
.current (No Instance)
.token.Item1
.token.Item2
and
token.Item3
for step 8.Consider saving your simulation model.
You might not have realized it, but your custom fixed resources has a few problems with it at this point. Try resetting and running the model and see if you can notice what the problem is on your own. If you get stuck, the rest of this step will explain the problem.
If you're still unsure about the problem, try this:
There's really two problems occurring here. First, you can't see the boxes in the Batch. Since the process flow didn't explicitly set the location for the boxes, they get swallowed up by the Batch and can't be seen. If you could see them in the Batch, you'd also see that all three flow items would appear in the same space (the same way they do on Processor1). This has to do with the way FlexSim automatically offsets objects.
Second (and more importantly), you will notice that the Batch releases all three flow items at the same time and then jumps to the beginning of the next batch. Releasing the flow items simultaneously causes the processor to process three items at the same time, which is the wrong behavior. This behavior is caused by the way FlexSim's event handling works.
You'll learn how to solve these two problems in the next two steps.
In this step, you'll fix the problem with the flow item visuals in the Batch object. You'll fix this by adding three Change Visual activities (one for each item) to the activity blocks that control how the batch receives items. You'll use the Change Location picklist options to set the flow item offsets inside the Batch activity. When you're finished, your process flow will look similar to the following image:
One FlexScript expression you'll see in this step is the current.size.z
expression. This expression gets the Z position of the item containing the flow item (the
Batch) and puts the flow item on top of the container object so that it doesn't get
swallowed up by the object.
To change the flow item visuals relative to the Batch:
Activity | New Name |
---|---|
First Change Visual | Change Visual: Item 1 Location |
Second Change Visual | Change Visual: Item 2 Location |
Third Change Visual | Change Visual: Item 3 Location |
token.Item1
0.6
-0.8
current.size.z
token.Item2
1.5
-0.8
current.size.z
token.Item3
2.4
-0.8
current.size.z
Try running the model to see how this changes the way flow items stack up in the Batch:
As you'll recall from the step in which you tested the model, the Batch is having a problem in which it releases all the flow items to the downstream processor at the same time. This problem is caused by the way FlexSim's event handling works. What is happening is that when the Processor is ready to receive its next item, it opens its input ports, which causes the first item to exit the Batch. When the Batch's On Exit event fires, it causes the rest of the Wait for Event activities to fire as well, releasing all the items simultaneously. All of this event-listening logic occurs before the processor even knows that it has received an item and close its input port. Consequently, all the items are released and exits immediately while the processor's input port is open.
This same problem can crop up in other scenarios. Within the Process Flow tool it usually happens when a listened event is fired on a Wait For Event or Event-Triggered Source, and that is followed by one or more other activities that themselves may cause events in the model to fire, without any delays between the original triggered event and the subsequent event triggering logic. The logic happens so fast that it doesn't give the original event enough time to "breathe" and finish what it was doing. In these cases, you can fix the problem by adding a Breathe activity, which is a Delay activity set to delay for 0 seconds. This will allow the original triggering event to finish what it was doing before the token moves on.
When you're finished, your process flow will look similar to the following image:
To add these breathe activities:
Activity | New Name |
---|---|
First Delay | Breathe 1 |
Second Delay | Breathe 2 |
Third Delay | Breathe 3 |
0.00
.Try resetting and running the model. This time you should notice that the flow items leave the batch one at a time rather than all at once:
It may seem a little counter-intuitive that you need to use a Wait for Event activity to
receive and release items. You might ask yourself if it would be easier to use the
releaseitem()
command on a Custom Code activity before each Wait for Event:
Release Item activity.
The problem with this approach is that it may actually cause the item to exit before the command is even finished executing. By the time the token gets to the Wait for Event: Release Item 1 activity, item 1 will already have exited. Because the event being listened to will have already fired, the token will get stuck waiting forever.
The solution to this problem is to use the OnListenerInitialized trigger on the Wait for Event activity. This allows you to keep the logic firing in the correct order. It allows you to execute the event-listening logic first, followed by the logic that receives/releases the item.
So far, you've learned how to create the logic for a custom fixed resource in the Process Flow tool. In the next task, you'll learn how to create the logic for a custom task executer. Continue on to Tutorial Task 5.2 - Create a Custom Task Executer.