Process Flow + using groups

Question

question

G C asked May 25, '16 Adrian Haws edited Aug 17, '16

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

5 |100000

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

G C commented · May 25, 2016 at 08: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 08: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 09: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 08: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 ·

Answer 1 · 2016-05-26T17:49:46Z

LeGrand Gold answered May 26, '16 April Zwerneman commented Aug 15, '16

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

5 |100000

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

April Zwerneman commented · Aug 15, 2016 at 09:53 PM

I am having a similar problem - two tokens have both acquired 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, 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?

0 ·

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

Jordan Johnson answered May 25, '16 Matthew Gillespie commented May 26, '16

@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

5 |100000

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

Matthew Gillespie ♦♦ commented · May 26, 2016 at 07:59 PM

You could do this same approach with resources too.

0 ·

question