Dry Ore Patch Train Restrictor

[SuicideJunkie]

I've made a little self-resetting restrictor for my ore patches that should be generally useful, particularly on maps with many small ore patches.
Suggestions for improvement are welcome.

The goal is:
1) Require the station to have at least a Minimum amount ore collected before inviting trains to visit.
2) When the patch is completely dry, allow one more train to pick up the remaining ore before closing "forever".
3) If the patch isn't quite done and the electric drills get reshuffled to extract a wee bit more ore (due to terrain limitations or tree protection), then the system should reset automagically.

Train Restrictor Logic

OrepatchRestrictor.png (223.65 KiB) Viewed 9295 times

Layout:
Top + : Wire up all the ore boxes to the adder. This adds EACH items to get a cumulative O-signal (ore), which means the blueprint works for any ore patch type without modification. Could be removed, if you are willing to do post-configuration or make multiple blueprints.
Upper *> : This is a direction detector which identifies whether the O has increased lately, and will latch a +1 output O if true.
Lower > : This is a secondary latch to latch the above +1 O.
Bottom * : Mulitply O by your minimum required ore (eg 1000), and output as M-signal (minimum required)
Stop : Enabled when raw O > M
Left side &=+ : Clock which outputs a Decrement signal every 1024 ticks. This will unlatch one (and only one) of the latches. If two Decrement pulses arrive before the next increment pulse, then the final latch resets and O goes to zero, setting the station to be open until dry since the latch O = 0.

Blueprint String

Code: Select all

0eNrtWFFvmzAQ/iuVHzeosCEkQdqkqX3tOlV9mypk4NpYIwYZUy2q+O+zoUkIIY3dNNvLXhKBfZ/v7rvvbPOCkryGUjAuUfSCWFrwCkU/X1DFnjjN9Tu5KgFFiElYIgdxutRPVDC5WIJkqZsWy4RxKguBGgcxnsFvFOHGOYohBWXcrWRR9gyJgSETBXcLAT0zf9TsmQlZqzcby26Ge9ezDJoHBwGXTDLoQm8fVjGvlwkIFcrWWgLkbrqASirIsqiUTcH1ejriy4mDVihy/cuJQleJ5JDq8UpPwPrnSQDw/hIsQ5GySplIaybbR9w8NI0OZuAF6XlB018u4xUIqUb2HCG7jmRMdH6gKBzB9be4daKg25l7mC7uIPGYa8GRqthD89Yekl3/gjZtUhR5nMCCPjNlrCy2qLEaztgmqY9MVDI2Zv0WdbyoKHW165iKEkQXcoQ+KYOilmVtB9mcQDZRZDuIHJw+NauNiS0B5DX9ewVyXgKApotdDrxdCj7/BQrwNucCsuMZd8ZhguFEZ3cVcoCrcON/BinLQLxJlNsx5Q2JIuNEvUKextLVHkXKw5KK1sMIfXkHR9cdZLlSntVcxo+iWMaMKwwUPdK8AisGZwdFNEIo9kwZNRTb1IrAdavzjDrdh/DXtrkKNIY1Qz2ev75Pi+/j+bgSyUBg+53UTKhDnNCmmIy7w0jVjRbTzLZzu+vdnTTn7dWDLoA94u/26m/fr99RIVeW3Xput2GGZmmfW6cd/6O0n74/njnj87f3wZkZIVovNtui16Pjf1u1aauhad8ctrBh45xa7cL4ozsnxta3jrZiAsOj1JkuHdjzvNOvHTeHNW1wBDom6YNnV0zG7u4HbheBkTTXfm1y/LeUeTOizGabJ+A0ySHOWKX/USRFDXoRtYQs4jb6V+05XS5inYsSLDy4R6ddHZ03FdZyqOHzLtGiFcCTPpFO5wRPwtl0gn1/ghUxSbvRUD0WzGeer8fVHw7CRuu0/fgS9T4UOSinCagY0a2Aix9UpouLe52EizuopGBpp79nEFV3rQwCEs79gExJ0/wB5S1H5Q==

