Factorio Forums

After fiddling with my bots and them loading chests not evenly I finally came up with this solution.
Not sure if it is useful for someone else but for me it works quite well.

This setup works like the well known mazuri loader but with bots and can balance load a train station (or whatever else you need balanced for that matter). You can put your roboports around it just make sure the requester chests are in roboport range.
The setting for the "Constant Combinator 1" is actually -2147483648 but my client has somehow issues with the '-' sign and is not showing it (the blueprint should have the correct value)

The 'Constant Combinator Start' is to initialise the system when the chests have zero items - the number is the number of loading chests.

The 'Decider Overflow Guard' is for when the loader chests are fully filled up and the bots can stop delivering items because of that. 43200 = 18 * 2400. 18 = chest count (adjust if you have another chest count) - 2400 = a full "steel" chest of ore (iron/coal/copper/uranium/stone). When you use another kind of chest (wood/iron) you need to adjust this number to the max items that the chest can hold.

Why such a large negative number in the first constant combinator? Wouldn't you want this to total the maximum amount the chests can hold?

I don't understand the need for this.
The bots will load the requester chests fairly evenly, just set them to request more than the inserters can load, probably 400 or so if you're close to the miners, more if the bots have to travel further.
Skip the steel chest buffer and load straight from the requesters to the train cars. No need for wires, unless you want to set the request by wire.

Unloading is a bit trickier, but I just set up provider chests (active, storage, or passive should all work) with wires to sum their contents, and all the inserters from train to providers set to go when the amount is less than will fit in one chest (depends on stack size).

I maintain bot-station balance by not delivering to a stop unless there's so little resource there that even if it's all in a single chest there's room for an evenly-distributed unload, generally <4000 is enough, high-throughput stations like green chips that are doing two-input delivery and simultaneous pickup need <2000 (those have seven unload-buffer chests, 4000/7=571+ so there's never more than 2572 of any resource in a chest).

For pickup, yeah, just set the requesters at enough that the limit is high enough that loading can't drain it before the wagon's full but it gets hit before the next pickup, or (again for high-throughput simultaneous-drop/pickup stations) just take what's there and use timed stops to be sure you can pick up everything that could have been made.

leitk wrote:I don't understand the need for this.
The bots will load the requester chests fairly evenly,

Well, open mouth, insert foot...
The bots do NOT load evenly as the OP suggested, and this is a very good solution.
The only thing I really changed on it is that I moved the top constant combinator over one to fit in a medium pole to power the inserters.

RocketManChronicles: The huge negative number is to take advantage of overflow. I think this avoids a combinator for every pair of chests.

RocketManChronicles: The huge negative number is to take advantage of overflow. I think this avoids a combinator for every pair of chests.[/quote]
Ok, that makes sense. I look forward to implementing this into my base.

Lets see if I can explain what is going on:

1) The constant combinator "start" adds one per chest, as if one extra item had been in each chest. So chests are never empty to the arithmetic combinator.
2) The arithmetic combinator computes the average of all chests (+1 from "start"), rounded down (floor) and negated. So it is always negative.
3) The constant combinator "1" adds MIN_INT. With the arithmetic combinator being negative this causes an integer underflow so it becomes positive. The requester chest get a signal of MAX_INT - average chest content from the green wire.
4) The red wire adds the actual chest content. The combined signal is "MAX_INT - average + chest", which overflows if the chest has more items than the average.

Note: So far at least one chest will always request something, They can never all be above the average.

5) The decider combinator checks if all chests are full. In that case it adds one to the green wire. This causes the requester chests to overflow one early, when the chests have reached the average, which they have since they are all full. Only this in fact stops requesting items at all.


Now here is where I see a problem: I have 1m iron ore in my logistics network and 100k logistic robots. Each requester chest requests 2 billion iron ore. So all 100k logistic robots are dispatched to fetch iron ore. But 600 logistic bots already fill the chest to completion, then 600 more fill the requester chest too. All the rest then hover over the requester chest failing to deliver. Worse if it is only one chest that is below average. Now all 100k robots go to that one chest.

Obviously you don't have so many logistic robots. But the problem remains I think. Whatever chest is below the average gets all the logistic robots. It then gets hugely more than the average. Due to the delay between bots getting dispatched and items arriving any imbalance could cause massive delivery spikes that make things even worse. I think the whole thing only works when you do not have enough logistic bots or not enough iron ore and that slows down delivery.

Here is how I would fix it:

