Model Freeze Without Dispatcher When Multiple TEs Are Connected to a Combiner

[borja_lorenzo]

[FlexSim 25.2.0]

I am comparing two simplified models: one with a Dispatcher and another without it.

Both models include:

a Combiner,
one operator TE connected through a center port that loads material into the Combiner and performs processing tasks,
and another transporter TE connected through a center port that removes completed pallets.

The issue only appears in the model without the Dispatcher.

Around simulation time 08:56 (after a scheduled stop at 08:55), the system freezes:

the operator stops bringing boxes to the Combiner,
pallets are no longer removed,
and the TE appears blocked.

Using the exact same logic with a Dispatcher, the problem disappears and the model runs normally.

I would like to understand why this happens without a Dispatcher and why adding one resolves the issue. Could this be related to some internal task sequence conflict, task prioritization, or center-port TE allocation behaviour? Could this also be related to some kind of event race condition or task allocation conflict when multiple TEs are involved in the same process?

I attached both simplified models for comparison.

Thanks.

[moehlmann_fe · Accepted solution]

The combiner process is set to "preempt and abort active". Before the 'freeze' the operator is moving the fifth and thus last item of the batch to combiner2. While this is happening, the forklift picks up the full pallet from combiner1. This creates a task sequence to move a new pallet from the source to combiner1 in the task sequence queue of the operator. When the operator unloads the item to the combiner, this becomes the new active task sequence. Then the combiner dispatches the process task sequence to the operator. That is preempting the transport task and thus aborting/deleting it. The source is now stuck waiting for the operator.

The preempt settings that abort other tasks are meant to be used when a new task has hade the current one(s) obsolete. Like a new task being created when the TE is currently travelling to a parking/waiting area. I really only ever use it when I give out tasks in Process Flow and manage the TE availability in some other way as well, since I can then know that any ongoing task can safely be aborted.

The dispatcher, in its default configuration, simply doesn't care about the preemption value of the task sequences. It only gives them out based on the priority. Which is why you see the operator first bring the new pallet to combiner1 in the model with dispatcher before processing the full pallet on combiner2.

So in short: Use "preempt only" when you want to allow tasks to take precedent over ongoing other tasks. Only use the abort settings you know for certain what the TE might be doing at the time.

And for completeness, because when preemption actually happens can also be confusing: A preempting task sequence will always preempt a non-preempting one. If both are preempting, this only happens when the priority of the new task is higher than that of the current one.