[waduk]

This is EXACTLY what i need.
Thank you !

[mrvn]

Why not simply wire up the last few belts before the buffer chest in read-only/hold mode and then enable the station when:

a) buffer chest >= train size
or
b) (buffer chest > 0) && (belts == 0)

You just have to test how many belt pieces you need to connect so one ore is present with just the last mining drill working.

Personally I just use a) alone and enable the station for the last partial load by hand when I deconstruct the mine.

[mmmPI]

Why not simply wire up the last few belts before the buffer chest in read-only/hold mode and then enable the station when:

a) buffer chest >= train size
or
b) (buffer chest > 0) && (belts == 0)

That's nice when you are sure that power is constant, if it runs too low like 25% for 5 minutes, the mine will output too slow so the station may turn on/off for every ore of the last couple mines.

The more complicated contraption allow for configuration of the equivalent of the belt lengh being read, which is the 1024 ticks counter which you could then use with robots.

[slippycheeze]

Why not simply wire up the last few belts before the buffer chest in read-only/hold mode and then enable the station when:

a) buffer chest >= train size
or
b) (buffer chest > 0) && (belts == 0)

That's nice when you are sure that power is constant, if it runs too low like 25% for 5 minutes, the mine will output too slow so the station may turn on/off for every ore of the last couple mines.

The more complicated contraption allow for configuration of the equivalent of the belt lengh being read, which is the 1024 ticks counter which you could then use with robots.

Don't forget the third critical problem, which is that if while you have power fade and the miners are slow, biters eat the train line causing trains to route the long way around, slowing down operations!

[mmmPI]

wuut ? i was more thinking like when lots of turrets fire at the end of the night during which you built roboports for example, it's annoying enough to have a power shortage even temporarily that if it transform on train deadlock everytime that might not be good

Also if using robots to fill in the chest, you can't rely on material being on a belt before to know if the outpost is depleted or not, another use for this contraption in case it wasn't clear.

I do agree that using belts reading is the most straightforward approach but it's not always possible

[slippycheeze]

wuut ? i was more thinking like when lots of turrets fire at the end of the night during which you built roboports for example, it's annoying enough to have a power shortage even temporarily that if it transform on train deadlock everytime that might not be good

Much better explanation of the problem.

I'd agree that you need a secondary backup if you use these strategies; an "or time idle > 300" on the trains would solve most of the deadlocking issues, unless you are assuming the rail system would deadlock if all stations enabled at once or something?

[mrvn]

Why not simply wire up the last few belts before the buffer chest in read-only/hold mode and then enable the station when:

a) buffer chest >= train size
or
b) (buffer chest > 0) && (belts == 0)

That's nice when you are sure that power is constant, if it runs too low like 25% for 5 minutes, the mine will output too slow so the station may turn on/off for every ore of the last couple mines.

The more complicated contraption allow for configuration of the equivalent of the belt lengh being read, which is the 1024 ticks counter which you could then use with robots.

If it runs for 25% with 4 miners you still get the same ore as one miner running at 100%. So this would only affect mines with less than 4 miners. And worst that happens is an extra train is send. In your setup you also run into problems when the combinators loose power. Will it recover if some or all combinators run out?

But really? How many laser turrets do you have and how many aliens attack that your power drops from >100% to 25% for 5 minutes? You should really clear some space around your base to reduce the attacks. And build a lot more steam engines to produce power on demand.

Generally I try to keep my power production running at 50-75% of possible supply. If any more power is used then it's time to build more power.

[waduk]

@marvn:
Sigh, how do i explain this.
You should consider there are a lot of different play styles.
For instance, each of my mining outpost serves 16 loading station at the same time, with beacon and all.
Near the depletion, only few mines remaining, and since it serves 16 at the same time, they just can't keep up, even when being overwhelmingly surround by beacon; there's no more speed can be gained to keep up demand.

