Loading All Items From Queue

Question

question

dougdurbin asked Nov 17, '20 dougdurbin commented Nov 17, '20

Loading All Items From Queue

I generally work with the healthcare environment but I have a project that I need to utilize the standard environment in. I've attached my model for reference as well. This might have been better built using the process flow tool but I have 2 issues that I'm working through:

1. The transporter is responsible for moving items from outbox queues to inbox queues. I have a dispatcher that is connected to all 3 outboxes and are called to transport items between these queues. I believe the logic is that when an item enters an outbox queue, a transporter is dispatched for that specific item. The problem I'm having is that other items may enter the outbox queue before the transporter gets to that queue to transport the item. Is there a way to possibly add a trigger to the dispatcher to reevaluate how many items are in the outbox queue so that ALL items are taken from that queue and not just the one that was dispatched for? I've read some other answers but can't quite narrow down to this specific case.

2. Without the solution to the previous method, I notice that the items aren't FIFO when placed from an outbox queue to an inbox queue when the transporter carries more than one item. I notice this as the red item travel through the process. I'm thinking it has something to do with the push/pull lists but I'm not entirely sure.

Thank you for the help.

Airplane Exercise Simulation (Test).fsm

Software Version:

FlexSim 20.2.2

queue transporter flexsim 20.2.2 loading queue items

airplane-exercise-simulation-test.fsm (116.0 KiB)

Answer 1 · 2020-11-17T05:56:44Z

Joerg Vogel answered Nov 17, '20 dougdurbin commented Nov 17, '20

The default transport job action is in fact LIFO for the last loaded item, then it depends on the order of the tasksequence queue.

Taskexecuters get into action whenever they receive a Task Sequence. When a Task Sequence finishes, then a next Task Sequence is chosen from the Task Sequence Queue. You can order the Task Sequence Queue. The default mechanism is ordering by Priority value of Task Sequences.
There is a Task Type in the Sequence of a transport job, which is responsible to load more items. It is the Break task type. If the Task Executer is capable to load more items, because his transport capacity is not depleted, then the Break task let execute the function To Break in the Taskexecuter. The default option chooses a next available Task Sequence of Task Sequence Queue, which has not begun already. The Task Sequence, which has initiated the break function is put as an already begun Task Sequence into the Task Sequence Queue to get finished later.
You can set priorities of Task Sequences to force an order after a Task Sequence had finished to execute the next Task Sequence. But there is still the problem of the last loaded item. This transport job Task Sequence runs without executing the Break To function and will be unloading the last loaded item first. There is a parameter in the Break Task which forces the Taskexecuter to execute always the Break To function. If Var1 is set not to 0 then the Break To function gets executed anyway. Then you can customize the source code to divert the execution of Task Sequence from the currently active to a different Task Sequence. If the Taskexecuter has not got any transport capacity left or there aren’t any Task Sequences to begin with, then the Taskexecuter must continue the already begun Task Sequence which loaded the first item into him. There are maybe more conditions to fulfill, but that is something you must decide.

You can enforce the parameter Var1 to be 1 in the On Receive Task Sequence event trigger of the Taskexecuter by changing the Variable value. Therefore you must cast the Task Sequence treenode ts into the Class Tasksequence, if it has not been done in the source code header of the trigger. Then you can set the first variable of the third task of the task sequence to the value 1.

Tasksequence castedTS = ts;
castedTS.tasks[3].var1 = 1;

If you want to enforce FIFO then you can set the priority of the receiving descending begining from first loaded item.

Here you find a similar approach in another thread.

· 1

dougdurbin commented · Nov 17, 2020 at 06:15 PM

This makes more sense, I didn't realize it would be a break activity but makes sense with your description.

0 ·

Answer 2 · 2020-11-17T14:09:09Z

Jason Lightfoot answered Nov 17, '20 dougdurbin commented Nov 17, '20

If you use regular port connections and don't push to lists then I think you get closer to the 'correct' behaviour avoiding some of the issues you describe.

The issue relating to loading all items from the queue doesn't appear at first glance to be one of the transporter's BreakTo - it's the PassTo of the dispatcher. At 0.88 the male operator goes to the queue with two boxes but only picks up one of them because the other task has already been given to the female operator.

If you want to use lists I'd suggest using a process flow to coordinate the jobs rather than rely on a dispatcher and default pull logic.

· 1

dougdurbin commented · Nov 17, 2020 at 06:17 PM

Thank you, I used the standard port connections vs pushing them to a list. My instinct was to use the process flow vs default logic. I may give it another try using this approach.

0 ·

question