Help with preemption shift schedule for operators pushed and pulled from lists.

[kari_payton]

[ FlexSim 17.0.2 ]

In the model, operators are created and pushed on a global list. Other fixed resources can pull operators from this list. I attempted to use preemption to have operators go off shift if they are idle or after the resource delay time. The problem is that processes stop on the fixed resource because it is waiting to push operators back on the list, but the token that pulls the operators are in the preempted flow. You can see this in my model at t=11.5. I will add different shifts of operators to the model that will continue the processes on this fixed resource.

establish-user-library-1.fsm

[sam_stubbsYXX86]

I'm not sure I completely understand the issue, but if your tokens are getting stuck on pushing/pulling from a list would you be able to use a "Use Max Wait Timer" option for the lists?

[kari_payton]

@Sam Stubbs If I use a max wait timer, when the context of the tokens returns after preemption they are still waiting to pull operators from the list but the tokens are gone. I'm asking how to create shift schedules using preemption if I am pushing/pulling operators from a list. The problem is that if the operators are in the delay when their shift ends, I am unable to send them off shift when they're done with the delay because the preemption event already happened. Is there a way to set the priority to finish the delay before going to the preemption event? Or for tokens to join the preemption event after the delay is finished. Because the times will have a statistical distribution I can't say exactly when the process will be completed for operators to go off shift at a certain time.

[logan_gold · Accepted solution]

@Kari Payton, if you want to wait until the Operator is done with its current task, then I suggest not using preemption. The only reason to preempt a Task Executer is if you want them to stop a lower priority task sequence and begin on a higher priority task sequence.

Instead, you can give an Operator a Delay task in your off shift logic for the amount of time the Operator should be off shift. Or, you can give it a Utilize task and then call the freeoperators() command when some other condition has been met. In either case, just make sure the task has a higher priority if it's possible that the Operator could have another task in its task sequence queue.

[kari_payton]

@Logan Gold ok I understand. Is this the same concept with shift schedules? Is there a way to have operators finish a task before calling the down function?

[logan_gold]

@Kari Payton, Yes. If you were to use a Time Table for instance, you can choose the "Travel To Location, Delay Until Down Time Complete" option in the Down Function. Instead of using the stopobject() command, this option gives a Task Executer a task sequence with a Travel task and a Delay task. So if you don't change the preemption method, the Task Executers will finish their current task sequence, then perform the Travel and Delay tasks.

[kari_payton]

@Logan Gold I removed the preemption and added Time Table. This works better. However, now though the operators can be pulled from a list even though they are not on schedule. Is there a way to query to pull operators from a list that have an idle state and not off shift?

[logan_gold]

@Kari Payton, unfortunately, using Time Tables when Operators are utilized in Process Flow can be a little tricky. One option you have is to add an Expression Field to your Operator list and then use this for the Expression:

getstatenum(value)

You'll also want to check the box for Dynamic, since an Operator's state changes throughout a model run.

Then, when you pull from the list, use this in the Query field:

WHERE fieldName == STATE_IDLE

Or this:

WHERE state != STATE_OFF_SHIFT

That last one is good if it's possible for the Operator to be pulled from the list even if it's in a state other than idle but not off shift.

[kari_payton]

establish-user-library-4.fsm

@Logan Gold yes it is being tricky but it's so close to working. I have tried both Queries but after the first shift change (t=8), the operators get "stuck" in the travel flow after being pulled from the list or the puller doesn't pull anything at all. Using the 2nd query you listed, Operators from shift 1 are pulled from the list but their shift ends and they don't finish the task. I set my time table on down for operators to travel to an object and delay until time complete. Is there a way to have them finish their tasks before being scheduled down? Using the 1st query you listed, no operator is pulled from the list at all.

[logan_gold]

@Kari Payton. The problem with the last model that you attached is the Pull from List activity happens at a time when there are not enough objects on the list that satisfy the query, because not enough Operators on the list are in an idle state. Also, back orders are only reevaluated when something new gets pushed to the list. Since the Operators are already on the list when enough of them change states, the back order is not reevaluated.

To fix this, you need to tell the list to reevaluate back orders when a certain event happens. So go into the list's properties window, under the Back Orders tab, and add a "Back Order Reevaluation Event". After clicking on the green plus sign, choose Value Event. Then, in the newly added fields, the only thing you need to change is the Event. If you click on the dropdown arrow on the right side of the input field, you can choose "OnStateValueChange".

This will cause the back orders to be reevaluated any time an Operator that is already on the list changes states and that should fix your issue.