Busy process flow resource acquired twice

Question

question

April Zwerneman asked Aug 15 2016 at 9:58 PM April Zwerneman commented Sep 08 2016 at 10:55 PM

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)

______

Cookie preferences

Your privacy is important to us and so is an optimal experience. To help us customize information and build applications, we collect data about your use of this site.

May we collect and use your data?

Learn more about the Third Party Services we use and our Privacy Statement.

Strictly necessary – required for our site to work and to provide services to you

These cookies allow us to record your preferences or login information, respond to your requests or fulfill items in your shopping cart.

YES

Improve your experience – allows us to show you what is relevant to you

These cookies enable us to provide enhanced functionality and personalization. They may be set by us or by third party providers whose services we use to deliver information and experiences tailored to you. If you do not allow these cookies, some or all of these services may not be available for you.

YES

NO

Customize your advertising – permits us to offer targeted advertising to you

These cookies collect data about you based on your activities and interests in order to show you relevant ads and to track effectiveness. By collecting this data, the ads you see will be more tailored to your interests. If you do not allow these cookies, you will experience less targeted advertising.

YES

NO

Are you sure you want a less customized experience?

We can access your data only if you select "yes" for the categories on the previous screen. This lets us tailor our marketing so that it's more relevant for you. You can change your settings at any time by visiting our privacy statement

Your experience. Your choice.

We care about your privacy. The data we collect helps us understand how you use our products, what information you might be interested in, and what we can improve to make your engagement with Autodesk more rewarding.

May we collect and use your data to tailor your experience?

Explore the benefits of a customized experience by managing your privacy settings for this site or visit our Privacy Statement to learn more about your options.

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

Brandon Peterson answered Aug 16 2016 at 6:28 PM April Zwerneman commented Sep 08 2016 at 10:55 PM

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 9: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