Your simple approach will make the station flicker on "my setup", even if i wire all belt.
Heck, if using bot based loading, the distribution is even more severe. Good luck trying to even hold a permanent value on the chest, the item will just come and come. Hardly anything stay for 1 sec in the chest.

So, when that happen, there's need to be a way to hold that flicker value, wait certain times if that value is really the last ore.
In short, you need a latch, and a reset-able auto timer to compare between interval.
If no changes happen; which mean the chest is either is full or there's no item is coming.

That's what this thread is all about.

-----

Anyway, back to original point.
I never thought to make use of 1 tick delay between negative and positive value.
Wow.

Btw, on my test there are some quirkiness with this design; where occasionally O>M for one tick.
Anyway, i fix that using another comparator (adding 2 combi), after the output.

Also, learn and inspired by this, i built my own detector. There's no need to enter the chest value/threshold (pro/ cons?)
And i can even attach the inserter as part of the "last ore" detector (while the original design seems didn't like about attaching the inserter as part of the total sum),
Cuz you know, occasionally, the last item is in the hand of the inserter, a leftover that wasn't being pick up by the last train.

Thank you @SuicideJunkie for making this, i learn a lot.

[mrvn]

@marvn:
Sigh, how do i explain this.
You should consider there are a lot of different play styles.
For instance, each of my mining outpost serves 16 loading station at the same time, with beacon and all.
Near the depletion, only few mines remaining, and since it serves 16 at the same time, they just can't keep up, even when being overwhelmingly surround by beacon; there's no more speed can be gained to keep up demand.

Your simple approach will make the station flicker on "my setup", even if i wire all belt.
Heck, if using bot based loading, the distribution is even more severe. Good luck trying to even hold a permanent value on the chest, the item will just come and come. Hardly anything stay for 1 sec in the chest.

So, when that happen, there's need to be a way to hold that flicker value, wait certain times if that value is really the last ore.
In short, you need a latch, and a reset-able auto timer to compare between interval.
If no changes happen; which mean the chest is either is full or there's no item is coming.

You seriously need 16 loading stations? The limiting factor becomes the train tracks there. A train track can have a LC train every 72 ticks. That is one train every 19.2 seconds at each station or 1666.666 ores a second for LC trains. Train stops can fill a train in far less than 19.2 seconds so they aren't the bottleneck. One should really build longer trains when one needs 16 loading stations with the increase in throughput that brings. But 1666.666 ores/s would be minimum speed so lets go with that. That's 111.111 yellow belts or 37 blue belts worth of ore. Must be some large ore field.

Now the issue: "Hardly anything stay for 1 sec in the chest."

Good that I didn't say to measure just chests. The condition is the chests are empty AND the belts too. Even if every ore is loaded onto a waiting train as soon as it comes in the belts would still be full of ore. Especially with beacons there won't be a large gap between ores on the belt even if only one miner still works. So nothing would flicker. The belts are your latch.

Also there won't be any train at the station keeping the chest empty. The whole idea was to only enable the station when the chests are full enough for a train or one last time when the mine is depleted. So no, the chest will not be empty. If they are then you didn't include enough belts in the logic or the miners got no power for too long [in which case the more complex combinator setup would also have problems]. Otherwise the chests will only ever be empty once, when the mine is depleted.

Second issue:

Near the depletion with 16 loading stations sharing the output it will take hours for each station to fill a train. In your setup argument the train sits there waiting for ore. Inefficient. That's not how my setup works. The station is only enabled when a train can be filled. It arrives, fills, leaves. Station stays dark until it can fill a train again or the mine is deleted. That was the idea behind the original post too I believe.

For the flicker you mentioned above the ore output of the outpost would have to get below e.g. 1 ore/s (depends on how many belts you wire to the detector). At that speed it would take over 8.888 hours to fill all 16 stations once. Do you really need 16 stations at that point?

I would add some circuit logic / priority splitters to the setup so that as the ore patch is reduced fewer and fewer loading stations receive ore until at the end only one loading station gets all the ore. It might be worth triggering the "one last time" for the stations at different times. So instead of checking for (belt == 0) check for (belt < N) where N increases the less priority the loading station has.

Or have one copy of the original combinator setup per stop so each triggers independently.

[mmmPI]

You seriously need 16 loading stations? The limiting factor becomes the train tracks there. A train track can have a LC train every 72 ticks. That is one train every 19.2 seconds at each station or 1666.666 ores a second for LC trains. Train stops can fill a train in far less than 19.2 seconds so they aren't the bottleneck. One should really build longer trains when one needs 16 loading stations with the increase in throughput that brings. But 1666.666 ores/s would be minimum speed so lets go with that. That's 111.111 yellow belts or 37 blue belts worth of ore. Must be some large ore field.

One can use 16 stations and 16 parralel tracks to deliver the iron everywhere in the factory

I'm not (just) being picky here, seriously i have attempted a game where i only had 1 patch of red science ore ( with a mod obviously) , all other things were normal, i just had 1 lonely gigantic but very poor patch of red science ore, and the challenge was to use it, at first it was easy, but the more i advanced in the game the further i had to mine from, and at some point it forces you to take the decisions of not scaling belts designs, but switching system using prod modules and spreading mines and using trains, that was fun.

Replace that with iron , and i understand the 16 loading station

Good that I didn't say to measure just chests. The condition is the chests are empty AND the belts too. Even if every ore is loaded onto a waiting train as soon as it comes in the belts would still be full of ore. Especially with beacons there won't be a large gap between ores on the belt even if only one miner still works. So nothing would flicker. The belts are your latch.

This can't work if your miners output directly into passive provider, and then robots brings things to requester and it gets loaded onto trains. You don't have any belts at all, so to know if the quantity is still increasing somehow, you would need to compare a chest quantity at 2 different moment.

Also there won't be any train at the station keeping the chest empty. The whole idea was to only enable the station when the chests are full enough for a train or one last time when the mine is depleted. So no, the chest will not be empty. If they are then you didn't include enough belts in the logic or the miners got no power for too long [in which case the more complex combinator setup would also have problems]. Otherwise the chests will only ever be empty once, when the mine is depleted.

This one got me thinking ( i feel like i'm seeing use case that your design is not covering ) WHAT IF : you had enough for 2 trains ? so 2 of them are waiting in line, the first one leave, the station stays open, the robots starts trying to refill the chests, the second train start getting loaded, which decrease the quantity in chest as inserter start swinging again, turning off the station. But at the same time you also have robots that were given enough time to fetch material and they start filling up the chests, re-opening the stations, until the next swing of the 12 stack inserters , which turns off the station, but the continous stream of robots re-open it just before the next swing of the 12 inserter and this creates a big mess ! with only 1 station it is kind of unlikely, but the more you have, the more chaotic the bots will look like.

( while keeping this assumption that the chest would never be empty because i couldn't find counter example )

For practical use i do not want to talk without seing the pratical cases , i just feel that you underestimate what the flicker-free design means, as some sort of guarantee against murphy's laws, for peace of mind or just for the sake of knowing that your design is "safe" for feeling of accomplishment, any design that has edge case in the factory pile up, and it's better to prevent those as much as you can just for when things goes wrong you have less place you need to debug or worry about.

Things that involve trains are usually the worst to debug ( in my eyes), unless you have the fire power to destroy trains, the non-destructive methods is tedious like manually moving them , ehhh.

[BlueTemplar]

Thank Wube for the Ctrl+click train move !

[mmmPI]

Thank Wube for the Ctrl+click train move !

That doesn't work in all case, i'd blame the murphy's law again, everytime a train will need manual intervention, it will be a one way train, stuck on a one way rail , blocking other trains stuck on one way rail , and none of them you would be able to move using ctr+click, because they couldn't go backwards.

Or you would have a train colliding with another train far away in the map, because one would stop in the middle of nowhere and start saying "no path" because one skipped station would have allow the train to reverse directions, but it flickered, and the station was skipped and the train crashed, and it destroyed one wagon. Which means you now need to find it set it automatic again but then cargo would be different from circuit condition in scheduled station, so it will wait forever unless you manually ask it to skip again another station, so it gets closer to main base, so you can add finally add that wagon.

I have imagination for how things can go wrong, fixes are fine, prevention is better which the design provide ! (unless sometimes when the fix involve a rocket launcher that could be discussed )

[waduk]

@mrvn:
Who said anything about the train waiting the train stop ?
Read the very first post.

1. Enabling the station when it reach the threshold. So no, the train will not waiting in the stop to load.
2. On the very last batch, it won't reach the threshold, so it will enabled the station for the very last load.
3. If we shifted the mines, new ore is coming, it can reset/start over again (back to rule 1)

Again, different playstyles.
Huh ? No, it won't took 8000 hours at all. I do this all the time.
With 24 blue belt coming in (the max i can fit in my layout), that's 1080i/s, i can clear out 10M ore in 2.5 hours.
But then i switch to bot based, it's even faster since the mines itself can produce more than 24 belt can handle.

Near the end the bot based will suffer an uneven distribution, so at the very worst case, the mines can only produce 45i/s.
Divide by 16 unload.
But in practice due distance and uneven distribution to requester chest, every now and then some station will only get them beyond 2 sec.

This combinator contraption can still working without belt to wire, aka if you use a bot based mining.
The original design use a 1024 ticks to check between value,
Initially i reduce it to use 120 tick, (because i want it to get enabled as tight as i could)
But then i noticed there's false positive, that's why i knew about the 2 sec interval on near depleted mines on my setup.
Now, i use 300 ticks.

....

I would add some circuit logic / priority splitters to the setup so that as the ore patch is reduced fewer and fewer loading stations receive ore until at the end only one loading station gets all the ore. It might be worth triggering the "one last time" for the stations at different times. So instead of checking for (belt == 0) check for (belt < N) where N increases the less priority the loading station has.

Or have one copy of the original combinator setup per stop so each triggers independently.

Basically you also need wiring the mines ? If not, how can you tell an ore yield is decreasing ?
No need for that, just plop the original combinator, it works.

[mrvn]

@mrvn:
Who said anything about the train waiting the train stop ?
Read the very first post.

1. Enabling the station when it reach the threshold. So no, the train will not waiting in the stop to load.
2. On the very last batch, it won't reach the threshold, so it will enabled the station for the very last load.
3. If we shifted the mines, new ore is coming, it can reset/start over again (back to rule 1)

Thanks for making my point. The argument was that the chests would be empty causing a flicker because items get loaded directly into trains. So unless the chests are full or the "mine is empty" has already triggered no train will be at the station emptying the chest as they get filled.

Again, different playstyles.
Huh ? No, it won't took 8000 hours at all. I do this all the time.
With 24 blue belt coming in (the max i can fit in my layout), that's 1080i/s, i can clear out 10M ore in 2.5 hours.
But then i switch to bot based, it's even faster since the mines itself can produce more than 24 belt can handle.

Again you misread what was written. And it has nothing to do with play style.

The argument was still that my setup would flicker the station on/off because the chests would be emptied by the waiting train and the "mine is empty" part would trigger. For that case the mine would have to be nearly exhausted and all your 24 blue belts would have to be empty of ore. But even if you only include one tile of each of the 24 belts in the circuit you would detect production of 1 ore/s. Therefore for the flickering to happen you would have to have less than 1 ore/s production from the mine. That leads to the insane waiting time.

Also my point was that it DOESN'T happen. So obviously it works all the time.

Near the end the bot based will suffer an uneven distribution, so at the very worst case, the mines can only produce 45i/s.
Divide by 16 unload.
But in practice due distance and uneven distribution to requester chest, every now and then some station will only get them beyond 2 sec.

This combinator contraption can still working without belt to wire, aka if you use a bot based mining.
The original design use a 1024 ticks to check between value,
Initially i reduce it to use 120 tick, (because i want it to get enabled as tight as i could)
But then i noticed there's false positive, that's why i knew about the 2 sec interval on near depleted mines on my setup.
Now, i use 300 ticks.

You are right. If you use a bot based design instead of the belt design from the first post then there will be no belts to use for my design. Your problem. The initial post was with belts and there my design still is far simpler. No way around some form of counter when all you have is logistic chests.

....

I would add some circuit logic / priority splitters to the setup so that as the ore patch is reduced fewer and fewer loading stations receive ore until at the end only one loading station gets all the ore. It might be worth triggering the "one last time" for the stations at different times. So instead of checking for (belt == 0) check for (belt < N) where N increases the less priority the loading station has.

Or have one copy of the original combinator setup per stop so each triggers independently.

Basically you also need wiring the mines ? If not, how can you tell an ore yield is decreasing ?
No need for that, just plop the original combinator, it works.
[/quote]

That stanza applies to both designs. Keeping all 16 stations active when the mine is near depletion is stupid. You spread the little production that's left over many stations causing trains to run very irregular. Worst case you get 16 full trains at the same time every 8000 hours or so.

[mrvn]

Also there won't be any train at the station keeping the chest empty. The whole idea was to only enable the station when the chests are full enough for a train or one last time when the mine is depleted. So no, the chest will not be empty. If they are then you didn't include enough belts in the logic or the miners got no power for too long [in which case the more complex combinator setup would also have problems]. Otherwise the chests will only ever be empty once, when the mine is depleted.

This one got me thinking ( i feel like i'm seeing use case that your design is not covering ) WHAT IF : you had enough for 2 trains ? so 2 of them are waiting in line, the first one leave, the station stays open, the robots starts trying to refill the chests, the second train start getting loaded, which decrease the quantity in chest as inserter start swinging again, turning off the station. But at the same time you also have robots that were given enough time to fetch material and they start filling up the chests, re-opening the stations, until the next swing of the 12 stack inserters , which turns off the station, but the continous stream of robots re-open it just before the next swing of the 12 inserter and this creates a big mess ! with only 1 station it is kind of unlikely, but the more you have, the more chaotic the bots will look like.

Luckily you can read the train contents and detect when a train is present. So when a train is present subtract a full train worth of items and add the train content to the chests. That gives you the amount of ore that will be left over after loading the train. Even more accurate include the hand contents of the inserters. Because otherwise the count could still fluctuate by the amount the inserters hold and flip between too low and just enough. Very unlikely but possible. If you include the inserters in the count you should have a tick-to-tick stable account of how much ore will be in the chests for the next train.

[waduk]

@mrvn:
Why you being rude ? It's up to anyone with whatever design they run with.
"Fun" is relative, it's not always about being efficient.

I can flip the argument and goes, why spread out for too many outpost ? If a few mining outpost can hold the production line?
For me it's easier to defend & manage, i can troubleshoot easily within few location instead traveling to 30+ different sites.
If those 16 loading near depleted, there always another sites they can visit.

In the end it's the same, regardless any approach a player take, there always be pro and cons.

Another thing on my side, one of the reason i want to clear the ore as fast as possible is because i would not built anything over an ore.
It's aesthetic decision, plus i don't want to use a mod to erase an ore.

And not every outpost have 16 loading station, some were just 2 or 4 loading station. Oil patch only have 1 loading station, and so on.

Simply put, it's not stupid.
If you still want to call it stupid, sure whatever.


But let's get back to original discussion, to be precise your original reply :

Why not simply wire up the last few belts before the buffer chest in read-only/hold mode and then enable the station when:

a) buffer chest >= train size
or
b) (buffer chest > 0) && (belts == 0)

You just have to test how many belt pieces you need to connect so one ore is present with just the last mining drill working.

Personally I just use a) alone and enable the station for the last partial load by hand when I deconstruct the mine.

Now, everyone here, including me point out that it will flicker (station will turn on and off)
Because this is what everyone is thinking, based on your design:

https://gfycat.com/embellishedblaringgerbil

Imgur Mirror, in case gycat is broken :
https://i.imgur.com/bH0wt5s.gifv

Top were Iron = 0, output A
Middle Iron >0, Output B
Right most A & B = Green

Bottom one is the threshold.
Iron => value = Green

Unless i'm incorrectly interpreted your first comment.
As you can see, it's flicking, It's not even an edge case scenario, just a typical ore run dry scenario.
And i even wiring two belt and the inserter that put the item to a chest as another safeguard.

Why don't you post your design, so we're on the same page.

[mmmPI]

Luckily you can read the train contents and detect when a train is present. So when a train is present subtract a full train worth of items and add the train content to the chests. That gives you the amount of ore that will be left over after loading the train. Even more accurate include the hand contents of the inserters. Because otherwise the count could still fluctuate by the amount the inserters hold and flip between too low and just enough. Very unlikely but possible. If you include the inserters in the count you should have a tick-to-tick stable account of how much ore will be in the chests for the next train.

That would make a more complicated design already maybe useful in other situations, or maybe you prefer it ( it seems you do ).

The original design allow you to configure the delay with just a slider for 1024 ticks if i understand it correctly, in your design that would mean rewiring some belts to adapt the lengh, and remath the ratio that you write in your combinator to prevent the flickering.
( many outpost = various number of belts/throughput vs many outpost = parameter 1 slider on each design)

I really think it is a question of playstyle. When i saw the original design in my head i went like "hey that's a thing i will remember" not the design itself, but the logic with 2 latchs and a delay to compare. I saw predictability and control. I don't leave comments on every design that inspire me, that would flood the forum but i wanted to express the differences that your proposed design have with the original design, because your proposed design @mrvn is what would be the most straightforward to me, how but op's design has more safety/ fool-proof, it uses a different logic that i understand but didn't thought about using. And i know/feel the weakness of the design you propose because this would be my go-to option most of the time. Except using it, you know there are conditions, edge cases, so you find other workaround, to balance mining, to balance station, to do other stuff so you can use the design you know. This one was new(to me), and has different set of conditions, such as working with robots ! ( and also guaranteeing that whatever you mess around the design won't flicker).

