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.
Answer by Matt Long ·
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.
Answer by Adrian Haws ·
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