So I got inspired by AntiElitz's new smelter and figured I'd have a go at putting together something using the same principles. I think I've made it simpler and more robust than his (and with less wiring), so I figured I'd share.
Only yellow belts and no combinators:
Sushi_smelting.png (5.12 MiB) Viewed 1194 times
The basic thing to realise is that a single steel smelter uses slightly more iron or copper ore as a full line of 24 steel furnaces uses in coal, so if you feed the first smelter fuel directly then you can feed all the others using the gaps in the ore that it creates. Which lets you run a full 48 steel furnace block off nothing but yellow belts.
This design also works when the furnaces are stone, but has a few gaps that I haven't been able to clean up that I consider an acceptable compromise for not needing to mess about with upgrade planners that I can't swipe over the whole array.
The red wire turns the whole thing off if there's not enough fuel, as it will jam if the last belt gets filled with ore.
The green wire turns off the coal feed if coal is backed up too much. Otherwise the coal jams the inner lanes.
All the yellow input inserters have their stack size set to 1. Because not doing that starves the second half of the build.
There's a very long cycle issue where a single smelter can run out of fuel, and another long cycle issue where the last smelter doesn't get ore, but they only cost about 10 plates every 10 minutes or so, and my attempts to fix that so far have caused collapse states where half the smelters run out of fuel instead.
And I even managed to fit in lights. Because who doesn't like lights?
Very interesting. The challenge is to get a delicate balance between ore and coal on one lane, while you cannot fully control from which lane inserters will grab the ore. Usually it's the near lane first, but if gaps get too big inserters will also pull from the far lane. And the latency between detection of "we have too much coal" and "get rid of too much coal" is very big.
Illiander42 wrote: ↑Mon May 27, 2024 6:21 pm
All the yellow input inserters have their stack size set to 1. Because not doing that starves the second half of the build.
This is because with larger stack sizes the gaps on the near lane get so big, inserters on the first half of the belt will pull from the far lane that is primarily reserved for the second half of the belt. So it not only makes the second half starve for ore, it will also make the first half starve for coal later, because the near lane will eventually stall and eliminate gaps intended for coal.
Re: Has anyone posted sushi-smelting here yet?
Posted: Mon May 27, 2024 9:34 pm
by Illiander42
Tertius wrote: ↑Mon May 27, 2024 7:25 pmwhile you cannot fully control from which lane inserters will grab the ore.
You actually can if you wire the inserter to the belt it takes from with an inserter condition of "ore > 4" but when I do that it becomes much less stable on keeping the smelters fueled, and has a much harder time starting up, so the stack size 1 is the compromise.
Unless there's a way to tell the inserter "sum of items >4" its going to be an issue one way or another without combinators.
Tertius wrote: ↑Mon May 27, 2024 7:25 pmAnd the latency between detection of "we have too much coal" and "get rid of too much coal" is very big.
Pretty sure that's what causes the occasional issues it has. The ratio is a nightmare.
Tertius wrote: ↑Mon May 27, 2024 7:25 pm
it will also make the first half starve for coal later, because the near lane will eventually stall and eliminate gaps intended for coal.
Only when the whole array is massively backed up. And interestingly, in that situation is matters that inserters take from the left end of the belt lane as they look at it, because the gap closes on the top of the build before coal gets into it, but not on the bottom half.
Re: Has anyone posted sushi-smelting here yet?
Posted: Tue May 28, 2024 6:31 pm
by Tertius
I played around with this contraption and changed the control concept. I don't know if I reinvented what you referred to in your OP, but here it is anyway.
The major change is that I keep an inventory of all items on the belt, not just peeking at 4 selected tiles. This way I just control "insert more coal if there is less then 60" and "stop ore, if less than 40 coal on the belt". It's not necessary any more to limit the stack size to 1, because there can be less coal on the belt, so the inner lane doesn't stall so fast.
The cost is 2 combinators per belt to keep track of the items on the belt.
This is a comparison of your belt-reading production line (top) and my item-counting production line (bottom) after perhaps 1 hour of runtime. The numbers in the Nixie tubes are just the plates counted from that row.
I randomly stopped coal or ore (half or fully) for 5-10 minutes to simulate unreliable supply. Both top rows produce less than their corresponding bottom rows, because on coal stop, the top rows starve earlier. While doing all this, my production line seems to have a ~10% higher throughput in the long run.
Screenshot 2024-05-28 202951.png (3.67 MiB) Viewed 1051 times
Tertius wrote: ↑Tue May 28, 2024 6:31 pm
The cost is 2 combinators per belt to keep track of the items on the belt.
Well if you're going to allow combinators then it becomes really easy because you can just use the ratio, or count when an inserter takes a coal, or a hundred other ways.
The hard thing is having the blueprint work with just red techs, and a single base-wide upgrade planner to steel furnaces.
Of course, if you just want a belt inventory, you don't need the combinators for that here, you can just wire the whole belt because the bit you're interested in doesn't have any undergrounds or splitters.