Smart/multitask furnaces

[rk84]

Thanks for MeduSalem showing his layout. It inspired me to play around with this. It was quite a pain to set up, but now I can make blueprint
(508 smart inserters to set working condition)

EDIT: Savefile: v0106c.zip

Furnace area at night. Low stone count so stone brick production have shutdown.

smart-furnaces.JPG (203.93 KiB) Viewed 16291 times

Logic Blocks
"Only" 116 circuit wires, but single block can control multiple furnace areas.
In this prototype signals are set in 1k itemcount intervals. Below 1000 => signal 14, tries to use all furnace and above 14000 => signal 0, stops.
Science packs are used as signals via wireless logistics. (Red - Iron, Green - Copper, Blue - Steel, Purple - Stone)
Rows of chests shows nicely what phase is going on. Steel and stone bricks has additional limiter to prevent iron or stone count to sink too low. Specially steel could eat it self to death by hogging furnaces from iron. Low item count for steel and stone can also clog the system, because of 5 item requirement. Stone is also faster then steel so it needs bigger stack request then steel.
Player can also manually increase signals by placing science packs to logicstic chest in anywhere in area. If you forget steel on, don't worry limiter will take care of that too. In another words bots will collect all chosen science packs in area.
By forcing max signal I was able to get around 3800 iron/min (98 furnaces, 300 bots, no modules)

furnace-logic-blocks.JPG (132.38 KiB) Viewed 16291 times

Iron ore distribution pattern
All ores have same shape pattern just different starting corner. Numbers presents the signals that "activates" above line of furnaces.

furnace-ore-pattern.JPG (256.12 KiB) Viewed 16291 times

[DerivePi]

OK, I think I have my head around it, but let me get some clarifications:

As shown, you have between 6 to 7,000 FE Plate in storage and only FE rows (up and to the left) 1 through 8 are allowed to produce FE Plate. This follows:
with 5 to 6,000 CU Plate with CU rows (down and to the right) 1 through 9 allowed to produce CU Plate.
with 2 to 3,000 Steel with Steel rows (left and then down) 1 through 12 allowed to produce steel.
and brick is off (no furnaces is allowed to produce brick) due to insufficient supply of stone.

Once a furnace starts producing FE Plate it will continue (be stuck) producing FE Plate until the logic system prevents that furnace from being fed FE Ore. Same thing with all of the materials. The Row 1 furnace for each material will probably always be "stuck" producing that material. I don't see this as a problem, just noting it because there will be the potential for an initial start up phase where material smelting will be a little unbalanced. This could be devastating for stone and steel after they are turned back on after low supply (i.e. when stone and steel need to ramp up, they can't because FE and CU Plate production prevents them from accessing the furnace).

Let's say a furnace is fed one stone and then, while waiting for a delivery, the logic system disallows further brick production. What happens? Same thing with steel.

Thank you for an excellent post!

[rk84]

OK, I think I have my head around it, but let me get some clarifications:

As shown, you have between 6 to 7,000 FE Plate in storage and only FE rows (up and to the left) 1 through 8 are allowed to produce FE Plate. This follows:
with 5 to 6,000 CU Plate with CU rows (down and to the right) 1 through 9 allowed to produce CU Plate.
with 2 to 3,000 Steel with Steel rows (left and then down) 1 through 12 allowed to produce steel.
and brick is off (no furnaces is allowed to produce brick) due to insufficient supply of stone.

I think you have these numbers/signals inversed or I have (the case in picture), but anyway that is possible situation.

Once a furnace starts producing FE Plate it will continue (be stuck) producing FE Plate until the logic system prevents that furnace from being fed FE Ore. Same thing with all of the materials. The Row 1 furnace for each material will probably always be "stuck" producing that material. I don't see this as a problem, just noting it because there will be the potential for an initial start up phase where material smelting will be a little unbalanced. This could be devastating for stone and steel after they are turned back on after low supply (i.e. when stone and steel need to ramp up, they can't because FE and CU Plate production prevents them from accessing the furnace).

