Are there other functional smart furnace setups?

[Zonk]

As iam improving my base i want to make some smart setup like this viewtopic.php?f=8&t=28603 or this https://imgur.com/a/aulH2#hua9Uhy

However the first doesnt make Steel and the 2nd needs to adjust every smelter numbers. Actually i think i would stick with the 2nd but since i want it to replace my 837 smelter with it i would aim for 1000 and there i will need to adust numbers on 2000 combinatos (0-999 two times...).

Before i type numbers in 2000 combinatos i want to know if there is another possible smart furnancesetup which can smelt iron copper and steel and maybe saves me the pain of this many typing? It doest have to run on robots only and iam open to new ideas

Energy isnt a issue i prepared 20k+ and only use half of it if all my bots are and factories are running.

[MeduSalem]

Well there used to be several other setups...

Here are some threads about it:

viewtopic.php?f=8&t=25615
viewtopic.php?p=87687#p87687
viewtopic.php?f=8&t=17378
viewtopic.php?f=8&t=9292
viewtopic.php?f=8&t=6139

But the setups are all pretty much worthless with 0.13 because of how it is almost impossible to get the changed Inserter Stacksizes under control... like has been discussed in detail over this thread here:

viewtopic.php?f=8&t=28965

So either you never fully upgrade all the stacksizes from the inserters or you have to try dealing with ugly circuit network/combinator contraptions where there is no guarantee that it will work reliable. (And all the solutions presented to date to solve the problem using the circuit network only work within a certain scope, like only when belt is fully compressed or when it is not fully compressed or when it's never completely empty or when there are no other item types on the belt and so on, basically meaning there is no general solution available.)

If you want to use bots then not fully upgrading the stacksize bonus of stack inserters is the only way to deal with the problem. When using belts you may also try other tricks like measuring belt contents and so on but I find these kind of setups to be too much of fiddling around and still no guaranteed reliability.

[Optera]

My solution was to write a tiny mod for myself adding one more tech level setting stacks for inserters to 5 and stack inserters to 15.
vanilla smart furnace is unfeasible with 0.13.
Let's hope one day filter inserters will use signals for stack size instead of simple on/off.

[Zonk]

Is the Problem because the inserter into furnance have some leftovers and fill it with 1-4 Iron which cant make steel?
Or is the Goal to just fill the chest with 5 Items?

[MeduSalem]

Yes, the problem is the 1-4 Iron Plates that may be left in the furnace, blocking the recipe switch.

With the 0.13 circuit network possibilities there is currently no useful way to circumvent that (people tried to find solutions like in the linked thread above but there are no practical ones to date). And as I mentioned... the only way that works for sure is not fully upgrading the inserter stack sizes.

That or using a mod that adjusts the stack sizes like Optera wrote.

[XKnight]

Yes, the problem is the 1-4 Iron Plates that may be left in the furnace, blocking the recipe switch.

With the 0.13 circuit network possibilities there is currently no useful way to circumvent that (people tried to find solutions like in the linked thread above but there are no practical ones to date). And as I mentioned... the only way that works for sure is not fully upgrading the inserter stack sizes.

That or using a mod that adjusts the stack sizes like Optera wrote.

Now you've managed to get my attention to this problem...

[golfmiketango]

Yes, the problem is the 1-4 Iron Plates that may be left in the furnace, blocking the recipe switch.

With the 0.13 circuit network possibilities there is currently no useful way to circumvent that (people tried to find solutions like in the linked thread above but there are no practical ones to date). And as I mentioned... the only way that works for sure is not fully upgrading the inserter stack sizes.

That or using a mod that adjusts the stack sizes like Optera wrote.

Now you've managed to get my attention to this problem...

Hehehe.

Let's start here: there is a brute force solution. If we isolate a stack and split it into a number of lanes greater than a stack, we can overcome the fundamental problem but it will be hideous.

I suspect -- specifically, I am pretty sure I read in the patch notes or some other official context -- that the devs gave us a much more elegant solution in 0.13, but I haven't tested my hypothesis/recollection yet. Hint: in 0.12, excess items could be bled onto a belt by a smart-inserter, as it would be unaffected by stack-size bonuses and could be disabled by a combinator.

[MeduSalem]

Well it's not like it is impossible... I managed to get one to work reliable myself a while ago, with inserters inputting from a belt to a buffer chest and if for some reason there weren't the exact amount of items in the buffer chest (there are always some quirks with getting the right amount of items into the buffer chest even with perfect counting due to weird/unexpected/unexplainable belt/inserter behaviour) the chest contents get trashed to an output buffer chest which then outputs back to the belt...

... but yeah I consider it completely ugly because it takes waaayyy too much space (compared to how easy such a setup in 0.12 used to be) and some combinator work and it totaly doesn't work with bots, which is also a huge issue for me.

Messy Test Setup

Smart Furnace - Test 2.jpg (153.37 KiB) Viewed 4766 times

Basically the setup works by checking the items held by the input inserter (the one taking from the belt) and as long as the input buffer chest is lacking items (currently the setup works for 10 Stone/10 Iron ore/10 Copper Ore/10 Iron plates, but anything up to 13 would work hypothetically and can be set with the Constant combinator to the left in the picture). The 2 combinators next to each other set a filter in the Input Inserter as long as the input buffer chest is lacking items (a stack is below 10). The combinators calculate the difference between the items in the input buffer chest and the items currently held by the inserter... and if the amount of items held by the input inserter matches exactly the amount lacking in the chest then the filter gets unset since the chest should contain the right amount of items after that insert.

At the same time when the amount of items are exactly met in the input buffer chest (like said exactly 10 Iron plates for example, in above picture the stack inserter is actually moving 10 Copper Ore in that moment, as seen by the copper ore filter) then the combinator (the single one left) sets the correct filter in the stack Inserter which inputs that stack of Items into the furnace in one go (which is why it hypothetically only would work up to 13 items). If the amount of items is below 10 the stack inserter doesn't do anything.

If the amount of items in the input buffer chest is 11 or above for some reason (because of mentioned quirks in belt/inserter behaviour) then the combinator to the right sets a filter in the Inserter located between input/output buffer chest which then removes items from the input buffer chest to get below 10 again (after which the filter is unset). As long as the amount of items for a particular stack is below 10 the inserter between the two chests doesn't do anything.

Whatever is the case once the 2 combinators next to each other detect lacking items in the input chest again the process starts over.

Hypothetically the setup is universal and would work even with mods that add additional ores since that would only require adding an additional threshold signal to the constant combinator.


That said I really can't explain why the quirks from belt/inserter behaviour are even happening... why they are preventing item perfect counting... they just seem to happen every now and then. Maybe it's a result from the inserter missing to grab an item from the belt... I don't know. I never found out what exactly is the reason, but all I know is that it makes this entire contraption necessary.


Maybe someone figures out something easier... I don't know. I even have some ideas for removing at least 1 of the 2 combinators located next to each other using implicit adding instead... where the constant combinator is holding the negated threshold of items (like -10 Iron Ore/-10 Copper Ore/-10 Iron Plates/-10 Stone) and the signals get implicitely added to the amount of items currently hold by the inserter and currently located in the input buffer chest... and the filter signal getting unset once the amount of items in the inserter hand + input chest cancel out the constant combinator signal. But that would require further testing and I haven't played for about a month now.

[XKnight]

Robot-based solution shouldn't be very complex:

Image

4 furnaces will act as a single one, so they will recieve the same orders, and we assume that they are syncronized between themselfs.
Brains of each furnace block will be located far away from them in a separate controller.

Controller sends orders to all filtered inserters according to current priority (what item type is the most necessary) if resource count inside each furnace is zero.
Resource count should be tracked by controller for each furnace block, using knowledge about furnace production speed, amount of items inside, and current stack inserter capacity bonus. Also, controller should check that requester chest always have enough items inside

Any questions?

P.S. One tick signal is enough to give order to stack inserter (for chest-to-chest operation).
Belt-based solution looks much more interesting, at least because we cannot use any predefined knowledge, due to unknown output belt configuration/compression.

[MeduSalem]

Well yeah I have a question... how does your setup NOT leave arbitrary amounts of residuals inside the furnace with Iron Plates?

You can't request exactly 5 or 10 items to the Requester Chest. The bots won't give a damn and will try to deliver 4/8/12/16/20/... I realize that it might work with 20 as limit because it's a least common multiple (as would 40/60/80/100/etc which are alternatives if the distance is long), but you would have to use a series of balanced active provider/storage chests somewhere which are always topped off or otherwise the bots might grab less than 4 items which then eventually leads to the residual item problem since you will never be able to correct that mistake since it's absolutely unpredictible if you don't control the resource input to the smart furnace array.

The problem I'm having with that is that you are forced to use Passive Provider chests on the furnace output for that to work since they have lower priority than the Active Provider/Storage chests which would act as input to the furnace array... If you instead use active provider chests on the furnace output they would starting to interfere with the topped off active provider chests that gurantee the correct amount is being ready somewhere... since you wouldn't be able to specifically tell a robot not to pick up from the active provider of the furnace output right next to the requester chest of another furnace input... and there's it's not guranteed that it actually is greater or equal 4 Iron Plates. (The same problem would also occur if you'd use passive provider chests as both furnace output and as furnace array resource input. Bots would go for furnace outputs no matter if they contain less than 4 iron plates)

So again that leads to another problem... if there are active provider chests always topped off somewhere then the bots would never consider picking up the output contents of the passive provider chests from the furnace outputs EVER. So it's a vicious cycle that again doesn't work.

It should also be mentioned that if one is trying to control the robots... then you NEVER should enter the Logistic Network the Smart Furnace array is located in ever... especially not with Iron Plates in your logistic trash slot because the Logistic Robots will come and pick that stuff up and your item perfect count is ruined. Which is ultimately something I would forget about and then the damage is done.

The only way to make it work is using the inserter stacksize since you have even less control over the robots than you do over the stacksize. But since you can't explicitely tell an inserter to pick up 5 or 10 items from a chest (maybe from a belt, but not from a chest) you are out of luck... which results in the fact that you have to pass out on the last stages of Stack Size upgrades so that you even have remotely a chance to get some control over that. But if limiting the stacksize upgrades is your approach anyways... then I'm not having any issues with that at all because it's easy to pick up from there since it wouldn't require any different solution than 0.12 did.

That said I can't use the approach of not fully upgrading the stacksize bonus in my map anymore because I already fully upgraded the Stack Inserter Stacksize and I only noticed it's a problem after I already had overwritten every autosave where the stacksize wasn't fully upgraded yet. So that's why I stopped playing the game completely because that was when I said "f*** that s***" because I think that the Stack Size Change without a better way to override the StackSize bonus (like Optera mentioned earlier in this thread) is a dumb implementation. It ruined my savegame and I don't feel like starting over just because of a stupid change like that, which was completely unnecessary in the first place.

Also on a side note I'm always using active provider chests on the furnace/assembler output because I'm dropping the output directly into my storage facility... and I'd absolutely hate to be forced to fiddle around with Requester Chests on that part just because of using Passive Provider chests on furnace/assembler outputs.

[XKnight]

Well yeah I have a question... how does your setup NOT leave arbitrary amounts of residuals inside the furnace with Iron Plates?

You can't request exactly 5 or 10 items to the Requester Chest. The bots won't give a damn and will try to deliver 4/8/12/16/20/... I realize that it might work with 20 as limit because it's a least common multiple (as would 40/60/80/100/etc which are alternatives if the distance is long), but you would have to use a series of balanced active provider/storage chests somewhere which are always topped off or otherwise the bots might grab less than 4 items which then eventually leads to the residual item problem since you will never be able to correct that mistake since it's absolutely unpredictible if you don't control the resource input to the smart furnace array.

The problem I'm having with that is that you are forced to use Passive Provider chests on the furnace output for that to work since they have lower priority than the Active Provider/Storage chests which would act as input to the furnace array... If you instead use active provider chests on the furnace output they would starting to interfere with the topped off active provider chests that gurantee the correct amount is being ready somewhere... since you wouldn't be able to specifically tell a robot not to pick up from the active provider of the furnace output right next to the requester chest of another furnace input... and there's it's not guranteed that it actually is greater or equal 4 Iron Plates. (The same problem would also occur if you'd use passive provider chests as both furnace output and as furnace array resource input. Bots would go for furnace outputs no matter if they contain less than 4 iron plates)

So again that leads to another problem... if there are active provider chests always topped off somewhere then the bots would never consider picking up the output contents of the passive provider chests from the furnace outputs EVER. So it's a vicious cycle that again doesn't work.

The only way to make it work is using the inserter stacksize since you have even less control over the robots than you do over the stacksize. But since you can't explicitely tell an inserter to pick up 5 or 10 items from a chest (maybe from a belt, but not from a chest) you are out of luck... which results in the fact that you have to pass out on the last stages of Stack Size upgrades so that you even have remotely a chance to get some control over that. But if limiting the stacksize upgrades is your approach anyways... then I'm not having any issues with that at all because it's easy to pick up from there since it wouldn't require any different solution than 0.12 did.

Also on a side note I'm always using active provider chests on the furnace/assembler output because I'm dropping the output directly into my storage facility... and I'd absolutely hate to be forced to fiddle around with Requester Chests on that part just because of using Passive Provider chests on furnace/assembler outputs.

Yes, I made a few mistakes:
1) active provider chest should be used there
2) I didn't describe requester chest: it should have lets say 100 each ore/plate cap.
3) I didn't describe stack inserter:
Example:
-1 tick: furnace is empty and we are sure that requester chest has more than 100 iron plates without measuring its directly (how is that possible? it is very very simple, and I am sure you will find the answer by yourself)
0 tick: send order: IRON PLATE, inserters pick up lets say 11 iron plates (current capacity bonus)
Calculate in controller: 11 iron plates / 5 iron plate per recipe = 2 steels, 2 steels * 17.5 sec * 60 ticks / 2 crafting speed = 1050 ticks, remaining items - 1. This means this furnace will have work for 1050 ticks
....
1050 tick: because we know that this furnace has 1 remaining iron plate inside, we cannot send anything except iron plate: send order: IRON PLATE
...
2100 tick: remaining items - 2, send order: IRON PLATE
...
3150 tick: remaining items - 3, send order: IRON PLATE
...
4100 tick: remaining items - 4, send order: IRON PLATE, 11 new iron plates + 4 remaing iron plates = 3 steel = 1575 ticks, remaining items - 0.
...
5675 tick: remaining items - 0, select new item type for this furnace.

