After running the model until its stop time, I realized that processor one is not running at its full capacity and is stuck with an item on it for a while. How can this be fixed?
@Mia L
I think your problem is being caused by a combination of the input/output port logic and the limited capacity of the packaging queue.
Essentially what I think is happening, the queue is receiving things from the first available of it's inputs, and since the capacity is only two there's a lot of competition for those spaces. Since Processor 1 is on the last input of the queue, all other ports would have to have nothing ready to send in order for Processor 1 to send. You can test this by rearranging the port order and you see that the "stuck" processor is whoever is on the queue's 5th input.
It also doesn't matter if the queue is pulling or if the processors are sending, the result is the same.
My recommendation would be to use a list. Attached I have a version of your model that simply has the processors push their items to a Global List, and the packaging queue pulls from the list in its pull strategy. This doens't cause the gridlock you were seeing before because the nature of the list prefers the longest waiting item over the first upstream port where something was found.
As another concern, I removed the send to port you had on processor 4, because 1) you didn't have a second port and eventually would would have processor 4 trying to send to a port that doesn't exist which eventually would cause processor 4 to block, and 2) it can cause conflicts if you are pulling from an object that is doing anything other than first available in its send to port.
I hope this helps.
14 People are following this question.