I don't see them as stuck since they are just in use. First come, first served. But yes it is bit unbalanced like you say, but I hope some interval tweaks to match the resource type will help some degree. I admit this design can't fully utilize every single furnace and if one resource is taking over all furnaces all the time only option is to place another furnace area. But that will increase idle furnaces too... patterns work independently now. I think I have get them to work together somehow to maximise furnace usage until out of storage.

Let's say a furnace is fed one stone and then, while waiting for a delivery, the logic system disallows further brick production. What happens? Same thing with steel.

My head went bit haywire with stone. For some reason I was thinking its same as steel, mayby I mixed it to wall recipe. So 2 stones is one brick and that does not work, because inserter stacksize bonus does not match. I tested max brick production and after that half or more furnaces were clog
I can think of some space wasting solution, but don't know if it is worth just for stone.

Steel works ok as long as require chest has >= 5 iron plates and stacksize bonus is maxed. (must have plates available in storage, require stacksize high enough to give bots time to react and enough bots to move items)

Thank you for an excellent post!

I'm glad you liked.

[MeduSalem]

To rk84: Woah ... Glad I could inspire you to extend on my initial thought. xD

Once a furnace starts producing FE Plate it will continue (be stuck) producing FE Plate until the logic system prevents that furnace from being fed FE Ore. Same thing with all of the materials. The Row 1 furnace for each material will probably always be "stuck" producing that material. I don't see this as a problem, just noting it because there will be the potential for an initial start up phase where material smelting will be a little unbalanced. This could be devastating for stone and steel after they are turned back on after low supply (i.e. when stone and steel need to ramp up, they can't because FE and CU Plate production prevents them from accessing the furnace).

I don't see them as stuck since they are just in use. First come, first served. But yes it is bit unbalanced like you say, but I hope some interval tweaks to match the resource type will help some degree. I admit this design can't fully utilize every single furnace and if one resource is taking over all furnaces all the time only option is to place another furnace area. But that will increase idle furnaces too... patterns work independently now. I think I have get them to work together somehow to maximise furnace usage until out of storage.

For smaller setups like for example 10x10 or 12x12 (but also for bigger setups once you are draining more iron/copper plates) this can lead to a massive problem pretty soon, because the permanent FE&CU parts may begin to overlap in "first come, first serve" patterns in the middle and then will sidestep to another free furnace next to it in the same line... eventually hogging the starting positions of steel and stone preventing them from ever being used by steel and stone.



That's the main reason why I set my smart "input"-inserters (the ones feeding ore to the furnaces) to only put something into the furnace as long as the "output" chest (the one where the finished plates/bars/bricks are dumped in) is empty of that corresponding plate type.

Since the crafting is not instant and since there's the unavoidable stack bonus of inserters the furnace will always have some rest ore. This rest ore will be be smelted while a robot will come to grab the plate(s) from the "output" chest. Then one of the following three will apply:

a.1) The bot takes too long to pick the plates up and the furnace will eventually run out of rest ore and the "output" chest is empty of another plate type then the waiting "input"-inserter of the other ore type gets the chance to dump its ore into the furnace thereby forcing a context switch and load rebalance.
a.2) The bot takes too long to pick the plates up and the furnace will eventually run out of rest ore but the "output" chest is full of each Iron/Copper Plates as well as Steel Bars and Stone Brick, so none of the inserters will dump anything into the furnace and the furnace goes into idle mode.
b) The bots are too fast, mainly because the particular output stream leaving the furnace area and leading to the storage system is nearby. Then the bots will always grab the plates before the furnace runs out of excess ore thereby "assigning" this furnace to this plate type until the demand shrinks.

So this will lead to following: The furnaces next to the output stream of a particular plate type will always be hogged by that same particular plate type because bots tend to pick up from the nearest providing source available. The further away a furnace from the output stream the more penalty it gets thanks to bot travel distance. This is my way of keeping plates in one particular corner/edge of the furnace-array without using a complex circuit logic. ^^