Now i have another new thing in my mind, summing up the train content + chest content + inserter holding + belts, that is what you propose, that is a lot of wire but it has some use case too

[mrvn]

@mrvn:
Why you being rude ? It's up to anyone with whatever design they run with.
"Fun" is relative, it's not always about being efficient.

I can flip the argument and goes, why spread out for too many outpost ? If a few mining outpost can hold the production line?
For me it's easier to defend & manage, i can troubleshoot easily within few location instead traveling to 30+ different sites.
If those 16 loading near depleted, there always another sites they can visit.

In the end it's the same, regardless any approach a player take, there always be pro and cons.

Another thing on my side, one of the reason i want to clear the ore as fast as possible is because i would not built anything over an ore.
It's aesthetic decision, plus i don't want to use a mod to erase an ore.

And not every outpost have 16 loading station, some were just 2 or 4 loading station. Oil patch only have 1 loading station, and so on.

Simply put, it's not stupid.
If you still want to call it stupid, sure whatever.

I'm not trying to be rude and I'm not saying that using 16 loading stations on a huge beaconed mining outpost is stupid. Only thing I called stupid is, in this context, keeping those 16 loading stations when you are down to the last few miners. You are optimizing each station to be super efficient and only have full trains but you forget about optimizing the mining outpost as a whole.

