I have a problem with a part of my model. I am trying to model a switching mechanism where conveyer belts feed different parts (unique MUs) to the flow control (the 'switch' ) and the switch then distributes the parts to machines it is connected to. See the attached picture alone with my problem below.
I have 7 conveyer belt outputs connected to a Flow control entrance. The flow control decides the successor to send the MU to depending on several attributes of the succeeding machines. The rules for this switching mechanism are quite complex, so for simplicity's sake I will not bring them up. But my question is related to how the flowControl works with its forward blocking list.
As an example, I am sending a MU on one of the 7 conveyors to the flow control. The flow control decides to direct the Mu to successor 7. It turns out that Successor 7 is failed, but nontheless the conveyer the MU has come from is not full so there is nothing to worry about (yet). We send it to successor 7 (marked with green lines) anyway and hopefully the failure will end before the conveyer becomes full. The FwBlockingList of the flow control is populated with this MU, and naturally the MUs on the conveyer stop and start queuing up. Each new MU on this conveyer that activates the flow control will want to go to the failed successor since the conveyer still isn't full.
Unfortunately after a while, the failure on Successor 7 persists and the conveyer gets full. Now we are in trouble. Now the flow control, in its code, is starting to redirect the MUs to a new successor (marked with blue lines). But it doesn't work. Only after a considerable delay will the MUs move to the newly designated successor, but not right after the code execution as I would expect.
If it is of any importance, during this whole time, the other 6 conveyers are feeding MUs to the flow control simultaneously.
Why does this happen? I presume I am understanding something wrong regarding the flow control and how it works with its blocking list.
All I would want is for all MUs on the conveyer to redirect to the new successor according to the flow control's code when the conveyer the MU is coming from is full. I suspect the first MU (and the rest after it while the conveyer wasn't full) are blocking the MUs that want to go to the new successor. But that doesn't explain why there is a delay in the redirection of MUs, since I would otherwise expect the conveyer to remain full until the failure in successor 5 has stopped, whereupon the MUs directed to successor 7 would go there (green lines) and the rest would go to the other successor (blue lines) which were chosen when the conveyer was full. Instead all the MUs are redirected to the new successor (blue lines), but only after a delay, even while successor 7 is still failed.
I would very much appreciate some insight.
A note regarding blocking lists: only the MUs that actually tried to move will be listed; MUs queuing up behind those will not, since they have not reached the end of the line yet.
Since the assignment was made at some point, it will remain that way until there is a new events that triggers the assignment strategy again. But this will not be by the arrival of another MU in the already occupied line.
In my experience you can already get a quite realistic behaviour with the standard strategies of the objects.