And even if the consumption of one particular plate type grows and it starts to clog the furnaces next to the output stream of another plate type it doesn't matter at all because then a combination of a.1) & b) will apply. The travel penalty of the wrong plate will give the right plate the chance to reconquer its nearest furnaces after a few seconds. This method ensures that the distribution ratio and location will always be fair & correct with a marginally delay.

Here's my initial setup which inspired rk84 once again so people don't have to go look into the other thread^^

Latest Iteration:

014.jpg (672.58 KiB) Viewed 16190 times

Earlier belt test setups (got only pictures from what I used for the blueprints):

012.jpg (156.5 KiB) Viewed 15588 times

013.jpg (180.94 KiB) Viewed 15588 times

They all lack layout optimization because I paid more attention to a proof of concept rather than space optimization... in an upcoming build I will try to squeeze stuff together if possible and if still looking "fine" to my standard of quality. xD

Let's say a furnace is fed one stone and then, while waiting for a delivery, the logic system disallows further brick production. What happens? Same thing with steel.

My head went bit haywire with stone. For some reason I was thinking its same as steel, mayby I mixed it to wall recipe. So 2 stones is one brick and that does not work, because inserter stacksize bonus does not match. I tested max brick production and after that half or more furnaces were clog
I can think of some space wasting solution, but don't know if it is worth just for stone.

Steel works ok as long as require chest has >= 5 iron plates and stacksize bonus is maxed. (must have plates available in storage, require stacksize high enough to give bots time to react and enough bots to move items)

That's the real problem about the whole system when incoroprating Stone and Steel as well. But I handle that with the "input"-requester-chests.

For example for Stone I never request more than 4 (I could request exactly 2 but I'll get 4 anyways due to robot cargo size) stone to this chest. Not 1 because it wouldn't work obviously, not 3 or 5 because I don't want to leave the furnace with an odd number of stone, not more than 5 because the inserter stack bonus creating even more unpredictable problems. So this ensures when the furnace begins to smelt stone it will always end up with 0 excess stone in the furnace. Obviously this method creates a little additional delay since the bots have to fly around and gather more stone on demand and in the meantime while waiting on more stone the furnace will perform a context switch to smelt something else until it may return to stone. But this is the beauty of the whole system... there are so many other furnaces in parallel doing the same thing that eventually one has stone bricks left to grab thereby "hiding" the supply delay.

For Steel this method doesn't work too well and the solution gets even uglier, because even If I'd request 5 iron bars to the "input"-chest the bots will deliver 8 due to maxed out robot cargo size. Sometimes even other awkward numbers because of it depending heavily on how much iron plates there are in the "output" chests of other furnaces, which might be actually less than the 4 the robot is capable of. This could eventually leave me with insufficient iron plates in the furnace, thereby rendering it stuck since the "input" inserter doesn't take more as long as the steel bar in the "output" chest is blocking the input.

So the way I'm handling that is that I request at least 20 or any other multiple of 4 & 5 trying to profit of all three effects (robot cargo size 4, inserter stack size 5 and that steel bars need 5 iron plates to craft) so that no matter what the furnace would be able to smelt all the excess plates left in the "input"-chest into steel bars without leaving an insufficient number of iron plates in the furnace. To further ensure that there's never a situation with insufficient iron plates blocking the furnace from unloading and performing a context switch you can increase the number of iron plates stored locally in the "input"-chests so that even if there's a spike in steel bar demand where your other furnaces couldn't keep up with the iron plates production the buffer in the chests will help overcome those spikes. But just let me say this... if those buffer chests are ever running empty you are doomed. xD

[-root]

Ok, so this is a really freaking cool idea that is right up my alley I'm going to make a video about it and see if I can get it to work

[ssilk]

Must say a bit about that: I tried such a setup for about 20 or 25hours. With nearly equal solutions like found here, but also quite different setups. But in no case I found a way which prevented the blocking by guarantee. There where always the problem, when "switching" the type, that there where some furnaces, which where clogged.

My current favorite of smelting setup is a mix out of logistics and belts, where the belts deliver about 80- 90% of the needed materials as near as possible to the furnace-block and from there it is put into requester chests, where one chest feeds 4 furnaces. The furnaced material is then moved back into requester chests by bots and transported by belts to its destiny.

In other words: I set up so many furnaces on so dense space, and made the transport with robots so cheap, that it will smelt up to 20000 items per minute continuous load per item type. I found no way, to "overload" it yet, and it is quite reliable.

[MeduSalem]

Must say a bit about that: I tried such a setup for about 20 or 25hours. With nearly equal solutions like found here, but also quite different setups. But in no case I found a way which prevented the blocking by guarantee. There where always the problem, when "switching" the type, that there where some furnaces, which where clogged.

With Iron and Copper plates alone it can be guranteed.

With Stone bricks added to the mix it can be guranteed as well as long as the requester chest never contains more than 4 stone (just request 4 stone to the chest with maxed out robot cargo size) at any given time as well as long as it doesn't contain an odd number of stone. As long as you have enough raw stone to supply the demand you are good to go. But I see no reason to produce more stone bricks than I actually need walls so this is something that only runs on demand anyways so I'm pretty sure I'll always have enough stone to provide the demand. ^^

The problem is the steel bars. They can only be made semi-secure by various ways:

1) Either have enough furnaces being able to smelt iron plates in real time so that at no time the demand of iron plates used for steel bars is higher than what the furnaces are able to produce and of course never run out of iron ore.
2) Working with a buffer in the requester chest so that even if there are small spikes in steel consumption where your furnaces couldn't keep up with the demand then the chests will hide the spikes and the furnaces will catch up again once the spike is gone.
3) Limit the steel bar production altogether to a reasonable amount.

