Is there a way to force inserters to wait for a full stack before rotating?

[Is]

Reason I want to do this:

(TL;DR: super Crazy circuit network concept)

I'm trying some hyper efficient "mono-belt" strategy which is based around using one single belt that connects all factories. There's no belt connections between factories, it's all being put on the single belt. The concept works by heavily using the circuit network, making factories request what items they need and producers providing these items. It's similar to what you can do with the Logistic Network, but allows for much higher throughput with lower energy consumption.

Each factory has a buffer chest on both the inputs and the outputs, in order to stabilize things. The inputs have a logic that wait until the box has reached a minimum value, requests the items, fills the chest up to a maximum value, then stops requesting (and picking up) again until the minimum is reached.

If the item is requested, it will be provided from the factory that produces it (for example the iron furnace "factory block").

Eventually I'm forced to use stacks in order to fulfill the demand of some factory blocks (gear wheels is actually a very good example on this). In order to not completely overflow the band and have some control, I'm using some crazy logic stuff to make the receiver request a specific stack size (for example 4), which makes the producer send exactly 4 items, and sets the receivers stack inserter to pick up exactly 4 items.

This allows me to have multiple factories request various demands, while the producer just sees what level of demand is on the whole network. For example, if one factory is requesting 2 items, while another is requesting 4, the producer will put 6 items onto the belt.

(Sidenote: I'm also using this for fluids, where everything is filled into barrels, using storage tanks as buffers. Yes, I am crazy. At least I'm putting raw resources directly into the furnaces / refineries)

The problem:

(TL;DR: Oscillations that ripple through the entire factory)

On the receiving end, the filtered stack inserters aren't waiting for their fully requested stacks. The cause for this is that items are sometimes spaced a bit, since the belt is getting quite full with multiple requests happening simultaneously.

This sometimes causes items to pass through while the receiver is swinging around. Even worse, you sometimes run into some very annoying oscillations, where the inserter is always missing 2 items on each swing until the items get packed more tightly (or until some other factory down the line is requesting items as well, which usually just moves this issue further down).

This issue is also recursive (aka death spiral) since the belt is packed even tighter because even more items are being sent. For example when multiple factories have oscillations going on, which gets even worse (unmanageable to be honest) as this is eventually starting with more and more items.

Current workarounds