P.S. Timing may be shifted a bit, because I didn't take into account inserters rotations.
Also, as you can see this controller will be able to process hundreds furnace blocks at the same time.
And the last, the only thing you should afraid is stack inserter capacity bonus 5 and 10, because these capacity bonus will break this setup (this means furnaces won't be able to switch resource type, solution: clear them manually when these technologies are researched or disable the entire grid before the end of research).

[MeduSalem]

Now I get what you are trying to do... basically you don't give a damn that the stack size bonus doesn't match with the recipe requirement... you correct the issue over time by keeping track of how many residuals there are in... and letting the furnace work until the residual is removed by hitting a least common multiple again.

Well I would have to say that the approach sounds nice... but at this point I should also say that I'm using Production Modules inside furnaces and Speed Module Beacons... so probably the timing will be different (if it is still possible then because of how the stat changes might result in ugly floating point issues with half ticks and so on).


But somehow the thing is super annoying as well because you can't really use dynamic load balancing on the smart furnace array. You always have to wait for the least common multiple to be reached before you can order a recipe switch... which can take some time. Like the above eample... 5675 / 60 = 94.58 seconds before a recipe switch can be issued.

Also it's questionable what happens if one shuts down the entire smart furnace array using a Power Switch to reduce energy consumption. One would have to wait for the last furnace to complete its task... until that the beacons surrounding the furnaces that are finished will continue to consume power.

[XKnight]

Well I would have to say that the approach sounds nice... but at this point I should also say that I'm using Production Modules inside furnaces and Speed Module Beacons... so probably the timing will be different (if it is still possible then because of how the stat changes might result in ugly floating point issues with half ticks and so on).

Productivity modules will not break anything because they don't affect timings.
Speed modules - yes, but you can add 1 extra tick to be sure that everything is ok.

But somehow the thing is super annoying as well because you can't really use dynamic load balancing on the smart furnace array. You always have to wait for the least common multiple to be reached before you can order a recipe switch... which can take some time.

Yes, this build has 5 times lower reacting time than configurable inserters, but this can be solved using big furnace array, and by smart selecting new item type.
For example: if you have 10 iron plates and 1000 copper plates then you should order iron plates.
But when you have 1000 iron plates and 1001 copper plates you should order them almost evenly.

Hurray, this is my 250-th post on the forum.

Also it's questionable what happens if one shuts down the entire smart furnace array using a Power Switch to reduce energy consumption. One would have to wait for the last furnace to complete its task... until that the beacons surrounding the furnaces that are finished will continue to consume power.

If you detect a minimal lack of energy you should entirely ignore the tick. But in my opinion this is not a regular situation, it is more like exception.

[MeduSalem]

Productivity modules will not break anything because they don't affect timings.
Speed modules - yes, but you can add 1 extra tick to be sure that everything is ok.

Productivity Modules reduce the crafting Speed by -15% each.

Yes, this build has 5 times lower reacting time than configurable inserters, but this can be solved using big furnace array, and by smart selecting new item type.
For example: if you have 10 iron plates and 1000 copper plates then you should order iron plates.
But when you have 1000 iron plates and 1001 copper plates you should order them almost evenly.

Somehow that sounds like a lot of additional fiddling with edge cases...

Until I got annoyed by the stupid stacksize behaviour and stopped playing I tried using your Load balancer design from that one other thread a while ago (viewtopic.php?p=185070#p185070)... though I never finished my implementation of it because yeah... like I said I got bummed out of how fiddly 0.13 made everything instead of being straight forward.

I already consider asking Optera for the little stacksize bonus mod because of how I can't stand how f'd up Vanilla has become on that part...

[Optera]

Unless you only allow steel crafting every 2nd furnace, your approach of crafting until it cleans itself may run into the problem of running out of iron plates before reaching the multiples needed to clear out the furnaces from steel crafting.
It did happen to my initial setup when my EC production started up and drained all iron plates.

[XKnight]

Unless you only allow steel crafting every 2nd furnace, your approach of crafting until it cleans itself may run into the problem of running out of iron plates before reaching the multiples needed to clear out the furnaces from steel crafting.
It did happen to my initial setup when my EC production started up and drained all iron plates.

Steel craftining is forbidden if you have less than 100 iron plates in every requester chest.

Productivity modules will not break anything because they don't affect timings.
Speed modules - yes, but you can add 1 extra tick to be sure that everything is ok.

Productivity Modules reduce the crafting Speed by -15% each.

Yes, but this is predicatable, and I was talking about extra items - they don't require additional ticks.

But somehow the thing is super annoying as well because you can't really use dynamic load balancing on the smart furnace array. You always have to wait for the least common multiple to be reached before you can order a recipe switch... which can take some time.

Yes, this build has 5 times lower reacting time than configurable inserters, but this can be solved using big furnace array, and by smart selecting new item type.
For example: if you have 10 iron plates and 1000 copper plates then you should order iron plates.
But when you have 1000 iron plates and 1001 copper plates you should order them almost evenly.

By the way, switching furnace to another item type is not free, because inserter with another item type will start rotation only if furnace is completely empty. As a result, furnace will be idle during this rotation, this means furnace efficiency will be only 105/(105+30) = 77% for iron/copper plates (105 ticks - production time, 30 ticks - rotation time). What do you think about this price? Is it worth it?

[afk2minute]

I was thinking about quite ugly solution (and the switch is slow) - using multiple requester chests (iron ore, iron plate, copper ore) that move materials to another chest from which they are inserted into the furnace. Allow inserter that work for iron plates to move only %5=0 items (need to calculate how much iron plates were put in the chest), that inserter (with iron plate) cant be switched before it moved enough items (yes that can be a lot of time before switch). With belts thats going to be much much harder, i cant actually think of such system.

[XKnight]

With belts thats going to be much much harder, i cant actually think of such system.

Ha, belt-based solution is almost ready.

[MeduSalem]

By the way, switching furnace to another item type is not free, because inserter with another item type will start rotation only if furnace is completely empty. As a result, furnace will be idle during this rotation, this means furnace efficiency will be only 105/(105+30) = 77% for iron/copper plates (105 ticks - production time, 30 ticks - rotation time). What do you think about this price? Is it worth it?

So now it is a lot of initial fiddly number-crunching work with fine-tuning as the base, with sluggish reaction times as the icing of the cake and less efficient too as the cherry on top. What I think about that... "Pretty ugly"... I'd say, as someone who values honesty. I wouldn't want to have a slice of that cake if I had the choice. But that's just me being someone who favors easy and straight forward solutions over ones that are overly engineered/complex, because those tend to fail faster if the scope they work in isn't met for some unpredictable reason... backtracing the source of the error becomes horrendous.

Back when I started experimenting with Smart Furnaces about 2 years ago I basically did it because I wanted to eliminate idle furnaces... we have come a long way since then. With goals being easy-to-setup, compactness and high throughput with additions like Productivity Modules for extra items, space for Speed Beacons, being able to shut down power in low utilization scenarios and whatnot.

I mean yeah, the aproach above "works", which is really ingenious because it's against all odds and for that you should deserve a Factorio engineering medal (we really should have something like that on the forum)... that said the costs already outweigh the gain for practical applications in my opinion.


The bottom line of the experiment is: We really just should be able to set the Stack Size bonus using the number specified with the filter signal. Would cut down on the mess and we'd be back to how easy it used to be with 0.12.

[afk2minute]

If you like "simple solutions" just dont make steel in smart furnaces, make steel on-site. its much easier, but i guess its not about easier but just to overengineer something and have fun