Process Flow + using groups

Question

question

G C asked May 25 2016 at 8:14 PM Adrian Haws edited Aug 17 2016 at 10:11 PM

Process Flow + using groups

I use process flow for all logic.

I have 3 groups and 4 operators:

GroupA= Operator1 & operator2

GroupB= Operator2 & Operator4

GroupC= Operator1-4 (all operators)

My problem is during a process that acquires an operator from GroupC. It will call an operator regardless of whether or not that operator is utilized in a GroupA or GroupB only process. This results in the operator stopping its current process to perform the most recent acquire operation BEFORE he has been released.

I'm wondering if I can use labels to simulate a utilization state and query the label number in the acquire activity...

I have tried a query in acquire activity:

WHERE isIdle == true

and adding the isIdle field in the resource activity. However this did not work; all the operators stopped being acquired at all.

Does anyone have an alternative solution for this?

Software Version:

FlexSim 16.0.1

list query acquire resource group backorder reevaluation

· 4

G C commented · May 25 2016 at 8:19 PM

(TYPO) It should be:

GroupA= Operator1 & operator2

GroupB= Operator3 & Operator4

GroupC= Operator1-4 (all operators)

0 ·

Jeff Nordgren G C commented · May 25 2016 at 8:43 PM

Can you please send us your model so that we can look at it? And can you explain why you need to have the same operators in different groups that are active at the same time? Wouldn't one group with all the operators in it be sufficient?

0 ·

G C Jeff Nordgren commented · May 25 2016 at 9:37 PM

help.fsm

The different groups are because some operators can only perform specific operations. I want to reference the group of operators that can perform the intended task. Some times the operators which can perform the task extends beyond a group of operators. For example:

Op5 & Op6 can do process16 and process22 but not process18

Op7 & Op8 can do process18 and process22 but not process16

Attached is a gutted version of my model. The logic is all within process flow and sub flow.

Let the model run for a while then slow it down enough to see what is going on in the 3d model.

Look at the operators with white and black shirts They will sometimes have 2 items with them, when they never should.

I believe this is because the groups cannot see operators, who are shared with another group, are already utilized.

As a result, the operator is called before he can finish his current process (even without being released)

Note that the same thing happens with the groups of stations (a station will get doubled up with operators even when already acquired).

I use this sub flow process without any issues on non-shared groups.

0 ·

help.fsm (57.6 KiB)

Matthew Gillespie ♦♦ G C commented · May 26 2016 at 8:24 PM

The issue you are having is due to the fact that a list (or resource using an internal list in your case) only evaluates back orders when a new entry comes on the list.

By using multiple resources you have each operator on two different lists. When you acquire an operator through the resource it only takes that entry off of one of the lists. So if you acquire Operator1 from Group A, the operator no longer shows up in the Group A list, but still appears on the Group C list. So if you have a back order waiting for Operator1 from Group C it will just keep waiting because Operator1 never gets added back on the list (the only default reevaluation event), because it was never taken off.

Jordan's solution handles this by making sure an operator is taken off both lists at the same time.

Legrand's solution handles this by adding an extra reevaluation event.

0 ·

______

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-05-26T17:49:46Z

LeGrand Gold answered May 26 2016 at 5:49 PM April Zwerneman commented Aug 15 2016 at 9:53 PM

Try adding a Back Order Reevaluation Event that listens to the operators' OnStateChange event. Do this by opening the resource activity's Advanced property pages and click on the Back Orders tab. Click on the green arrow and select Value Event. Keep the Focus Type and Event Focus as value but change the Event to "OnStateChange"*.

*There is also an "OnStateValueChange" which is slightly different but for this solution they are exactly the same and it does not matter which one you select.

· 1

Answer 2 · 2016-05-25T21:41:26Z

Jordan Johnson answered May 25 2016 at 9:41 PM Matthew Gillespie commented May 26 2016 at 7:59 PM

@G C One solution is to use three lists instead of three groups.

In the attached model, there are three lists. The list called GroupA contains Operators 1 and 2. The list called GroupB contains Operators 3 and 4. the list called GroupC contains all four operators. Note that each operator is on two lists.

To get an operator from GroupA, a token should pull from GroupA, and store the result; I used a label called "prePull". Then, the token should immediately try to pull that operator from GroupC using this query:

WHERE value == puller.prePull

This ensures that the token will try to acquire the same operator from GroupC as from GroupA. When a token is done with that operator, it should push it back to GroupC, and then to GroupA. Be sure to push the label value, rather than the token. Also be sure to use a max wait timer of 0.0, allowing the token to move along, and to keep the value on the list on early release. Use the same double push/double pull mechanism to acquire operators out of GroupB.

Acquiring an operator from GroupC is simple; just push to and pull from the GroupC list.

In the end, every token must acquire an operator from GroupC, meaning that no two tokens will acquire the same operator.

acquireoperatormodel.fsm

aqcuireoperatormodel.png (29.1 KiB)

acquireoperatormodel.fsm (24.2 KiB)

· 1

question