I'm also not saying you can't play that way. You can put a rocket silo in a wooden chest and shoot it till it explodes for all I care.

But as you say let's get back to the original discussion:

But let's get back to original discussion, to be precise your original reply :

Why not simply wire up the last few belts before the buffer chest in read-only/hold mode and then enable the station when:

a) buffer chest >= train size
or
b) (buffer chest > 0) && (belts == 0)

You just have to test how many belt pieces you need to connect so one ore is present with just the last mining drill working.

Personally I just use a) alone and enable the station for the last partial load by hand when I deconstruct the mine.

Now, everyone here, including me point out that it will flicker (station will turn on and off)
Because this is what everyone is thinking, based on your design:

https://gfycat.com/embellishedblaringgerbil

Imgur Mirror, in case gycat is broken :
https://i.imgur.com/bH0wt5s.gifv

Top were Iron = 0, output A
Middle Iron >0, Output B
Right most A & B = Green

Bottom one is the threshold.
Iron => value = Green

Unless i'm incorrectly interpreted your first comment.
As you can see, it's flicking, It's not even an edge case scenario, just a typical ore run dry scenario.
And i even wiring two belt and the inserter that put the item to a chest as another safeguard.

Why don't you post your design, so we're on the same page.

You nailed the design. It is that simple. Except the reason why it flickers is that you only wired up 2 blue belts. That's like setting the timers in the combinator design to 5 ticks. You need to add more belt tiles. Enough to cover the distance between 2 ores. In your example the belt isn't long enough for that. Usually I have far longer belts going from the miners to the train to get the output of the whole patch into one place. So that isn't a problem. If you add beacons you need less belt tiles. Or with red or yellow belts.