Have each requester chest request one stack or iron ore (or 2 or 10, doesn't matter, enough to keep iron ore in them). Then wire up the inserters just like you did the requester chests and set to anything > 0. The logic is still the same but now it reacts in one tick. By the time the inserter has returned to pick up the next iron ore the arithmetic and decider combinator have updated their output and the inserter will not overfill the buffer chest.

Note: For single item type stations you don't need the underflow trick but for multi item type stations you want filter inserters with "set filter" programming.

mrvn wrote:Now here is where I see a problem: I have 1m iron ore in my logistics network and 100k logistic robots. Each requester chest requests 2 billion iron ore. So all 100k logistic robots are dispatched to fetch iron ore. But 600 logistic bots already fill the chest to completion, then 600 more fill the requester chest too. All the rest then hover over the requester chest failing to deliver. Worse if it is only one chest that is below average. Now all 100k robots go to that one chest.

Obviously you don't have so many logistic robots. But the problem remains I think. Whatever chest is below the average gets all the logistic robots. It then gets hugely more than the average. Due to the delay between bots getting dispatched and items arriving any imbalance could cause massive delivery spikes that make things even worse. I think the whole thing only works when you do not have enough logistic bots or not enough iron ore and that slows down delivery.

Here is how I would fix it:

Have each requester chest request one stack or iron ore (or 2 or 10, doesn't matter, enough to keep iron ore in them). Then wire up the inserters just like you did the requester chests and set to anything > 0. The logic is still the same but now it reacts in one tick. By the time the inserter has returned to pick up the next iron ore the arithmetic and decider combinator have updated their output and the inserter will not overfill the buffer chest.

Note: For single item type stations you don't need the underflow trick but for multi item type stations you want filter inserters with "set filter" programming.

This is why I question the negative 2 billion number. Why would you not make this the maximum that can be held in the requester chests, so that you don't have robots waiting to load the chests? To make it simple, let's just say that you can hold 10k ore in the chests, make "Combinator 1" have a value of -9000 (the difference just for stack sizes/timing of bots), therefore, you get exactly what is needed. I do like the idea of attaching the inserters to the network to control how much they transfer to the buffer chests.

RocketManChronicles wrote:

mrvn wrote:Now here is where I see a problem: I have 1m iron ore in my logistics network and 100k logistic robots. Each requester chest requests 2 billion iron ore. So all 100k logistic robots are dispatched to fetch iron ore. But 600 logistic bots already fill the chest to completion, then 600 more fill the requester chest too. All the rest then hover over the requester chest failing to deliver. Worse if it is only one chest that is below average. Now all 100k robots go to that one chest.

Obviously you don't have so many logistic robots. But the problem remains I think. Whatever chest is below the average gets all the logistic robots. It then gets hugely more than the average. Due to the delay between bots getting dispatched and items arriving any imbalance could cause massive delivery spikes that make things even worse. I think the whole thing only works when you do not have enough logistic bots or not enough iron ore and that slows down delivery.

Here is how I would fix it:

Have each requester chest request one stack or iron ore (or 2 or 10, doesn't matter, enough to keep iron ore in them). Then wire up the inserters just like you did the requester chests and set to anything > 0. The logic is still the same but now it reacts in one tick. By the time the inserter has returned to pick up the next iron ore the arithmetic and decider combinator have updated their output and the inserter will not overfill the buffer chest.

Note: For single item type stations you don't need the underflow trick but for multi item type stations you want filter inserters with "set filter" programming.

This is why I question the negative 2 billion number. Why would you not make this the maximum that can be held in the requester chests, so that you don't have robots waiting to load the chests? To make it simple, let's just say that you can hold 10k ore in the chests, make "Combinator 1" have a value of -9000 (the difference just for stack sizes/timing of bots), therefore, you get exactly what is needed. I do like the idea of attaching the inserters to the network to control how much they transfer to the buffer chests.

Because for filter inserters or requester chests you need a positive number if the chest has less than average items in it: But "average - chest contents" means adding an arithmetic combinator per chest. "chest - average - MIN_INT" underflows to become positive saving you the arithmetic combinator per chest while loosing the exact count needed.

mrvn wrote:

RocketManChronicles wrote:

mrvn wrote:Now here is where I see a problem: I have 1m iron ore in my logistics network and 100k logistic robots. Each requester chest requests 2 billion iron ore. So all 100k logistic robots are dispatched to fetch iron ore. But 600 logistic bots already fill the chest to completion, then 600 more fill the requester chest too. All the rest then hover over the requester chest failing to deliver. Worse if it is only one chest that is below average. Now all 100k robots go to that one chest.

Obviously you don't have so many logistic robots. But the problem remains I think. Whatever chest is below the average gets all the logistic robots. It then gets hugely more than the average. Due to the delay between bots getting dispatched and items arriving any imbalance could cause massive delivery spikes that make things even worse. I think the whole thing only works when you do not have enough logistic bots or not enough iron ore and that slows down delivery.

Here is how I would fix it:

Have each requester chest request one stack or iron ore (or 2 or 10, doesn't matter, enough to keep iron ore in them). Then wire up the inserters just like you did the requester chests and set to anything > 0. The logic is still the same but now it reacts in one tick. By the time the inserter has returned to pick up the next iron ore the arithmetic and decider combinator have updated their output and the inserter will not overfill the buffer chest.

Note: For single item type stations you don't need the underflow trick but for multi item type stations you want filter inserters with "set filter" programming.

This is why I question the negative 2 billion number. Why would you not make this the maximum that can be held in the requester chests, so that you don't have robots waiting to load the chests? To make it simple, let's just say that you can hold 10k ore in the chests, make "Combinator 1" have a value of -9000 (the difference just for stack sizes/timing of bots), therefore, you get exactly what is needed. I do like the idea of attaching the inserters to the network to control how much they transfer to the buffer chests.

Because for filter inserters or requester chests you need a positive number if the chest has less than average items in it: But "average - chest contents" means adding an arithmetic combinator per chest. "chest - average - MIN_INT" underflows to become positive saving you the arithmetic combinator per chest while loosing the exact count needed.

Ok, that makes sense.

TL;DR
I did a version where I controlled the inserters, not the requester chests as the OP did. The balancing was improved. Support for multi-item added. Blueprint attached at very bottom of the post.

---

Some month ago, I wanted to solve the same problem and was satisfied with my solution of reading each chest's content. Reading of your solution really got me, thanks for that. After reading this threat and testing your setup, I have to agree with the given objections by mrvn and RocketManChronicles.


Assumptions & design concept
1. I too didn't want the requester chests to request that much Items. I would like to design the train loading station in a way that could work with not-separated roboports, even if I would prefer to at least have the option keep it separated.

2.1 It might happen, that a train entering the station to be loaded is already partly loaded.
2.2 The trains will either go to a (de-)centralized unloading station where everything will be unloaded evenly, or directly to i.e. an assembling station where maybe they would not be unloaded evenly.
2.3 Reading train content and controlling delivering adequate demand only is not included here.

3. A train loading station of that kind would probably be installed near furnaces or mass producing assembling plants. A one-sided 4 wagon loading station with therefore 6 (maxed out) stack inserters can load around 17880 (744.5 x 6 x 4) items per minute, plus the time window for the trains entering and leaving the station. Mining drills at ore patches might not keep up with that speed.
3.1 As for ore patches, imagining that a solution here might be delivering different ores to one train, i.e. in shared ore patches, setting different items -per wagon- for the requester chests might be a choice you want to have. Though there are some other, like setting filters for the cargo wagons' slots - which I don't prefer here, as our intention here is to do a balanced loading.
3.2 Of course, you can sort the items later, but just loading what comes first will probably lead to random chest contents, which we don't want for several reasons.
3.3 Loading different items in the same train requires (here):
a) different combinator logic per item
b) a closer look at the trains leaving setting (i.e. the 2 wagons with iron ore might be full, but the 1 with coal might only be half filled)
c) for reasons of simplicity, every bot/roboport on the loading station is in range of every chest.

4. Thinking this any further, by setting the filter for each requester chest, the basis for multi-item cargo wagons is done, though this might need further train inventory control.

5. Therefore I decided to not combinator-control the requester chests, but the inserters. I chose to set the item requests per wagon manually (or with a constant combinator i.e. per wagon).

6. I ran some test with 6 provider chests (positioned centralized above the station) and 480 bots delivering to a 4 cargo wagon station and found, that for large numbers the balancing of the OP's design was doing good, but looking at small numbers the balancing was somewhat off. In the solution posted in this post, the balancing is too when running multiple items. It works very well in terms of balancing for small numbers too, assuming that there are enough items in stock to be delivered to the requester chests and only 1 item type is delivered. At least, there is no big variation in the delivered amount per item (every chest containing iron has nearly the same amount, though the chests containing stone have different amount(s)).

---

Setup The 4 wagon station loads 4 different items.

1st wagon: 6 chests iron ore
2nd wagon: 4 chests iron ore, 2 chests stone
3rd wagon: 6 chests copper ore
4th wagon: 6 coal

Number-boxes are redwired to the corresponding chest and showing the amount of items inside. Don't get distracted by the redwires between inserter and steel chest.


wiring The items (per chest) are set with the top constant combinators. They are only (green-)wired to the corresponding requester chests. As Wagon 1 and 2 share a resource (iron ore), there are 3 greenwire connections between them (1. requester chests, 2. inserters, 3. steel chests). The connection ends before the row with stone. I've chosen an amount of 200. The arithmetic combinator is set to input: [each] / [number of chests], output: Signal A. Its input is wired to the inserters, its output to the steel chests. The inserters are connected via greenwire and set to mode: enable/disable, enable condition: [everything] <= Signal A. Each steel chest is redwired to the corresponding inserter.
Enjoy.