Multiple Processors Using Preemption to Pull Operator from Dispatcher

Question

question

Mindy W asked Apr 20, '21 Mindy W commented Apr 21, '21

Multiple Processors Using Preemption to Pull Operator from Dispatcher

I have a model with several multiprocessors, one of which is a process that should not be worked on unless all other processors are empty (i.e. it's the only work to be done). I'm trying to utilize the preemption functionality in the FlexSim tool so that the other multiprocessors receive priority.

I cannot attach my actual model, but I've created the attached test model, which is having the same issue.

Preemption Test.fsm

The processors require an operator to perform the process steps and the operator is controlled by a dispatcher. I have set the dispatcher to Pass To 'First Available Unless Preempting then Minimize Queue Count'.

In the attached model, there are three multiprocessors. Multiprocessor1 is the processor that should only be worked when no other work is available (no preemption). When you begin running the model, it works as expected. The operator is dispatched to Mulitprocessor1 when a flow item arrives, but when a flow item arrives in Multiprocessor2 (with preemption), the operator stops working at Multiprocessor1 and moves to Multiprocessor2.

Until this point, everything is working as I would expect. However, when a flow item arrives in Multiprocessor3 (also with preemption), the model has an issue. I have placed a break in the dispatcher's Pass To code to try to determine the issue and when this break is present, the model gets stuck and loops through this code repeatedly. If the break is removed, the model simply closes. No errors are displayed in the System Console when I reach this step.

The way I would expect the model to work is that the operator would finish the work at Multiprocessor2 and then it would move to Multiprocessor3. Both Multiprocessor1 and Multiprocessor3 have requested an operator, but because Multiprocessor3 uses preemption, I would expect the operator to go there first. There should be no difference in priority for Multiprocessor2 and Multiprocessor3, so if both are requesting an operator, I would expect the operator to go to whichever requested the operator first. This is what I'm trying to do.

Can anyone advise as to what is being done incorrectly in this model? Am I misunderstand how preemption should be utilized?

Thanks in advance!

Software Version:

FlexSim 18.0.10

dispatcher preemption flexsim 18.0.10 customcode

preemption-test.fsm (23.9 KiB)

Answer 1 · 2021-04-21T06:45:33Z

Felix Möhlmann answered Apr 21, '21 Mindy W commented Apr 21, '21

The model stops working because there is an A-connection going from the operator back to the dispatcher. This will cause the operator to pass any additional task sequences back to the dispatcher creating an endless loop.

If I understood what you are trying to achieve correctly, you might not need to use preemption at all. Instead you could simply raise the priority level for the second and third Multiprocessor above that of the first one. New task sequences for those two will then automatically be queued in front of those for the first machine.

Hope this was helpful.

· 7

Joerg Vogel commented · Apr 21, 2021 at 08:39 AM

There is not an endless loop, because an operator receives only one tasksequence at a time from a dispatcher, if he gets available after he has finished his last active tasksequence and his own tasksequence queue is empty. A taskexecuter is doing always two things. He is executing tasks and he manages tasksequences like a dispatcher.

0 ·

Felix Möhlmann Joerg Vogel commented · Apr 21, 2021 at 10:05 AM

I might be wrong, but that is not the behaviour I see when the dispatcher is set to "First Available Unless Preempting" (or other options such as "Shortest Queue", "Shortest Distance", etc.), as is the case in the model provided.

To test this I build another model, connecting a second Operator to first via an A-connection. When the tasks are not preempting, the first Operator only ever receives a single task sequence, as the dispatcher will use the "First Available" logic. However, when the queues are set to preempt, more tasks will be send to the Operator, with queued tasks being passed along to the second Operator. This suggests that the same would be true for the connection back to the dispatcher, which in turn would it assign it back to the operator, thus creating a loop.

Preemption_TE_Chain.gif

Preemption_TE_Chain_2020_2.fsm

Granted, the model is build in a newer version (2020.2), as I don't have the 2018 version installed right now.

0 ·

preemption-te-chain.gif (477.7 KiB)

preemption-te-chain-2020-2.fsm (36.3 KiB)

Joerg Vogel Felix Möhlmann commented · Apr 21, 2021 at 11:58 AM

@Felix Möhlmann,I made a mistake. YES, there is an infinite loop, if a taskexecuter has got an output port back to his dispatcher.

A preempted tasksequence gets a priority to be transfered by a dispatcher to a connected taskexecuter. The Taskexecuter is a dispatcher himself. If he hasn't got a rule to transfer immediately to another available output port, then he stores all incomming tasksequences in his tasksequence queue node. If he is connected to a dispatcher, then this dispatcher is always available and then there is an infinite loop.

preemption_queue.fsm

0 ·

preemption-queue.fsm (38.4 KiB)

Show more comments

Mindy W commented · Apr 21, 2021 at 01:41 PM

@Felix Möhlmann

Based on your comments, I tried using priority rather than preemption and this is causing two things to happen:

If the operator is dispatched to the Multiprocessor with a lower priority first, he isn't released until the process step has been completed. In my actual model, this process step has a very long duration, so I want the model to interrupt the process and move the operator to a higher priority Multiprocessor.
It appears that each process step in the Multiprocessor is stored as a different task in the task sequence list, so the operator moves back and forth between Multiprocessors performing one process step and then switching to another Multiprocessor to perform one process step, and so on. NOTE: In my actual model, the multiprocessors have more than one process step each.

@Jörg Vogel

I also tried eliminating the operator's output connection to the dispatcher, but ran into a problem there as well. When I eliminate that connection in the model attached above, the operator is first dispatched to Multiprocessor1 because this is the first Multiprocessor to receive a flow item. When a flow item arrives in Multiprocessor2, it interrupts the processing at Multiprocessor1 and moves to Multiprocessor2. However, after that it never leaves Multiprocessor2. Multiprocessor3 requests and operator when the operator is busy at Multiprocessor2 and when the flow item leaves Multiprocessor2 another item enters and the operator just stays at Multiprocessor2 and continues processing flow items there.

Here is some clarification on what I'm trying to do:

I have one multiprocessor in my model that is lower priority than the other multiprocessors. It also has a very long duration, so if an operator is dispatched to that multiprocessor and another multiprocessor requests the operator, I want the model to interrupt and move the operator to the higher priority multiprocessor.
When an operator has been dispatched to a multiprocessor, some of the process steps require and operator and some do not. Is there a way to tell the operator to work stay at the multiprocessor it is currently at if that multiprocessor's next process step also requires an operator, otherwise move to the next task in the task sequence list? Is it some combination of settings in the Dispatcher's 'Queue Strategy'? Essentially, the goal here is not to spend extra time traveling if the next step at the Multiprocessor that is currently being worked also requires and operator, but if the next step does not require the operator, I want it to be released to do other work.

Thank you for your help!

0 ·

Felix Möhlmann Mindy W commented · Apr 21, 2021 at 04:26 PM

Thanks for the clarifications @Mindy W

To interrupt the process at the Multiprocessor1 preemption will indeed be necessary then. To keep the operator working at the same machine if possible you could try to increase the priorities of consecutive tasks that require the operator to be present.

So for example if a multiprocessor has 8 steps, where steps 2 and 6 do not require the operator, the priorities would be:

Step - Priority
1 - 1
2 - 0 (doesn't matter)
3 - 1
4 - 2
5 - 2
6 - 0 (doesn't matter)
7 - 1
8 - 2

This should make the operator finish consecutive tasks first before moving to a different machine to start a "priority-1 task" there.

The priorities of Multiprocessor1 should all be 0 to not interfere with task of the other machines.

This is the closest solution i could come with so far.

If it's still not close enough to what you want to achieve, you will probably have to use Process Flow to properly bundle multiple steps into a single task sequence.

0 ·

Mindy W Felix Möhlmann commented · Apr 21, 2021 at 05:23 PM

@Felix Möhlmann @Jörg Vogel

Thank you again for your comments! Setting the model up using preemption with the priorities as described above, seems to be working as expected! And if I remove the output port connection between the operators and the dispatcher, the code does not get stuck looping through.

Thanks again!

0 ·

question