(TL;DR: I should probably just give up on this whole idea unless there's some way to resolve this issue)

I already have a loop-back, so whatever items aren't being picked up will be returned back to the sender, so to say. It hurts to see that sometimes 8 out of 12 requested items are looping back, while the inserters are still going mad (throwing out 12 items each swing).

Increasing the buffers in the chest seems like a good idea, but it sometimes feels like it also makes it worse, since, eventually, there's multiple chests requesting items at the same time, overflowing the network as well.

The other workaround would be to use less items per belt and therefore more then one belt (or, effectively, one belt side per item). This workaround would pretty much defeat the whole concept. I could in theory still work with the efficiency-heavy features though and could probably remove the loopback (or use it a little differently).

What I've tried out in my last playthrough was using an insane amount of Drones in the Logistic Network to relieve the belt with some less-needed items. The amount of drones needed is staggering (as well as the energy consumption). Eventually even the drones reach their capacity, since they're slow and have a hard time reaching the other end of the factory (for example with Iron or Copper plates).

The solution I'm looking for (and general TL;DR):

Everything would work perfectly fine if the requesting inserters would wait until their hand is full with the maximum stack size set by the cuircuit network input. I wouldn't need any workarounds, the whole concept would work, and it'd feel glorious.

[knighttemplar1960]

You could use a splitter off of the main belt and set it to filter out the item you want with a priority output setting. Then you could wire 2 belt tiles off that splitter and enable them only when that machine needs that item. Wire the inserter to the belt so that its off when the number of items is less than the machine requires and then turns on (in hold mode) when the number of items equals what the machine needs. The inserter will then grab all the required items since they will be compact and only what is requested. After it swings the hand will be empty and your item request will be back to zero which will power the inserter down again.

Very messy and painful.

[OldWhovian]

You could use wiring to read the belt contents for 1-2 belts (at the inserter and before it) and only enable the inserter if enough are present. Might not work perfectly if you don't use a memory cell and timer to ensure it stays active long enough to cycle.

[Is]

Wouldn't that cause congestion before the splitter if the machine isn't needing the item? Given that a filtered splitter is always fully pulling the item without load balancing? Although, yeah, with two splitters it would work, one filtered, followed by an unfiltered one (which balances the load back, fixing congestion). Yeah, I think that would actually be a super slim suggestion, I might try and go with that! Thank you so much!! <3

[Is]

Originally posted by OldWhovian:

You could use wiring to read the belt contents for 1-2 belts (at the inserter and before it) and only enable the inserter if enough are present. Might not work perfectly if you don't use a memory cell and timer to ensure it stays active long enough to cycle.

That was actually my first version, believe it or not. The issue is that if a factory further down the line needs the same item, the item won't reach, as it's being picked up before. I eventually changed it so the last factory just picks up any leftovers. As it still caused congestion, I just gave up and went with the loopback

[knighttemplar1960]

Originally posted by Is:

Wouldn't that cause congestion before the splitter if the machine isn't needing the item? Given that a filtered splitter is always fully pulling the item without load balancing? Although, yeah, with two splitters it would work, one filtered, followed by an unfiltered one (which balances the load back, fixing congestion). Yeah, I think that would actually be a super slim suggestion, I might try and go with that! Thank you so much!! <3

Use the wires to set the belt to disabled when the machine doesn't need anything. The belts don't move in this case and the splitter can only send the products on until the belt is enabled at which time this machine will get ALL of that type item until you've reached what you need.

[Is]

Originally posted by knighttemplar1960:

Use the wires to set the belt to disabled when the machine doesn't need anything. The belts don't move in this case and the splitter can only send the products on until the belt is enabled at which time this machine will get ALL of that type item until you've reached what you need.

I just tried this, due to the splitter having an input filter it blocks the main belt if the splitted belt is stopped. But using 2 splitters works, so I've got my solution :)

[Chindraba]

I'm intrigued by the concept, and might have to add it to my list of things to try. I do have a couple thoughts which might be worth something in your planning, or maybe not. They are just brainstorm ideas you can consider and use, or not, as fits your goal and setup.

Lag, or lead time is always a problem for 'just in time' inventory systems. Factorio is no exception to that. Depending on how much the system works - as in if it's a mall and only makes things once in a while to replace construction, or if it's the "production" system for science and works full-time full-speed - you might want to figure out the delay from the source to the receiver - for each receiver and each item - and set a buffer to cover that delay so the machine can start to fulfill it's production requests and have enough of a buffer, just enough, to keep working until the requested inputs arrive on the belt. Just another constant combi at each machine. No big deal, right?

Splitter filters and belt blockage solution: For a completely different purpose, and one very prone to backups, I developed a triple-splitter arrangement which filters off the belt yet won't block unless the entire loop is saturated, in which case it's effectively blocked anyway.

For this I'll use a belt moving left to right and the take of moving to the south. Splitter #1 has the input belt on the bottom and is set to filter the item on the bottom output. The top output going to a bypass belt and the bottom output going to another splitter, offset 1 tile south of the first. Splitter #2 has output priority set to the lower output. The lower output goes to where I want the item (the hold zone in your case). The upper output connects directly to a third splitter. Splitter #3 is set even with splitter #1, has priority input set to the bottom and is filtered to not output on the top output. (Deconstruction planners are read and look like a good "stop" symbol when used as a filter on splitters.) The bottom output of splitter #3 is the continuation of the belt's progress. Because of the blocking filter on splitter #3 it is possible to place splitter #1 of the next item directly after it without any belts needed, giving a 3-tile wide take-off, which happens to nicely match the size of an assembler.

The problem I would see with such a filtered splitter arrangement is that the filter cannot be set by circuit (yet) and some assemblers are going to need several inputs, and you'd need a filter setup for each of them. Satellites are one of the nasty things, only needing six inputs, and most in massive quantities!

Belt as buffer: If you added a 2-tile space between splitter #2 and #3 you could connect the upper output of #2 to the upper output of the new #4 and the lower output of #2 to the lower output of #4. Wire the lower belt from #2 to #4 and enable/disable as needed to trap up to 8 items on the belt segment when the item is requested. The priority output will fill the buffer first yet allow the excess to flow down stream to fill other requests. Trigger the inserter to only swing when the buffer is either full, or at the needed quantity and then unblock the belt once the inserter has picked up as much as has been requested. A longer belt, even a dropped loop, could be used for places with massive needs. Each straight belt can hold 4 per lane and each curve can hold 4 on the outer lane and 3 on the inner lane. Since to make a loop work you'll need left and right curves in pairs you can consider each pair of curves as 7 per lane or 14 total for each pair of curved belts.

[Is]

@chindraba You were describing exactly what I was doing with that 3-splitter concept. One issue with that system by itself is that the lower output on splitter 2 will run into some one-sided blockage if the inserter can't manage it. This leads to all the filtered items getting unbalanced and sitting at one side of the belt, instead of being merged properly again. I'm currently considering building a whole re-merger at the end, but it's getting a bit out of hand, and I feel like the inbalance is small enough to not cause major issues. It remains to be seen.

In regards to the buffer: Solving this problem was key to making the whole build possible. I put chests at each input and output of the belt to have some storage. After that, I've figured out a way to have a signal going to the network when the input chest drops below x, then keeps the signal up until the chest is filled up to y, stops the signal, and then waits until the chest is below x again.

Given that figuring this out is pretty much 90% of making this build work out, I believe this would be something to figure out for oneself. In case you don't wish to do so and just want to get rolling right out of the box, I'll gladly throw some blueprints at you :)

As a hint: there's 4 steps in there that each have their own logic and follow one after the other. It's a loop with 4 steps, at each step something needs to be checked. You don't need mods to do it, but you have to think outside the box :)

Good luck and I'm glad I've caught your attention with this madness of mine! :3

[Biometrix]

In 2.0, I think this is coming?

[Chindraba]

If your minimum and maximum values are "hard coded" in the circuit you can use bias values and accomplish min/max levels in chests using only 3 combinators.

If/when I do a mono-belt challenge I'm most likely going to keep the lanes distinct. Which lane something travels in will always be the same, and only one. It does reduce the belt buffer to half, which I can fix with a longer belt if I use that, but it also enables easy underground hood trapping if I know that iron plates are always on the left lane, for example. Lastly, even though the belt shouldn't clog unless it's fully saturated, I can reduce that to only affect one lane and plan the lane usage around the likelihood of a clog and help keep commonly paired items in different lanes just to help increase production throughput.

Yes, it does sound like a fun challenge.

[Nico]

I think I remember them talking about adding such a 'wait for full stack' feature with version 2.