question

April Zwerneman avatar image
3 Likes"
April Zwerneman asked April Zwerneman commented

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?

FlexSim 16.0.0
process flowgroupsresources
· 3
5 |100000
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Sam Stubbs avatar image Sam Stubbs ♦ commented ·

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 Likes 3 ·
Sam Stubbs avatar image Sam Stubbs ♦ commented ·

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 Like 1 ·
April Zwerneman avatar image April Zwerneman commented ·

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 Likes 0 ·
help-sample.fsm (23.6 KiB)

1 Answer

Brandon Peterson avatar image
3 Likes"
Brandon Peterson answered April Zwerneman commented

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
5 |100000
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Matthew Gillespie avatar image Matthew Gillespie ♦♦ commented ·

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 Likes 3 ·
multigrouplist.fsm (24.5 KiB)
listgroup.png (7.2 KiB)
April Zwerneman avatar image April Zwerneman Matthew Gillespie ♦♦ commented ·

@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 Likes 0 ·
Matthew Gillespie avatar image Matthew Gillespie ♦♦ April Zwerneman commented ·

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 Likes 4 ·
Show more comments
April Zwerneman avatar image April Zwerneman Matthew Gillespie ♦♦ commented ·

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 Likes 0 ·
multigrouplist-label-issue.fsm (23.3 KiB)