[kovarex] [0.16.22] Belt back pressure inconsistency
Posted: Mon Feb 05, 2018 7:47 am
by quyxkh
Watch the inserters, you can see that one lane's getting much more backpressure transmitted than its belt partner even though the items are moving at the same rate (and I think there "should" be no backpressure at all, since these are priority splitters with clear output paths, but I wouldn't call that a bug).
The effect shows up more subtly in the #4 inserter, but the traffic there is clearly identical in both lanes.
It took me al while to understand what you mean because at first I just looked at what the splitters do.
Especially when watching insterter #8 and the splitter above it I always see a free output on the splitter but still it somehow seems to decide to not accept input for a short time. This ist what you meant, right?
Another thing I noticed when watching Inserters #5 and #6: somehow the first steel of each "grab" of inserter #5 seems to jump ahead. (The alternative was the rest of the Items being blocked for a short time but that is impossible because then both inserters wouldn't be synchronous.)
Re: [0.16.22]backpressure glitch (?)
Posted: Mon Feb 12, 2018 2:29 pm
by kovarex
I don't understand this report, sorry. What is backpressure on a belt?
Re: [0.16.22]backpressure glitch (?)
Posted: Mon Feb 12, 2018 7:56 pm
by quyxkh
Sorry if I invented a term, I mean what happens when exit lanes are at capacity so the input lane traffic backs up. Watch the #6 inserter gradually get out of step with the one loading the other lane.
I think now that this is a not-a-bug, an accident of timing that I missed noticing, I can see that the lane merge makes the priority-merge splitters take different number of items per lane,
Re: [0.16.22]backpressure glitch (?)
Posted: Tue Feb 13, 2018 11:42 am
by seePyou
But there is nothing blocking inserters 4 and 8 and they are always free to insert steel on the belt! I do not understand why these inserters are going off sync with their "brothers". Can anyone explain?
Re: [0.16.22]backpressure glitch (?)
Posted: Tue Feb 13, 2018 1:22 pm
by Aeternus
There is something blocking them actually. The splitter they feed has one end of it's output blocked.
Re: [0.16.22]backpressure glitch (?)
Posted: Tue Feb 13, 2018 3:42 pm
by seePyou
So? If one end of a splitter is not blocked, it should not block the input at all! I was watching the animation closely, and the right side (as we see it) of the belt input and output of the right side of the splitter is always free. As such, inserters 4 and 8 should never be blocked? Maybe that is a defect in itself?
Re: [16.22] Belt back pressure inconsistency
Posted: Sat Feb 17, 2018 2:19 am
by Iccor56
remaking this gif with 'show info' on would be helpful
Re: [0.16.22]backpressure glitch (?)
Posted: Wed Feb 21, 2018 5:26 am
by Zaflis
Aeternus wrote:There is something blocking them actually. The splitter they feed has one end of it's output blocked.
The small S-curve between splitters at top left seems to be constantly free for items. I don't see why the 4th inserter desyncs with the rest. Is it maybe just because it is a turn? A straight belt would work but this not?
Re: [16.22] Belt back pressure inconsistency
Posted: Wed Feb 21, 2018 1:19 pm
by quyxkh
It seems to me now that if the splitter's chosen output lane for an item is busy and its buffer is occupied it takes a tick to switch. That seems fair enough. To keep the traffic flowing freely put four belt segments on the inserter-drop-to-splitter-input path, not just two. That fits in to most of my station designs without trouble and poses only solvable problems for the rest so I'm happy.:
Re: [kovarex] [0.16.22] Belt back pressure inconsistency
Re: [kovarex] [0.16.22] Belt back pressure inconsistency
Posted: Sun Mar 11, 2018 10:28 am
by kovarex
I re-tested this setup after making different (but related) bugfix of the input priority logic. And it seems to work properly now (by now I mean in the to be release 0.16.29)