Strange behaviour non accumulating conveyor

On behalf of Steven I'm posting a little model in which he encountered strange behaviour of the non accumulating conveyor.

In the model is a separator which splits the product in two. The first part goes to the conveyor (non accumulating) and the second into the queue (which would be a different process). When there are 10 products on the conveyor the input seems to block until the last product is has left the conveyor. How does this happen?

And yes, if you put it on accumulating it works fine, but why isn't it working for the non-accumulating conveyor?

Martijn

Hello,

just checked the model, and don't know if the conveyor blocks que input when there are 10 items inside, becouse i tried using the option "round robin if available" on the send to port option in the separator, and got the same behaviour, but if i use the option "round robin" it works fine. so the conveyor might not be blocking the input but set it as unavailable ??.. is there any difference ?... i would like to know the reason of this behaviour too

Pablo Concha E.

Martijn,

I ran some tests on your model and the problem definitely is with the conveyor and not the seperator. If you watch closely and step through the events the input port of the conveyor goes red when the parts try to leave the seperator and then goes green again immediately after. This will have to be something for Anthony to look at.

UPDATE:
Alex just came in and informed me that the conveyor was closing its input ports on convey end (Deep in the library object code). We then figured out that the on exit event opens the input ports back up.

No problem right? Wrong, because of the timing in the model there are a number of events that occur at the same simulation time. So when the convey end event creates the on exit event zero time later it actually occurs many events later in the simulation you provided. So the events happen as follows:

Conveyor - Convey End Event
Source - Creation Event
Separator - Process Finish Event
Conveyor - Exit Event

As you can see the Separator event ocurs in between the convey end and exit events for the conveyor. At this time, however, the conveyor has closed its input ports because it is an non-accumulating conveyor and doesn't yet know if it can allow anything in yet or not. Remember a non-accumulating conveyor can't let anything else in until there is room to allow it in and the item at the end of the conveyor has to leave for that to happen. Any small change in the length of the conveyor or in the times in the model and this would not happen.

An easy fix for this model would be to close the output of the separator on convey end of the conveyor and send a delayed message 0.000000000001 time later to reopen the output ports of the separator. The model would behave almost exactly like it should (because almost no time would elapse) but this problem would be avoided entirely. The reason you cant do it 0 time later is because the event for the conveyor exit isn't created until after the code for the on convey end trigger is fired.

Big Thank you to Alex,
Brandon

Martijn,
Brandon is right on that. The model behavior is a rare coincidence of the fact that your separator's process time is exactly 1, the conveyor's speed is exactly 1, and the conveyor's length is exactly 10, namely exactly 10 times the separator's process time. If you change the length of the conveyor to 10.01, or give any amount of randomness to the separator's process time (I changed it to uniform(0.99, 1.01)) then the problem will go away. The problem is that you're using the default separator option, which for splitting is to go to first available, and for that instant that the separator finishes the process time of the part, the conveyor is actually unavailable because its first part just hit the end of the conveyor but hasn't left yet, so the conveyor technically can't receive the next part, so the part goes to the queue.

Like Pablo said, you can force the item into the conveyor by using round robin sendto strategy instead of first available.