Multiple Dispatchers for Set of Resources

Question

question

Tony Nikolov asked Jun 27, '16 Adrian Haws commented Aug 8, '16

Multiple Dispatchers for Set of Resources

I am making a simulation where there are three sets of processors that can are connected to sets of dispatchers controlling multiple operators. To put it clearly, there are 5 sets of processors: Set 1 with 3 machines, Set 2 with 10 machines, Set 3 with 1 machine, Set 4 with 1 machine, and Set 5 with 1 machine. In addition, There are 3 dispatchers: Dispatcher 1 controls 4 Operators who can work on Set 1 and Set 2, Dispatcher 2 controls 1 Operator who can work on Set 2, Set 3, and Set 4, and Dispatcher 3 controls 1 Operator who can work on Set 2, Set 3, Set 4, and Set 5. In addition, there are a centralized queue for every processor Set where the operator must carry the flowitem to the desired processor station.

The problem I am having is getting these operators to work together in unison such that Dispatcher 1, 2, and 3 can seamlessly operate Set 2 while Dispatcher 2 and 3 can operate Set 3 and 4 together. I tried using the Multiple teams logic on the processor but none of the operators would do anything when I implemented that. Is this something I would need manual flow sequence for? If so, I'm unsure of how to create that, so any help would be appreciated. Thanks.

operators dispatchers

· 12

Adrian Haws commented · Jun 27, 2016 at 03:03 PM

@Tony Nikolov would you be able to attach a model that shows your setup?

0 ·

Tony Nikolov Adrian Haws commented · Jun 27, 2016 at 06:22 PM

Hi Adrian,

I've attached the file. The piece in question is the Gearless TWs, the HSTWs, the Gearless Shielders, the HSTW Shielders, and the COD. The 3 Dispatchers in question are the HSTW and Gearless Dispatcher (4 operators), the HSTW COD Shielders Dispatcher(1 operator), and the HSTW and Shielders Dispatcher (1 operator). All of the operators are orange and they congregate at the sink and have different shifts that they operate on.

pgore-projectsacs-tapewrap-simulation-projectacs-t.fsm

0 ·

pgore-projectsacs-tapewrap-simulation-projectacs-t.fsm (156.1 KiB)

Adrian Haws Tony Nikolov commented · Jun 27, 2016 at 07:21 PM

Were you able to take a look at Sam and Jordan's answers to see if they'll fix the issue?

0 ·

Show more comments

Answer 1 · 2016-06-27T17:37:35Z

Jordan Johnson answered Jun 27, '16 Adrian Haws commented Aug 8, '16

My solution is based on the Task Sequences tutorial for Process Flow. If you haven't done that tutorial yet, I would recommend it to get a good idea of the method I used. This method hijacks the Use Transport option on the processor, and wires in your own process flow.

Here is the 3D model I made based on your description:

I colored each set of processors a different color, and each team of operators a different color. I named the dispatchers Team 1, Team 2, and Team 3.

Here is the Sub Flow I made to solve the problem:

For each 3D processor, I set the process time to zero; the Sub Flow handles the process time. Then, like the tutorial, I configured the Use Transport option to use a Sub Flow (which used the Per Instance option):

Notice that the Dispatch object is current, unlike the tutorial, which uses centerobject(current, 1). This means the keyword current will refer to the calling processor. Also notice that I store the item that needs transport, the set that the processor is in, and the destination of the item as labels on the token.

Then, I created a global list for all the operators. I added a field to the list that stores which dispatcher the operators belong to, using connections:

This helps with using list queries later on. Then, I added each operator to the list as initial content (which you can do from the general tab).

Now we move to the Sub Flow, which I named Operator Flow. The first Decide activity uses the "set" label to determine which route to go down. Each "Get Dispatchers" activity creates a label called "dispatchers", which is an array of all the dispatchers that could be used by that set. For example, set 3 can use operators from Dispatchers 2 and 3:

Once the set of possible dispatchers is assigned, we can pull from the list with a query:

This pull from list can be read as follows: Get a single operator whose dispatcher is in the label array of dispatchers. Put that operator on my operator label. The token waits until it can get the right kind of operator.

The remainder of the flow is simple: wait for some amount of time, move the object off the processor, and put the operator back on the list.

I attached the model so you can see how it works.

multiprocessorset.png (102.6 KiB)

multiprocessorsetflow.png (30.2 KiB)

multiprocessorsetprocessorconfig.png (22.1 KiB)

multiprocessorsetlistconfig.png (10.2 KiB)

multiprocessorsetassignconfig.png (33.3 KiB)

multiprocessorsetpullconfig.png (17.4 KiB)

multidispatchermultiprocessor.fsm (31.3 KiB)

· 4

Ramesh Yadav commented · Aug 07, 2016 at 05:52 PM

Why the given model is not opening in Flexsim 7.5.4.

0 ·

jing.c Ramesh Yadav commented · Aug 08, 2016 at 01:13 AM

The model aboved was built by FlexSim2016, and they also used ProcessFlow Module which was first introduced in FlexSim7.7

0 ·

Ramesh Yadav Ramesh Yadav commented · Aug 08, 2016 at 05:34 AM

I have licensed flexsim 7.5.4, is it possible for me to upgrade it to flexsim 2016?

Thanks for help!

0 ·

Adrian Haws Ramesh Yadav commented · Aug 08, 2016 at 03:27 PM

@Ramesh Yadav You can contact your local distributor, Commercial Consultancy Services, for information on licensing. See contact information here.

0 ·

Answer 2 · 2016-06-27T16:19:38Z

Sam Stubbs answered Jun 27, '16 Sam Stubbs edited Jun 27, '16

I don't know if this answers your question but it might be easier to think of the Operators/Dispatchers in terms of who can do what. You can have an Operator be assigned to multiple Dispatchers, and you can even have a Dispatcher assigned to another Dispatcher, etc.

So maybe do something like this: Create your three groups of Operators. (You can assign them to groups and change the colors of them etc for monitoring purposes.) But then set up your dispatchers in 5 groups: WhoCanWorkOnSet1 (and assign all of group 1's operators), WhoCanWorkOnSet2 (assign group 1 and group 2 operators), WhoCanWorkOnSet3 (assign group 2 and group 3 operators), etc etc. Then the processors are only caring about which operator is allowed to work on them.

Does that make sense?

question