Setting Up Multiple Shifts

Question

question

Adrian M asked Mar 26, '24 Jason Lightfoot edited Mar 31, '24

Setting Up Multiple Shifts

Hello,

I'm having a hard time setting up multiple shifts and would like some guidance on how to do so. I have a ProcessFlow module set up where I use the Acquire and Release activities every now and then.

The issue I'm experiencing is that when I set up the shifts using timetables and a customized down function with Stop Inputs and Outputs then on resume function with Resume Inputs and Outputs, nothing really stops e.g. an operator dedicated to the 1stShift will still be working during 3rdShift hours.

The secondary issue I'm experiencing is that when I update the down behavior to Stop Objects and Resume Objects, the operators get stuck until they are back on the clock, but I would like for the person on the subsequent shift to take over their work, so production can continue on.

The dispatchers seem like they are doing a good job at switching between multiple shifts, but I have no idea how I can reference all three dispatchers for the three shifts. Also, the count in the properties window will only count the number of items I have selected within that referenced group which will only allow tokens to grab a maximum of 3 since I have 3 dispatchers for paint, but actually have a total of 30 operators.

How should I set up multiple shifts while being able to reference them in the ProcessFlow resource activity? Any operator's unfinished work should be completed by the next operator that is starting their shift. (Or allow the operator to finish their work and allow the next operator to begin the next task.)

Thank you,

Software Version:

FlexSim 23.0.2

operators schedule multiple shift

1711411512756.png (347.5 KiB)

1711411908565.png (211.7 KiB)

1711411938766.png (166.2 KiB)

1711412311234.png (318.6 KiB)

· 1

5 |100000

Attachments: Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Joerg Vogel commented · Mar 26 at 05:57 AM

@Adrian M, There are two logic levels in FlexSim.

3D logic based on object triggers and Tools, which is a legacy mechanism.
Process Flow is absolutely independent.

There exists also a supporting mechanism called TaskSequences. Automatically created Tasksequences are transport and utilize task sequences.

Tools like timetable, MTBF/MTTR are introduced for 3D logic.
Process Flow, because it is independent, evaluates not a single property of a 3D object automatically or any tool at all. If you work with this logic, you are responsible to read all value properties yourself, but you can on the other hand take shortcuts, that allows you to override strict 3D sequences of logic steps. Please keep this in your mind, when you work with FlexSim.
You are allowed to mix both logic levels and they are working well together. But you must always remember that a strict stepping of a 3D logic implies benefits, that you must implement yourself in an independent Process Flow logic level.

Back to your question. It is mechanism called preempting. A operator is preempted away to do a different tasksequence. The previous preempted Tasksequence is transferred into a treenode called tasksequencequeue. This Tasksequence is marked as a begun tasksequence, because number of task to complete is smaller than total number of tasks of this tasksequence. Normally a Taskexecuter is looking for tasksequences that aren’t begun, this means number of task to complete is the same as total number of tasks in a tasksequence. When a Taskexecuter is not finding a not begun tasksequences anymore he does a begun tasksequpence. You can bypass this strict mechanism, if a begun tasksequence has got a higher priority than a not started Tasksequence. You see it is a strict step mechanism and it belongs to a 3D logic Level.
If a Taskexecuter would be connected at his output port to a dispatcher or another Taskexecuter, a preempted Tasksequence will be transferred over this output port connection to the input port object instead of being queued up in himself.
In Process Flow you are responsible to implement a similar mechanism yourself. It is based on an activity still called preempting, which will move a token to another activity and can keep a set of begun properties in token labels.

1 ·

Answer 1 · 2024-03-26T12:58:18Z

Jason Lightfoot answered Mar 26, '24 Jason Lightfoot edited Mar 31, '24

You can close the operator input ports at the end of the shift to prevent them from getting dispatched jobs and open the input when they come back on shift. Ideally the timing would allow them enough time to complete the task which will avoid the need for task preemption.

If you do need to preempt the job then still close the input but also add an output connection back to the dispatcher for the preempted job to be sent back and reassigned.

· 5

5 |100000

Attachments: Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Adrian M commented · Mar 28 at 12:29 AM

@Jason Lightfoot, @Joerg Vogel I think the problem is I was referencing the Operator Resource in ProcessFlow as oppose to referencing the Dispatcher in the 3D model to control the Tasksequences. After making this update it looks exactly like how I need the model to be working. Such a simple mistake lol. In the future, I shall reference the Dispatcher instead of token.resource especially when I need to implement multiple shifts.

Thank you guys for your input!

1 ·

1711583423223.png (336.2 KiB)

Adrian M Adrian M commented · Mar 28 at 09:01 PM

Also, I needed to update the code in the Custom Code activity for every Close and Open Port logic I used according to the trigger whether it was opening or closing the port because the default logic did not execute as I needed it to (maybe because the default logic is intended for fluids?).

Instead of using the default logic which was equipped simply with closeinput or openinput. I replaced it with Object.input.close or Object.input.open.

Thank you,

0 ·

1711659693680.png (226.0 KiB)

Adrian M commented · Mar 26 at 11:18 PM

@Jason Lightfoot is this what you are referring to?

All my timetables have the same customized down behavior with the functions detailed in the screenshot. I have also connected my operators to their designated dispatcher with an A connection.

Also, all the operators that are off shift have the status idle when it should have a scheduled down status meaning that they are still available to be utilized for the task sequences in my ProcessFlow.

May you please provide an example?

Thank you,

0 ·

1711481100012.png (408.9 KiB)

Adrian M Adrian M commented · Mar 27 at 06:12 AM

@Jason Lightfoot I've updated the model with a new set of characteristics and tried to follow the description you provided, but the close input ports on down and open input ports on resume for the operator still doesn't seem right since first shift operators tend to be working on second shift hours and etc. The event triggered source is listening to my timetable for their respective shifts.

I've also tried to use the same structure but replaced the custom code with stop object (operators) and resume object (operators) which seemed to work best for me, or at least looked accurate for what I wanted them to do e.g. first shift utilization will stop when their shift is over and second shift utilization will fluctuate when they were on shift and vice versa.

I had an A connection from my operators going to the dispatcher and an A connection from the dispatcher to the operator which was the case for both scenarios (close and open ports, stop object and resume object).

However, in all my Create TS activities I put the preempt option to preempt only, so I'm not sure if that was the right thing to do or should I select one of the other preempt options. I'm still confused about the preemption as I'm not sure if it did anything.

Thank you,

0 ·

1711519266310.png (281.1 KiB)

1711519704030.png (267.5 KiB)

1711519935907.png (299.3 KiB)

Jason Lightfoot ♦♦ Adrian M commented · Mar 31 at 12:33 PM

Any task sequence set to Preempt Only will interrupt any lower priority tasks and will also be interrupted by any higher priority tasks. That setting also means that when preempted the task sequence is preserved and if an output port is present, it will be sent incomplete through it (back to a dispatcher in this case).

The other two cases where priority is considered are Preempt and abort active (destroys the task sequence when preempted) and Preempt and abort all, which destroys all queued task sequences on the task executer).

If the operators are taking tasks when they should not, check the status of their inputs - they will be open when they should not be.

0 ·

question