Busy process flow resource acquired twice

Question

question

April Zwerneman asked Aug 15, '16 April Zwerneman commented Sep 8, '16

Busy process flow resource acquired twice

My question is similar to this one: https://answers.flexsim.com/questions/21559/process-flow-using-groups.html

I have two tokens that are both acquiring the same resource, 1 via GroupA and 1 via GroupC. The two task sequences are not performed at the same time, but I'm not sure why it is okay that they have both acquired it at the same time. I would prefer the second token to keep its resource label empty in case another resource in GroupC becomes available.

I tried adding a back order reevaluation event, as suggested in the post above, but nothing changed. Perhaps this is because the resource was acquired after the operator's status changed to busy? Why is it allowed to acquire a busy operator at all?

Software Version:

FlexSim 16.0.0

process flow groups resources

· 3

Sam Stubbs ♦ commented · Aug 15, 2016 at 10:06 PM

Is it possible to see your model? Then we could take a look and see exactly what's going on in the logic. (If your model has private information, you can post it in a private question here in answers.)

3 ·

Sam Stubbs ♦ commented · Aug 15, 2016 at 10:12 PM

As a side note, the operator's status has nothing to do with whether it is being "acquired" or not. A token only looks to see if another token has acquired the Resource, and based on the number of available resources that can be acquired. When a token acquire's a resource it is simply getting a reference to that object.

1 ·

April Zwerneman commented · Aug 15, 2016 at 10:24 PM

Sam - here is an example of the problem I'm having. I think it's different than your side note, as both tokens (Job B & Job C) have acquired Operator3.

Operator5 becomes available at time=40, but because Job C already has Operator3 on its resource label, it cannot start until time=51 (when Operator3 finishes Job B).

help-sample.fsm

0 ·

help-sample.fsm (23.6 KiB)

Answer 1 · 2016-08-16T18:28:25Z

Brandon Peterson answered Aug 16, '16 April Zwerneman commented Sep 8, '16

April,

The problems that you are having are a result of how the resource blocks work / manage resources. Basically the resource block is managing the resources very similarly to how a list works. You can think of acquiring as being equivalent to pulling the resource from the list and releasing as being equivalent to pushing the resource back to the list.

Lists do not manage an object/token/resource/etc. in any capacity more than informing it that it has been pulled or that its request has been filled. This means that lists act independently from one another and pulling or pushing a token from a list does not have any affect on any other lists that the token may be associated with. Similarly, resource blocks act independently from one another and acquiring or releasing an object from one will not affect the others. This is where your are running into problems.

In your model you have placed operators (via groups) into multiple resource blocks. Because the resource blocks act independently from one another tokens are able to acquire the same operator from different resource blocks at the same time.

There will be many different ways to get around this problem. As your model gets more complicated you may find it advantageous to represent the operators in the model with tokens that have their own process flow path. This will allow you to have the operators choose which task they do next as opposed to having the token/task choose for the operator.

Good Luck,

Brandon

· 5

Matthew Gillespie ♦♦ commented · Aug 15, 2016 at 10:30 PM

April,

Here is one way to get around this issue. It uses a list with fields that define the groups. That way each operator is only on the list once and is taken off as soon as any of the groups want to use that operator.

This example model shows this concept.

3 ·

multigrouplist.fsm (24.5 KiB)

listgroup.png (7.2 KiB)

April Zwerneman Matthew Gillespie ♦♦ commented · Aug 16, 2016 at 09:56 PM

@Matthew Gillespie - this works, thanks! One question: Can you explain why you check "Use Max Wait Timer" on the Push to List activity? I looked this up in the user manual, but it didn't make sense.

0 ·

Matthew Gillespie ♦♦ April Zwerneman commented · Aug 16, 2016 at 10:06 PM

By default the token will wait at the Push to List until something pulls the thing you pushed. Since I was pushing the operator on the list and not the token, I didn't want the token waiting around until someone pulled the operator. I used the Max Wait Timer to override that default waiting behavior. That way the token could push the operator back on the list (basically release the resource) and continue on its way.

4 ·

Show more comments

April Zwerneman Matthew Gillespie ♦♦ commented · Sep 08, 2016 at 10:55 PM

One more question about task executor lists...

We noticed in our model that when you pull more than one operator, then push them both back in the same activity, the second one's labels get changed to match the first one's labels. I would think labels are set, unless you specifically go in and change it. Is this supposed to happen? I changed your example a little to demonstrate this. If you run it for awhile, all the "groupB" tokens start piling up because the labels eventually get changed so that there are no longer enough groupB techs to satisfy the pull requirement.

multigrouplist-label-issue.fsm

0 ·

multigrouplist-label-issue.fsm (23.3 KiB)

question