I am building a model and there is a situation I did not understand.
I have a schedule with two work shifts (201 and 202). I also have a WorkerPool with the number of workers on each shift and their services. These workers will perform work on eight SingleProcs
Pausing the simulation, I found that there were stations waiting for workers, although there were workers available on WokerPool, so I noticed something else strange: there were workers on shift 202 working on shift 201.
What is going on?
Solved! Go to Solution.
Since you show the dialog of the worker No 19, but have only 13 workers defined in the wokerpool table, I suspect that you have other model frames (maybe copies of the model in discussion) that have been running and where not resetted? Or are there more than 1 workerpools? Using the same shift calender ore others? Are you looking at the right worker instances?
I suggest you check where work NO. 19 come from at the init stage and stop the simulation and shift switch time, and check the state again, or you can only activate this type of worker and run simulaiton to check again.
I think you can find the problem, or the software problem, thanks.
I did some testing and found that it's a software problem.
I have two workerpools associated with the same calendar. In this way, the error occurs, with active shift workers not going to their jobs and unplanned shift workers are working.
So, I created another calendar with the same information, but another name, so I left a workerpool associated with a calendar. The problem no longer occurred.
I suggest that this bug be observed in the next software update.
My little model have two workerpools and one shift calendar and works as desired.
Can you please update your model which shows the bug or adapt my model so that we can see the bug.
Please use relative path of the broker in workerpool and also the shiftcalendar. Because of the absolute path the broker & shiftcalendar might be still referencing from some other frame. if you have a different shift timings there it might affect the broker and worker pool. Also having operator no. 19 will not create any problem if its giving the right service at the right time. From the picture it looks like if you use the relative path of broker and all the other object related to it from the same frame it may solve the issue.
Also as a best practice relative paths helps to avoid unnecessary debugging, unless you really want to reference the object from different frame.
Absolute path: .Models.MasterFrame.broker
Relative path: Broker