How to assign items from a list to the nearest processor (distance-based, not index-based) in Process Flow?

[LiamYY]

Hi folks,

I’m following the FlexSim “Tasks using Lists” tutorial (Tasks using List section, v22.2) and adapting it to my model:

• I’m using Process Flow with a List to manage items.

• A token is created when an item enters an entry Queue.

• I use a Schedule Source to represent my processors (multiple identical stations).

• Processors pull items from the List using Pull from List logic.

• Operators / task executors are used to move items between resources.

Right now, item assignment from the List is effectively based on the token index (1 to N). What I want instead is:

The operator should always send the item to the nearest available processor, where “nearest” is based on the travel distance from the Queue (or item location) to each processor, not on the token index.

I see there are options like ListFields() and different distance types (FixedResource, Item, TaskExecutor, TaskSequence, etc.), and in the Pull from List activity I can reference the Puller and Puller’s token. However, I’m not sure what is the best way to:

1. Calculate the distance from the item’s current location (entry Queue) to each candidate processor, and

2. Use that distance inside the List / Pull from List logic so that the item is always assigned to the closest processor, instead of just going by list order or token index.

Concretely, my questions are:

1. How should I structure the List and ListFields (or other labels/fields) so that I can store or compute the distance to each processor?

2. In the Pull from List activity, what is the recommended way to select the nearest processor dynamically using those distances?

3. Is there a clean way to use the Puller / Puller’s token and resource locations in the expression so that the logic is fully distance-based?

Any example expressions, screenshots, or small demo models showing distance-based assignment from a List would be very helpful. My model is attached. Thanks!

[joerg_vogel_HsH]

Please look here, how it is done for a rack.

https://forums.autodesk.com/t5/flexsim-forum/finding-the-nearest-open-slots-to-an-item-in-a-rack/m-p...

(all answers)

[LiamYY]

Thanks! I found this thread, which is very similar to what I’m trying to do: https://forums.autodesk.com/t5/flexsim-forum/acquire-nearest-shared-resource/m-p/13548379.

My current issue is that the token representing the processor seems to get stuck at the “Release processor” step (where I push it to the list after the processor finishes processing). Is there anything wrong with the way I’ve set up this logic?

I’ve attached screenshots and the model for reference.

Thanks again!

[FelixMoehlmann]

By default a token will wait in a Push To List activity until the pushed value is pulled. If you don't want that, set a maximum wait time and check "Keep On List On Early Release".

[LiamYY · Accepted solution]

Thanks! I played around with the model, and-

The logic (see screenshot) is:

• Source: Items Enters Queue

• Get op

• Delay for X seconds

• Acquire Nearest Processor (resource group)

• Load Item from queue1

• Unload Item at Processor

• Free op

• Wait for process finish

• Release Processor

• Sink

What I’m seeing:

• If the delay between Get op and Acquire Nearest Processor is 0.15 s, the operator always goes to the nearest available processor (as expected).

• If I change that delay to 0.10 s (or remove it), the operator sometimes goes to a farther processor instead of the nearest one.

Why would changing this small delay affect which processor is selected as “nearest”?
Is this related to event ordering / when the distance is calculated, and is there a better way to guarantee the operator always chooses the nearest processor without using an arbitrary delay?

Thanks!

[FelixMoehlmann]

The process time of the processors is 0.1s. The operator is released after the item is unloaded, the processor is available again 0.1s later. If the delay is 0.1s or less, the processor has not been pushed back to the list yet, when the next token pulls one (when delay and process time are equal the timing depends on the order and amount of events, which in this case works out to the token pulling first before the release happens).