Dispatcher with 8 operators – only 4 are working, and nearest Source assignment issue

[tugba_aslanturk]

Hi everyone,

I have a model where 2 different Sources are feeding into the same Queues. There are 8 operators responsible for transporting boxes, and I connected them to a Dispatcher.

Problem 1: Only 4 operators are actually working, while the other 4 remain idle. I would like all 8 to be active.

Problem 2: After delivering a box, I want each operator to return to the nearest Source (based on distance). Currently, boxes are generated from Sources with random percentage distribution, but operators don’t automatically go to the closest Source after their task.

How can I fix both issues? Any suggestions would be appreciated.

[kavika_faleumu]

Hey @tugba_aslanturk, maybe I can help here.

1. The Dispatcher's default setting is to pick the "first available" operator. That means, it goes down the list of Operators in the "Output Ports" and picks the first one that is available. That means the ones at the top will be used (regardless of distance) before the idle ones.

You can fix this by changing the Dispatcher's "Pass To" property to something like "Shortest Distance" or "Shortest Distance if Available". This will have the Dispatcher pick whichever operator is closest and give them the task.

2. If you want Operators to go back to its nearest Source, you'll probably need to implement some Process Flow. One approach is to put the Sources on a Global List and query whichever one is closest.

First, I put all the Operators in a group so I could create a token whenever one of them has finished an "Unload Task". I initiate a Global List of Fixed Resources with the 2 Sources in it.

One of the default fields is a "distance" field that calculates the distance from an item in the list to whoever pulled from the list.

Using this, we can pull a Source and have the Operator travel to it.

Attached is the example model. Hope this helps!

[tugba_aslanturk]

Thanks a lot for the detailed explanation! Changing the Dispatcher's Pass To setting helped clarify why only some of the Operators were being used.

What I would also like to achieve is to have all Operators work simultaneously with minimal idle time. Right now, they spend too much time waiting.

I tried setting the interarrival time with an Arrival Schedule so that at time zero 1000 products are created. But in that case, all Operators only pull from Source1, while Source2 is left unused.

How can I balance the product flow so that all 8 Operators stay busy and pick up from both Sources instead of only one?

[joerg_vogel_HsH]

Creating 1000 products at a source higher in a model treenode leads to create 1000 task sequences at once. You want to create a balance then you must create items in alternating patterns in all your sources. You have to understand what your model does. Even if something is happening at the same time in your model there is still an order what happens first what happens next. And this leads to consequences what your model does. 

[tugba_aslanturk]

Hi — thanks for the tips so far. I reorganized the model as follows and I still need help implementing the exact operator behaviour I want:

Current setup

Two separate Sources feed into two distinct Queues (Source1 → QueueA, Source2 → QueueB).

All Operators pull from the Queues (not directly from Sources) and now all 8 operators work simultaneously — good progress there.

What I want

I want Operators to randomly pick/receive tasks (i.e. be assigned items) in a distributed/random manner, and then — after each delivery — each Operator should go to the nearest Source’s Queue (nearest by travel distance) and pick the next box from that Queue.

In short: random assignment/distribution of work, then return-to-nearest-queue logic for subsequent pickups.

Problems / questions

Right now Operators are pulling from Queues and stay busy, but I can’t get them to follow the flow “random assignment → travel to nearest Source’s Queue → pick box”. How can I implement that sequence reliably?

Should I handle the “random distribution” at creation time (round-robin / alternating creation between Sources / set an attribute) or via the Dispatcher/TaskSequence logic? Which approach avoids creating 1000 task sequences at top-level?

Recommended implementation pattern: Process Flow token for “on unload → find nearest source queue → travel there” vs. scripting on the Operator’s UnloadComplete trigger — which is better/scalable?

If you have a small snippet (Process Flow or code) that: (a) assigns incoming items randomly among operators, and (b) on task completion computes nearest Source/Queue and makes the operator travel there — that would be ideal.

Thanks — concrete examples or a tiny model snippet would save me a lot of trial-and-error.

[tugba_aslanturk]

You can see the model in the attachment.

[joerg_vogel_HsH]

A remark: I haven’t looked into your model.

A global task sequence list has some default fields. There should be a dynamic field for a distance to destination or unload station. Perhaps there is a dynamic field for load station, too. If it isn’t you have to adjust the code to evaluate the distance between puller and loading station. If a distance field doesn’t exist in this kind a list, you find a template for this by adding new fields to a list. Loading station is in a standard 3D logic task sequence a parameter involved1 in first task or involved2-property in second task. 
you can push all task sequences into such a list and whenever you pull for a new task sequence to dispatch it to an available taskexecuter any dynamic field gets evaluated and you can query for shortest distance to an loading station.