question

Kari Payton avatar image
0 Likes"
Kari Payton asked Adrian Haws commented

Change operator when the shift changes on a custom fixed resource.

I'm trying to use shift schedules to set operator hours. The problem is that the operators don't stop and switch out when their shift ends. The first group of operators leave after their 12 hour shift but the second group doesn't come in to finish the task. My operators are grouped as a resource. Maybe this is not the best way to model using operators for a custom fixed resource process.

shifts.fsm

FlexSim 16.1.2
time tableshift schedulefixed resource process flowprocess flow preemption
shifts.fsm (45.1 KiB)
· 2
5 |100000

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

Kari Payton avatar image Kari Payton commented ·

@Matt Long @Adrian Haws hey thanks for the answers. I attempted to use preemption, but still struggling with it. Please help if you can. I attached the model. The operators are not being released from their tasks even though they are going on off shift. preemption-shift-workers.fsm

0 Likes 0 ·
Adrian Haws avatar image Adrian Haws Kari Payton commented ·

@Kari Payton I'm not sure exactly what you're trying to do with the preemption, but I've made a few small changes in your model.

First, you have to make sure that the resource you're trying to utilize is actually acquired. In your model you release the resource, but didn't acquire a new one before calling tasks like "Travel", "Change Visual", etc, with a reference to the "resource" label. What I did was to release that resource, then immediately acquire a new one. (As a side note, I made sure to not acquire the resource I just released by using a query).

Second, when the source for preempting creates a new token, there isn't always a token in the "Delay" activity to assign to the label "preemptedTokens". Therefore I made a "Decide" activity see if that label exists, and if it doesn't to send it to a sink.

See attached model.

0 Likes 0 ·
Matt Long avatar image
2 Likes"
Matt Long answered Adrian Haws commented

The issue specifically with your model is the first two operator tokens get stuck in the Delay activity because your Time Table preempts the operators to travel to the cylinder and then tells them to delay until their next shift.

There are probably multiple ways to handle this, but when it comes to schedules and dealing with Time Tables, I would recommend taking a look at the Preemption activities. Save Token Context, Release Token and Restore Token Context. The User Manual has a few examples of how to use these activities.

In the attached model I added an Event-Triggered Source for each time table listening to their Down Function. I then call Release Token on the tokens sitting in the Delay activity. This gets the tokens moving, but it still doesn't completely solve the problem.

The problem is in the disconnect between the Time Table and Process Flow. The Resource doesn't perform any checks as to whether an operator is "off shift" or not. It doesn't know anything about Time Tables or MTBF/MTTR objects. You have to manually control the Process Flow in these situations.

Without any additional changes to the model, the Operator's are acquired before they have finished their "off shift" time (7AM). This is due to the second shift's delay only being 11 hours and finishing before the next shift is scheduled to start. You'll probably wan to perform some checks to see if your operators are on shift before acquiring. One way of doing this would be to have some Event-Triggered Sources or Wait for Events set up to listen to the Time Tables and perform appropriate actions depending on their state.

shifts-updated.fsm


shifts-updated.fsm (47.5 KiB)
· 3
5 |100000

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

Kari Payton avatar image Kari Payton commented ·

@Matt Long @Adrian Haws I read the help manual about Preemption and have a little better understanding of it. However, in the model I don't want the operators on the first shift to pick back up where they left off. I want the operators on the 2nd shift to pick up where the first shift left off.

The first process takes 14 hours, but the operators are on a 12 hour shift. So I want the operators that come in on the second shift to finish the last two hours of processing that the first shift didn't get to.

0 Likes 0 ·
Adrian Haws avatar image Adrian Haws Kari Payton commented ·

@Kari Payton This answer talks about how to do this.

1 Like 1 ·
Matt Long avatar image Matt Long Kari Payton commented ·

The task sequence activities don't save any info when you use the Save Context activity. So it may be best to use a Delay activity for the processing time. Then when the operators go off shift, you want to save the context of the tokens in the Delay and release them to a block of activities that will release their current operators and acquire new operators. Once the new operators get to the point where they need to finish processing, you restore the context of the token back to the delay activity.

0 Likes 0 ·
Adrian Haws avatar image
0 Likes"
Adrian Haws answered Adrian Haws edited

There are different ways of going about this. This answer has a model with two operators switching off using a MTBF MTTR table and a Fixed Resource Process Flow. 1484-901-shift-tests.fsm

You might also be interested in the model from this answer. 1096-process-flow-schedule-1.fsm

I see that you're using time tables in your model, which works fine. It looks like the thing that's not allowing your two available operators to be acquired is that you can't get to the second "Run Sub Flow" activity until the first one is done. You'll want to set up your logic just a little bit differently. I can't say whether or not this works how you'd like your model to, but I attached a revised version of your model that allows for all operators to be acquired. 1836-shifts-1.fsm


5 |100000

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