I'm doing a combination of all three.

I only use 2 inserters that output steelbars to a belt so that's the highest production rate of steel plates possible in my factory at any given time. I could set it higher though, my furnaces would be able to support at least 4 inserters, maybe even 6, but I never really stresstested it but I guess I'd start to notice that the amount of iron plates wandering off to the storage facility would heavily suffer under this load. I've also a buffer of 100 iron plates per furnace, which I also could set much higher but since I'm still experimenting around a little bit it would be too bad if I would have to move 56*4800 plates somewhere else.


I have thought of an additonal way of security... Since I'm using a 24 million Iron Plates Storage facility (currently filled with 6mio plates) I could transport some of the iron plates stored there back to the furnace area and have a passive prodivder chest there to increase the provided iron plates "buffer" to my complete storage capacity. But it would need some fiddling or logic system so that the plates from the passive provider chests aren't re-entered into the requester chests leading to the storage facility again creating an endless loop. Normally if I'd place that provider chests on the far opposite side of where the requester chests are then the bots should take the iron plates from the furnaces first and only from the passive chest coming from the storage facility if the furnaces don't provide enough since the bots want to provide requester chests with the nearest passive chest available... at least if they have more choice than what's needed. That's something I might actually try out given enough time. ^^


But all this works only with inserters being able to move 5 items at once and robots being able to grab 4 items at once. For inserters and robots on other research levels the numbers would have to be adjusted and for some research levels it might actually be impossible.

[skomick]

