Unpredictable behavior of the Conveyor ExitTransfer with First Available rule

Question

question

Serge A asked Nov 22, '19 anthony.johnson edited Mar 5, '21

Unpredictable behavior of the Conveyor ExitTransfer with First Available rule

12 identical flowitems are created at the beginning of the simulation and are conveyed with the same speed on three conveyors with the same conveyor type. The exit transfer of the first conveyor is configured to send items to the first available output. Its sendtoport trigger also changes the color of the item.

Assuming that conveyors move at the same speed, all items should be able to enter the first downstream conveyor (Conveyor2), which happens most of the time. But items #3, #10 and #12 are sent to the second conveyor (Conveyor3).

It appears that sendtoport is called before the downstream conveyor is actually available, and it takes into consideration when the conveyors will be freed. This calculation might be slightly inaccurate which leads to the wrong estimation which conveyor will become available first.

Expected behavior: all flowitems are sent to the first conveyor.

Reproducible: 19.0.6 and 19.2.4.

conveyor-first-available-1924.fsm

Software Version:

FlexSim 19.2.4

conveyors bug

conveyor-first-available.png (37.6 KiB)

conveyor-first-available-1924.fsm (37.4 KiB)

Answer 1 · 2019-11-22T19:25:49Z

Regan Blackett answered Nov 22, '19 anthony.johnson edited Mar 5, '21

If you click and drag the Entry transfer on the down stream conveyor so that is on the side of the conveyor rather than the end, it gives you the expected behavior.

transfer.png (803.9 KiB)

· 2

Phil BoBo ♦♦ commented · Nov 22, 2019 at 07:42 PM

Serge,

I'll add a case to the dev list to look into why it isn't working in the original case. In the meantime, you can use Regan's workaround.

1 ·

anthony.johnson ♦♦ commented · Mar 05, 2021 at 07:02 PM

This is a floating point precision issue where the downstream conveyor's open input event is sometimes getting created right after the upstream conveyor's open output event, and sometimes it's being created right before. Unfortunately, it's very difficult to "fix" this in the conveyor design, because changing the floating point comparison would have other side effects that would show up elsewhere, or wouldn't even fix this but would just effect a different, but still incorrect, result.

Another solution to this is to simply add some small padding value to the entry space of the upstream conveyor, but not on the downstream conveyors. This would mean that items would have an infinitesimal gap between them that's large enough to avoid floating point precision issues when entering downstream conveyors.

1 ·

question