question

Serge A avatar image
0 Likes"
Serge A asked anthony.johnson edited

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

FlexSim 19.2.4
conveyorsbug
5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

1 Answer

Regan Blackett avatar image
3 Likes"
Regan Blackett answered anthony.johnson edited

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
5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Phil BoBo avatar image Phil BoBo ♦♦ commented ·

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 Like 1 ·
anthony.johnson avatar image anthony.johnson ♦♦ commented ·

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 Like 1 ·