@rk84 and @MeduSalem (et. al.) Hey guys! Beautiful looking setups! I am thoroughly intrigued! But I am more of a hands-on type of guy, so is there any way you could provide a save game for me (and others) to check these out? (If I would need mods installed that would be no problem, but that doesn't seem to be the case.) With these explanations along with an interactive experience, I'm sure I could get a much better grasp of logic and logistics setups such as these and in general (even though these look quite advanced). In any case, thanks for the inspiration, guys!

[rk84]

Thanks for the help. It fixed the stone issue. Now I'm trying to come up new idea to control active furnaces. Like if every furnace had a number (from 1 to max count of furnaces) that activates it. And some how every ore type would get range of numbers to loop activate furnaces.

@skomick
I uploaded the file and added link to beginning of first post. No mods.
You will need to start some process to get some activity. For example increase limit of smart inserter that is output for underground express belt assembler.

Edit: There is still some single clogs, but it is not bad as before.

[ssilk]

With Stone bricks added to the mix it can be guranteed as well as long as the requester chest never contains more than 4 stone (just request 4 stone to the chest with maxed out robot cargo size) at any given time as well as long as it doesn't contain an odd number of stone. As long as you have enough raw stone to supply the demand you are good to go. But I see no reason to produce more stone bricks than I actually need walls so this is something that only runs on demand anyways so I'm pretty sure I'll always have enough stone to provide the demand. ^^

It cannot be guaranteed, cause it can happen, that some provider chest as odd numbers inside (1 or 3 stone) and then the bot brings also only 1 or 3.
There is no way to guarantee anything, if a furnace needs > 1 item.

[-root]

So I just rebuilt this live on twitch. Took me nearly 3 hrs to do on a much smaller scale with only copper and iron.

This is some next level stuff right here. Medusalem & Rk, props. Mad props. You've just set a new bench mark for super-psycho builds!

I'll be putting out a youtube video detailing the build and how it works.

[MeduSalem]

@rk84 and @MeduSalem (et. al.) Hey guys! Beautiful looking setups! I am thoroughly intrigued! But I am more of a hands-on type of guy, so is there any way you could provide a save game for me (and others) to check these out? (If I would need mods installed that would be no problem, but that doesn't seem to be the case.) With these explanations along with an interactive experience, I'm sure I could get a much better grasp of logic and logistics setups such as these and in general (even though these look quite advanced). In any case, thanks for the inspiration, guys!

I'd like to but with the slow upload rate of my internet connection it would take nearly forever to upload that huge thing somewhere... -_- ^^

Thanks for the help. It fixed the stone issue. Now I'm trying to come up new idea to control active furnaces. Like if every furnace had a number (from 1 to max count of furnaces) that activates it. And some how every ore type would get range of numbers to loop activate furnaces.

Glad I could help. ^^

It cannot be guaranteed, cause it can happen, that some provider chest as odd numbers inside (1 or 3 stone) and then the bot brings also only 1 or 3.
There is no way to guarantee anything, if a furnace needs > 1 item.

Well it's not a 100% gurantee but I'd say 99.99999%. It's near to impossible that my stone provider chests would only have 1-3 stone inside ever. I've 6 provider chests feeded by fast inserters from an express belt filled up with stone being backed up by another 12mio stone storage system nearby which is currently filled with about 3.5 mio stone if not more (haven't checked the storage lately but it might be even fuller). I'm literally getting choked with resources on that map, which is my own fault since this test map is one of my earlier ones where I did not know how to make some "nice" decisions during map creation.

The chance that I'm running out of stone in the provider chests is converging to zero since I'm producing bricks only on demand rather than constantly, since I might end up with millions of bricks with no stone left to make more rails to expand the network...

That's the same reason as to why I won't overproduce steel bars... because I might end up with millions of steel bars but no iron plates left for everything else.

I know it does save space by compression but there are not enough consumers for Steel Bars and Stone Bricks in my opinion to make it worthwhile to do it; so that will always stay something I will only produce on demand with a little output buffer of 4800-9600 bars/bricks (so 1-2 full chests of each) or something like it. And they will be refilled over time if there are spikes in the demand which the production couldn't keep up with.

If there would be a way to get iron plates back from steel plates and stone from stone bricks by the same ratio... like getting 5 iron plates for each steel bar then I would actually compress all iron plates into steel bars and decompress them when I need them. xD

At least I make sure that the consumption never surpasses the production rate or only during small spikes I can live with. Overproducing stuff carelessly where you might run out of resources and gaining too much of something you don't need anyways will lead to problems no matter which setup you are using.

So I just rebuilt this live on twitch. Took me nearly 3 hrs to do on a much smaller scale with only copper and iron.

This is some next level stuff right here. Medusalem & Rk, props. Mad props. You've just set a new bench mark for super-psycho builds!

I'll be putting out a youtube video detailing the build and how it works.

Thanks ^^

I'll be watching the video once you link it.



If it were possible to set a schedule in assemblers as well... like 2 or 3 types of items that may be produced depending on which source materials you feed it then I might actually expand the idea there as well because I've too many assemblers just idling and doing nothing or only every once in a while.

... but that's just a dream of mine. xD

[ssilk]

Well it's not a 100% gurantee but I'd say 99.99999%.

Sorry, but a guarantee is 100%. And btw. it is not 99.99999%, it is more like 99.9%, cause it might happen, if any chest gets empty.

But - well - that is different thinking of Germans: "When does the bad thing happen?", instead of "How long does it work without happening something bad".

[MeduSalem]

Sorry, but a guarantee is 100%. And btw. it is not 99.99999%, it is more like 99.9%, cause it might happen, if any chest gets empty.

But - well - that is different thinking of Germans: "When does the bad thing happen?", instead of "How long does it work without happening something bad".

I understand that concern and it is fully legitimate. ^^

I have found a solution to the empty chests... just by preventing the "input" inserters (the ones emptying the requester chests and dumping stuff into the furnaces) from running when the provider chests are about to run dry (simple logistic network check in my case). This way neither the requester nor provider chests ever get empty even if you run out of stone or iron ore/plate supply. The production will then halt and wait until the contents of the provider chests raise above the threshold again. xD

That way you ensure that once the robots arrive at the provider chests that they will always have at least enough resources that they can pick up 4 at once.

That's the failsafe if you really somehow managed to run out of stone/iron plates ever. The same goes for iron ore and copper ore even it wouldn't be necessary for them.^^

Actually this failsafe works quite well...

I've 98 furnaces... which basically means 98 * 4 (robot cargo size) = 392. I set the inserters which dump the iron plates into the furnace for steel bars to only work when there are above a total of 400 iron plates in the logistic network distributed over all the output chests of other furnaces and in a small provider buffer chest holding additional plates (this one is coming back from my storage facility containing iron plates and since they are passive chests they have a lower priority than the active provider output chests next to the furnaces, thereby bots will only take stuff from the storage facility when the active provider chests next to the furnaces are empty.

I did basically the same for the stone inserters as well and for iron ore and copper ore... just to test things.

I could set the number higher for additional security if I would be doubtful, but it should work just fine with that since I let it run on maximum output rate of steel plates possible and the iron plate requester chests never ran dry, nor did the iron plate provider chests. They didn't even go below the local buffer stored in the requester chest because they are refilled at the same pace as the plates are consumed. ^^

So if even if the steel demand is very high they can't consume more than what is available and they will always leave some more plates in the provider chests so that there's never any odd number in the chests, which is especially important for stone.

[-root]

Ok, best place to watch it is probably twitch.

VOD on Twitch

The youtube video is blocked in some countries.

[Phillip_Lynx]

... The youtube video is blocked in some countries.

Surley because of the music you played during the stream

[ssilk]

I have found a solution to the empty chests... just by preventing the "input" inserters (the ones emptying the requester chests and dumping stuff into the furnaces) from running when the provider chests are about to run dry (simple logistic network check in my case). This way neither the requester nor provider chests ever get empty even if you run out of stone or iron ore/plate supply. The production will then halt and wait until the contents of the provider chests raise above the threshold again. xD

That way you ensure that once the robots arrive at the provider chests that they will always have at least enough resources that they can pick up 4 at once.

Well, might be, that you are right. My concern was about the moment when one provider/storage chest runs dry. There could be 1 or 3 items left in the chest and the bot picks them up and drops it in the requester and brings your counts in it from even to odd. I admit, that I never tested, if that can really happen, but I think it can.

Edit: The fact that it didn't happen yet is eventually, because I think, that the chests might never have odd values in it. So a good next question is: does it happen, if the chest contain an odd value? And if yes: How can a chest contain odd values?

[MeduSalem]

Well, might be, that you are right. My concern was about the moment when one provider/storage chest runs dry. There could be 1 or 3 items left in the chest and the bot picks them up and drops it in the requester and brings your counts in it from even to odd. I admit, that I never tested, if that can really happen, but I think it can.

Edit: The fact that it didn't happen yet is eventually, because I think, that the chests might never have odd values in it. So a good next question is: does it happen, if the chest contain an odd value? And if yes: How can a chest contain odd values?

Yupp if only 1 or 3 items are left in a chest... no matter if it is the provider chest (which happens when they emptied by bots faster than they are filled by inserters) or requester chest (which may happen when bots take from multiple provider chests containing only 1 item and deliver it to the same requester chest or something)... it becomes a complete disaster because then it will require manual help to get some of the furnaces unstuck. It builds up a race condition which has to be prevented.

Complex Approach

So if you only have one provider chest providing raw stone to the furnace setup and set a Threshold the input smart inserters can't go below depending on how much is in the logistic network then it will be no problem... Since bots acquiring stone will "remove" the items from the "available"-stack instantly once they get the task assigned to pick something up. This works even with the travel-delay the bots have, in fact this works even better than having red/green wire doing it, because they give wrong information on the already for pick-up "reserved" items.



I've studied the behavior by hovering my mouse over a logistic chest and watching the resource numbers. They are always reflecting the available resources MINUS what is already "reserved" for bot pick-up. If at any point the available stone number drops below 4 or worse then you're screwed because then there is more consumption than resources available for pick-up guaranteed leading to the odd-number problem which we try to avoid.

To prevent that odd number disaster and the resource number from dropping below 4 in the stone provider chests just raise the "Threshold" in the Smart "input"-inserters to a higher level until the numbers never drop to 4 or below in the available resource counter. That's the empiric method on getting the Threshold right but takes quite some time to study and will always depend on the exact number of furnaces and the number of provider chests.

So I thought about a way to calculate that Threshold for Stone (which I may be corrected upon if someone finds a mistake):

Code: Select all

Threshold = (Number of Stone Provider Chests - 1) * Chest Capacity + Robot Cargo Size * Number of Furnaces + 4

Chest Capacity = 2400 for Stone
Robot Cargo Size = 4 (it does work with sizes of 1 and 2 as well, but not with 3 because then it will lead to the odd number problem again!)

The "+ 4" at the end ensures that even in the worst case scenario that there is at least 4 stone left in the provider chest.

This is because you won't exactly know which provider chest the robots will prefer for pick-up if there are several available so it might happen that all bots will go for one stone provider chest totally emptying it while the other provider chests are completely full, thereby maybe falsely fullfilling the threshold requirement if one doesn't include that dumb behavior of bots into consideration.

For more security you can raise the number gained by the formular (I prefer to work in increments of 100 or 1000), but it should work with the formular otherwise there are glitches or special behaviors in the game programming I don't know of yet and which I haven't encountered the past month. ^^

This works for Stone obviously... at least I haven't had any weird things happening when I forcefully shut down the stone supply.



For Steel Bars the above empiric method or formular works too to some extend, but there I tend to calculate only with 1 provider chest because of the following reason reasons:

On top of the work condition for the "input" inserters you will need to have a local buffer in the Iron Plate Requester Chests. It may be based on a multiple of 4 and 5 (robot cargo size, inserter stack bonus and steel bars requiring 5 iron plates, but any other number will work as well as long as it is greater than at least 20 to overcome inserter speed and to hide bot deliver delay).

This is because robots only can carry 4 Iron Plates so it will take at least 2 Bots (in other cases even more) to deliver the required amount of Iron Plates... but since the "Input" Inserters will get the chance to input Iron Plates more than once until the first Steel Bar is finished crafting - thereby preventing the Inserter from working in a very delayed manner - the local buffer needs to be greater than that. So it would be in the best interest to have a multiple of 4 and 5 as a failsafe. I'm currently using 100 as local buffer in the Iron Plate Requester Chests and it never drops below 90 under very heavy load, because in my case the "Input" inserters stop working because I'm hitting the Threshold of available plates in the provider chests.



But to come back to the odd number thing... yes there may be odd numbers in the requester chests for Iron Plates depending on which source the bots picked from (there are multiple because of multiple furnaces provoding iron plates and if you have a backup from a storage system then those chests as well), but as long as the local buffer in the requester chest doesn't drop to an amount where the inserter would pick up less than 5 you are good to go. It also doesn't matter if there's odd numbers in the provider chests as long as it doesn't affect the local buffer in the requester chests in a bad way, which means capping the "Input" Inserters with the Threshold working condition so that the bots may catch up with refilling the requester chest again before continuing to work.

And for the Stone... it doesn't matter if there's odd numbers in the provider chest as long as it doesn't drop below the Threshold where the "last" bot to arrive would pick up an odd number of stone. So the threshold prevents the inserters from emptying the requester chests and thereby stopping to create "demand" until the point where there's enough stone in the provider chests again.

So this is where the Thresholds kick in and in case of Steel Bars also the Local Buffer prevents the inserters from ever entering any weird numbers of items into the furnace.

Update:

WELL. Screw the stuff in the spoiler... I've found an even simpler approach:

... Why did I never consider that the input inserter only works when the requester chest it takes from has the required amount of items in it?

For steel this is an pretty easy approach, since once it has 5 plates in the chest the inserter will enter exactly those 5 plates into the furnace.

For stone you will have to tell the requester chest only to request 2 or 4 stone. The bots will bring 4, the inserter will take all 4, but since it is a multiple of 2 they will be smelted into bricks leaving no rest in the furnace. It's the only place you will need a threshold in the inserter to gurantee that the bots are able to pick up 4 stone from the provider chests. xD



At least this reminds me of... why the hell can't we optionally change in an inserter menu how much items it tries to grab with each turn? It would make life so much easier for stone if you could specify that those stone inserters should take only 2 stone instead of the regular 5 like other inserters. ^^

[xnmo]

I was almost going to post this in -root's help thread but decided here was probably more appropriate.

Really like this smart furnace idea and will likely use some variant of this in the future. That being said the look of the staggered rows in the design by rk84 and -root was bugging me so I made a slight change to the blueprint. Looks a lot neater and is more efficient on chest usage too.






With this blueprint it's also easy to leave in spaces if you want. So if that is what you desire you can fit beacons in too. Maybe not enough compared to what MeduSalem likes though

[DerivePi]

If you are just dealing with Cu and Fe ores then the problem with balancing the "smart" furnaces goes away and the issue is limited to supplying the right balance of Fe and Cu ore. When you add stone and steel, two serious challenges present:
1. Furnaces must be fed the correct number of ingredients for steel and brick production
2. Production of Steel and brick should be limited. There is no reason to limit the production of FE and CU plate.

The corollary to item 2 is that FE and CU plates should continue to be produced regardless of supply. There is no reason for any furnace to be idle when it can be producing these plates.

To balance CU and FE (and not have idle furnaces) production I propose linking 2 timing circuits together. When one loop finishes, the other begins. One loop for CU and one for FE. Along each loop, place smart inserters that are linked to the storage of FE and CU plates. The inserters operate if the storage is below a certain ascending amount and shortens the timing loop (ie the time that ore is not loaded into the system - more supply of that plate = longer time for the opposite ore to be loaded into the system). Once the loop is finished the other timing loop begins (with an exception if supply of the other ore is empty it doesn't start the other loop). Loading the system is done with smart inserters and can be placed onto a belt or directly into each furnace.