Flow item acquiring a resource that begins on downtime

Question

question

Eva R2 asked Jun 25, '21 Felix Möhlmann commented Jul 1, '21

Flow item acquiring a resource that begins on downtime

Hi. I have a 3d model and process flow that are linked. At arrival time 0, a source produces about 30 items of about 8 different types. The flow items are "separated" through decision nodes and acquire a specific operator based on their type and the operator's capabilities. I have operators on two different shifts (using time tables) that have similar labels based off of their capabilities. Everything is working surprisingly well except for the issue that follows.

At the beginning of the model (start time 0), there are 10 items of "type 1". Some of the type 1 flow items are able to acquire operators working in the first shift (starting at time 0), however, there are a few flow items that acquired operators that are on downtime, so they wont be picked up until the second shift starts. I want the flow items to acquire the operator that is not currently on downtime. Any thoughts?

Software Version:

FlexSim 19.0.9

labels time table downtime acquiring resources conditional acquire

· 2

Joerg Vogel commented · Jun 26, 2021 at 10:37 AM

Yes, if you acquire you resources by process flow activity then setup a query clause that allows only available operators to be chosen.

0 ·

Eva R2 Joerg Vogel commented · Jun 28, 2021 at 11:41 AM

How would I do that? What would the syntax be to only acquire operators that are not on downtime?

0 ·

Answer 1 · 2021-06-29T07:31:45Z

Felix Möhlmann answered Jun 29, '21 Felix Möhlmann commented Jul 1, '21

Hi @Eva R2,

the way I would do that, is to define a lable one the operators that signifies whether they are currently on downtime or not. You can then use this label to query for available operators in the "Acquire Resource" activity. The label can be set/reset in the "On Down" and "On Resume" triggers on the "Functions" tab of the time table parameters.

I'm attaching a sample model that demonstrates this.

OnlyAcquireActive.fsm

OnlyAcquireActive_FS2019.fsm

Note: The tokens wait for a new resource to become available or one of the time tables to resume in a "Wait for Event" activity if they couldn't acquire an operator, because otherwise they won't try to acquire an operator if the label changes.

Note2: I also added some logic to re-run tokens through the process flow when their acquired operator becomes inactive. For that, in addition to setting the "Down" label, I also send a message to the operators in the "On Down" trigger of the time tables. A child token listens to this message and moves its parent back to the beginning of the main flow.

If you have any questions feel free to comment.

Edit: Added 19.0 version of the model.

onlyacquireactive.fsm (145.5 KiB)

onlyacquireactive-fs2019.fsm (141.3 KiB)

· 6

Eva R2 commented · Jun 30, 2021 at 01:40 PM

Hi - thank you so much for your input. I understand what you are saying in note 1, however I am getting lost in the logic you presented with note 2. In your process flow, in the activity "Release Token" is the parent token being released back to the start activity before acquiring it? I don't have much practice using the custom code activities so I am also getting lost in your "Release Abort Token" and how that communicates with the "Wait for Event" . Again, thank you so much - I at least have a starting point to add these functionalities into my own model.

0 ·

Felix Möhlmann Eva R2 commented · Jun 30, 2021 at 03:11 PM

The child token ("Abort Token") I create is waiting for a message to be send to the worker that was acquired by the parent. This message can come from two sources.

The first is the "Release Abort Token" activity. This is configured (through a picklist option) to send a message to "token.resource" (the worker). A message can contain up to three parameters, which in this case are left "blank" (values of zero).

The second source are the timetables. In the "On Down" trigger I added the line

sendmessage(curmember, curmember, "Down");

within the loop, so a message with the first parameter set as "Down" is send to all objects connected to that time table. The rest of the code is generated automatically by choosing the "Set Label (group)" options.

Now, when the "Abort Token" registers a message to the worker, it saves the first parameter to the label "msgparam1" (set in the Wait for Event activity). In the "Decide" activity it then checks whether this parameter is "Down" or not. If that is the case, the token indeed releases its parent token to the "Start" beneath the "Resource" where it will release the previously acquired worker and reenter the main flow at the "Acquire" activity to find a new, active worker.

I hope this explains what is happening better.

0 ·

Eva R2 Felix Möhlmann commented · Jun 30, 2021 at 05:24 PM

Yes, that definitely helps - thank you! In my own model, I would like the operator to wait at the processor while it completes processing the item. I am doing this currently by adding a "wait for event" after the unload activity. However, if there's a shift change (on the operator) while the processor is in the middle of processing an item - it continues to do so without any operator. Is there someway I could apply what you are saying above to get the processor to stop and acquire an on shift operator to continue on? Hope this makes sense, thank you for all of your help!

0 ·

Show more comments

question