Process flow logic to dispatch the task to different shift

Question

question

AnneK asked May 2, '24 Jason Lightfoot edited yesterday

Process flow logic to dispatch the task to different shift

Hi I am working on my model to add a second shift. I used the process flow to handle all the task sequence. When I run the model at the off-shift time of the first shift (after 4:30p), the first shift operator will schedule down, supposedly second shift operator will need to take over where the first shift ends and continue the operation. However, I didn't see that happening in the 3D model that the night shift people come over or the token change the task executer from morning shift to night shift, despite the processor is continue running. How can I request the shift change and redispatch the task to the next shift when the first shift ends. For example, this morning shift assembler 9 is working on token 28, when it reaches the off-shift time (8:05p) it's scheduled down, but it' still the operating time for second shift, so night shift person should get dispatched to continue work on the task until their shift ends. Do I need to add any custom code to reflect this?

Please find my model here for reference:R26_TS_Multiple Shift.fsm

Thank you,

FlexSim version: 23.0.3

Software Version:

FlexSim 23.1.0

process flow task executor dispatching strategies multiple shift

1714679929624.png (399.2 KiB)

r26-ts-multiple-shift.fsm (2.5 MiB)

Answer 1 · 2024-05-05T23:34:48Z

Jason Lightfoot answered May 5, '24 Jason Lightfoot edited yesterday

You should be able to just connect your task executers to dispatchers (output and input connections) to have the dispatcher re-issue the task. This has I think happened since if you look at the label above you'll see that the task sequence has been given to Assembler_Tester_RC. However I expect you need the operator to travel to the correct location in order to resume the delay task. To do this you would need to add a non-waiting milestone task that encompasses the travel task in its scope/range before your delay task. Note that references to the task executer should then be replaced with findownerobject(token.taskSequence) and not rely on the 'acquired' operator.

In fact with that mechanism in place I would also suggest not using Acquire Resource activities at all and instead just dispatch your task sequences to the relevant dispatcher.

· 2

AnneK commented · May 06 at 01:39 PM

Hi Jason,

Do you mean to directly connect the dispatcher to the processor? What does the none-waiting milestone task here stand for do you mean to ask operator travel from its current location to the place to perform the task before the delay? Could you provide a sample model including the "task executer should then be replaced with findownerobject(token.taskSequence) and not rely on the 'acquired' operator" for me to demonstrate your explanation or modify on top of my model so I can understand your advice better?

Thank you!

0 ·

Jason Lightfoot ♦ AnneK commented · yesterday

There's an article here you can reference first. If you need more help after that let us know.

A connection to a dispatcher is one way of getting a reference - there are many - lists, labels, maps, relative paths....

0 ·

question