The original design allow you to configure the delay with just a slider for 1024 ticks if i understand it correctly, in your design that would mean rewiring some belts to adapt the lengh, and remath the ratio that you write in your combinator to prevent the flickering.
( many outpost = various number of belts/throughput vs many outpost = parameter 1 slider on each design)

Note quite. The number of belt tiles you need depends on only two things: 1) the belt speed, 2) the mining speed of the last miner. You need to connect enough belts so that with just one miner working there still always is one ore in the covered section.

Personally I simply connect the chest to the train stop and set it to enable when it has a full load. That takes 0 combinators. I really don't care about the last partial load. Exhausted mining outpost will be deconstructed at some point and then I enable the station one last time manually. So this is more of an academic issue.


Concerning taking train contents into account while loading: I also did a more complex design for higher throughput unloading stations with a waiting bay. The station will allow one or two and only two trains into the station depending on the amount of space for ore. All other trains with be redirected to other stations:

viewtopic.php?f=194&t=48069&p=277977&hi ... on#p277977

Feel free to change this for loading and combine it with the "Dry Ore Patch Train Restrictor" of either design for the ultimate station.

[waduk]

So it's not a new approach at all. I've do that in the past.
It's prone to false positive, that's what everyone trying to say here.
The only bulletproof way is to wire the belt all the way through every miners.
And it's not applicable on bot based setup.

If it's working in your setup, that's good. But it's not for me, thus why i revived this old thread.
The contraption that OP posted is good, easy to understand. And i built my own version based on this design.

Sigh, you really have to touch that 16 loading subject again...
It's the same. If you use 16 different outpost, i just put them in one place.
Like i said, it's easier for me to defend, managed and travel.
The end result is the same, the factory still got a steady line of supply.
The inefficiency you mention about the stop is still open / not disabled despite ore near depleted is not an issue to be worth being addressed at all.
In real time, is only happened in the last half hours or so. Hardly noticeable.