Task priority does NOT preempt in process flow

[yyangN34HW]

Hi there, I'm following through tutorial task logic to build interactive process flow and 3D Model.

https://docs.flexsim.com/en/25.0/Tutorials/TaskLogic/Tutorial2CoordinatedTasks/2-2CoordinatedTasks/2...

I modified slightly to add a travel step followed by standard task creation, and move down "acquire processor" after then, so that the released operator would travel to standard queue before previous token finished in the processor.

Then realizing that if both standard queue and large queue have boxes, Operator A and B would head over to each queue instead both heading to large queue. I upgraded both "Create Main Task" and "Create Assisting Task" priorities and selected "preempt only", it didn't pull back Operator A from walking to standard queue as shown. How can I fix this logic?

[moehlmann_fe · Accepted solution]

Before the task sequence gets created the token must first acquire the operator as a resource. As long as this is in place, the preemption setting can't make a difference.

For example, you could remove the acquistion/release from the synchronized task and create the task sequences in fixed operators (since there are only two anyway).

[yyangN34HW]

I see, thanks for the solution, this workaround does solve.

I, however, keep thinking ahead that what if I'd have third or more operators, then assigning the created task to fixed operator wouldn't solve this issue. Clearly switching "acquire operator" to post create task would cause error, so I rewrite the heavy transport tasks by removing "Split" and all "Synchronizes", and changing the quantity of "acquire: main operator" to be 2. Seems that it creates array in the heavy task token but does NOT drive both operators to do the task.

Any better idea on making operator's quantity variable to be viable? Thanks in advance.

[yyangN34HW]

Just realizing that the model can only run for roughly 10 mins and get stuck with operators, objects keep piling up in both queues, no error message pops out.

Any idea on what's the issue? Thanks in advance.

[moehlmann_fe]

On the left side, the operator gets acquired first, then the processor. On the right side it's the other way around. This can, and does, lead to a situation where one side has an operator but can't get a processor because the processor is acquired by the other side without access to an operator.

To prevent this, if multiple resources are required, they should always the acquired in the same and later released in the opposite order (acquire A, acquire B, release B, release A).

[yyangN34HW]

I see, in which case the operator won't be actually released until the process is finished. Solution accepted!

Would you mind taking a look at the reply in which I uploaded another version for an alternative idea of controlling operators as a variable? Unfortunately it didn't work out as expected. Sincerely appreciate for your time.

[moehlmann_fe · Accepted solution]

Since you will want to switch back to acquiring the processor before the operator anyway, I would suggest the following:

Add the travel task to the 'singles' queue at the end of the task sequence but uncheck the Wait Until Complete option. The task will be added but the token will continue down the flow immediately, releasing the operator. It can then be acquired by another token and the preemption can override the travel task back to the queue.

Additionally, you could implement a Queue Strategy for the Operator resource, giving the 'doubles' tokens a higher priority to acquire an operator.