0.13 Count Perfect Chest Item Count

[siggboy]

What comes to mind is to use buffer boxes near your station. [...] As soon as the chests are full you start loading your wagon. The amount in the chests will obviously decrease but you don't start filling them until the wagon is full and on its way.

Well, this is exactly the solution that I've already come up with . It's probably the simplest possible way, and it also has the advantage that you do not need to know the stack size of the item that you're loading (I load things other than ore, too).

There are a few problems with the approach:

• The inserters that load the buffer chests can also get stuck with items in their hand... that basically shifts the problem only from one row of inserters to the next. Even though the buffer inserters stop repleneshing the buffer when a train is present, they will still drop off their remaining items; and these then end up in the loading inserters hands. Back to square one.
  So we need to actually put a safety buffer in place, i.e. we don't buffer the full 40 stacks that would theoretically fit, but one stack less per chest (e.g. 36 stacks if you have 4 inserters per wagon/resource).
  Which leads us to...
• You waste quite a lot of train capacity if you need to limit the train load to 36 stacks per wagon. It's something I could live with but I'd prefer a solution with less overhead.
• My system involves resource bookkeeping. For this to work, the player has to set up how much of an item will get loaded in the outpost. And I want this to be easy -- it is easy for single-product providers, and I want it to remain that way for multi-product providers as well. So ideally you set it to something like "8k" for ore and "16k" for plates etc... if you have to do funny calculations to take the safety buffer into account, that's just ugly and awkward.

Right now I'm back to experimenting with inserters that remove items from the wagons (so the stack inserters can free their hands). If you use a slow (yellow) inserter for this, then you have a lot less overhead even if you use the simplest possible approach (just turn on that inserter while the stack loaders have a hand count greater than zero).
The "unlocking inserter" moves about 50 items during the time it takes the wagon to get loaded (from one side, with 4 stack inserters per wagon). That's a lot better than the 50+ items per chest that you need to reserve with the above approach.

You then have to feed the removed items back into the supply, which is ugly but acceptable.

The smart supply train loaders use a similar trick (have an inserter remove items to unfreeze inserters that are stuck).

Btw, how are you detecting what resources a train actually wants to pick up?

It's part of my smart train scheduler, which is quite involved (you can check the link in my signature for an older version, and lots of discussion).

Another idea popped into my mind, why don't you just mix the resources on a per-wagon basis? So first and second wagon gets iron ore and rest gets coal or whatever. This would also simplify unloading your train at mainbase.

My train scheduler has "provider" and "requester" stations. It works like the logistic robot network, only with trains instead of robots. So when a train gets dispatched at the depot (= roboport), it already knows which resource to pick up, and where to drop it off.

Mixed wagons are not in the picture. A system could be designed that deals with mixed wagons, but it's not what I'm building (it's very complex and does not really help in most cases, so I won't do it).

[Jupiter]

This is becoming more and more a duplicate of viewtopic.php?f=8&t=28268

But you can also use a trick to let inserters pick up any number of items at a time. Then they'll never have items left in their hand. I described it in another post (viewtopic.php?f=5&t=28110).

Copied here:
========================================================================

So I came up with the following setup in an attempt to create an inserter that can grab only a specified number of items at a time. This only works when grabbing from belts. Grabbing out of anything with an inventory (trains, chests etc) does not work at all. A work-around is of course to put a belt between the inventory thing and your inserter.



In this setup I use arithmetic overflow of signal values in a network to let the signal be >0 (thus removing the filter from the inserter) when I want it to and otherwise be some (high) number above 0 otherwise (and activating the filter). As shown, the constant combinator outputs 2 signals of the type of item that you're going to grab. One signal is always 2^31 - 1= 2147483647. By experiment I found out that signal values are stored in 32-bit signed 2-complement integers thus the number of bits signifying the magnitude of the number is 31 (so 2147483647 is the biggest positive number possible and -2147483648 the largest negative).
The second signal is -x + 1 where x is the limit of items grabbed at a time.

So how this works is that the inserter also reads what it is holding and adds it to the big number. As long as it doesn't reach the item limit then no overflow will occur. When it does, then overflow occurs and the signal value will be -2147483648 and it removes the filter from the inserter. The small signal from the combinator will prevent overflow from happening for a while so it controls your item limit.

[siggboy]

But you can also use a trick to let inserters pick up any number of items at a time. Then they'll never have items left in their hand. I described it in another post (viewtopic.php?f=5&t=28110).

Yeah I saw that solution (that's why I came here, you linked to it from another thread ).

I cannot use this like you proposed, because the train loader needs to work at full speed. It could be useful in other places, however. In any case, the way you did it by abusing the integer wrapping into the negatives is elegant.

[Jupiter]

But you can also use a trick to let inserters pick up any number of items at a time. Then they'll never have items left in their hand. I described it in another post (viewtopic.php?f=5&t=28110).

Yeah I saw that solution (that's why I came here, you linked to it from another thread ).

I cannot use this like you proposed, because the train loader needs to work at full speed. It could be useful in other places, however. In any case, the way you did it by abusing the integer wrapping into the negatives is elegant.

But it can work at full speed. What you do is instead of having the constant combi output a -2 (or whatever is appropiate) you replace that -2 signal with the contents of the chest.
you do it like this (laid out spaciously for clarity):



This will insert exactly 39 iron ore into the box and do it at full speed. It only takes less items at the very end. Notice how the chest is also connected to the inserter.

[siggboy]

But it can work at full speed. What you do is instead of having the constant combi output a -2 (or whatever is appropiate) you replace that -2 signal with the contents of the chest.

Yes, but I do not want several combinators per chest. Actually I'd have a simpler solution that only needs 1 combinator per chest, but I don't want to do that because it's just too many combinators. My main circuit for a provider station has 15 combinators. That's about as big as I want it to be, and it's only possible because I've already optimized.

I don't want to add 2 or more combinators per chest. That would be over 60 combinators just to avoid the inserter problem. And you also have to put the combinators somewhere. There's not a lot of space, it's a train station.

[Jupiter]

But it can work at full speed. What you do is instead of having the constant combi output a -2 (or whatever is appropiate) you replace that -2 signal with the contents of the chest.

Yes, but I do not want several combinators per chest. Actually I'd have a simpler solution that only needs 1 combinator per chest, but I don't want to do that because it's just too many combinators. My main circuit for a provider station has 15 combinators. That's about as big as I want it to be, and it's only possible because I've already optimized.

I don't want to add 2 or more combinators per chest. That would be over 60 combinators just to avoid the inserter problem. And you also have to put the combinators somewhere. There's not a lot of space, it's a train station.

You don't need those combis for every chest. You just need the ones I've shown for the entire station just once.

[siggboy]

I will run some experiments. If this works then it will be quite valuable, it might be the best solution.

[siggboy]

Alright, I'm done experimenting. Thanks, you've finally put me on the right track.

First of all, regarding your last example:

The combinator that does "each + 1" is not necessary, you can simply put "-2^31" in the constant combinator (instead of calculating "2^31-1+1" as in the example). One combinator down.

The item count still has to be negated, but that's not an issue for me because I have the negative count already (in fact I did some shenanigans so I'd have a positive count, now I can reverse that ).

Actually I did not pursue your approach further because I did not see how to disable the inserters because I had to use the filter (and then "disable by condition" is not available).

You've provided the missing piece with the trick of adding (-2^31 - item_count), because that will remove the filter as soon as (-item_count) is cancelled out by the chest content and inserter hand count (as you've explained already). Actually it's important to note that the inserter will still drop the items that it's holding when the filter is cancelled, otherwise this entire scheme would not work.

Now here's the best part: I can use this to load from chests to wagon, because I use SmartTrains, and I can read the content of the wagon. The inserters will still insert <stack bonus + 1> * <inserter count> too many items, but that's easily compensated by skewing the desired item count a little -- and it's far better than having to reserve <stack size> many items per chest.

Without being able to read the wagon content (Vanilla Factorio) the other approach of actually doing this when loading the buffer chests, like you suggested, works as well. The downside of that is that you cannot use a balanced loader (combinator based), or at least it's not obvious to me how that would work (maybe you know).

To sum it up, here's how the loader will look now:

One constant combinator outputting (ItemType * -2^31) to all inserters. All inserters and chests connected to the constant combinator. Inserter set to "Filter; Read Hand (hold)". (-DesiredItemCount) needs to be added to the circuit. The SmartTrains station output (it does output the total cargo) needs to be added as well (it updates every 12 ticks by default, which is just about fast enough since an inserter requires ~12.5 ticks for a rotation).

Now, well end up with at most (DesiredItemCount + TotalInserterCount * [InserterStackBonus + 1]) items in the wagon, so we have to subtract (InserterStackBonus + 1) for each inserter that we use from the target item count.

Edit: I've found out that it's enough to subtract 1 stack worth of items per wagon. Which makes a lot of sense, thinking about it, because that means the inserters will shut down before touching the last wagon slot, assuming that they all work in tandem (they usually do in a train station). If the inserters are not synchronized then it's necessary to subtract the full theoretical margin as calculated above.

I take it. It's neat. Thanks again for helping me out.

[Jupiter]

Alright, I'm done experimenting. Thanks, you've finally put me on the right track.

First of all, regarding your last example:

The combinator that does "each + 1" is not necessary, you can simply put "-2^31" in the constant combinator (instead of calculating "2^31-1+1" as in the example). One combinator down.

Good catch!

Now here's the best part: I can use this to load from chests to wagon, because I use SmartTrains, and I can read the content of the wagon. The inserters will still insert <stack bonus + 1> * <inserter count> too many items, but that's easily compensated by skewing the desired item count a little -- and it's far better than having to reserve <stack size> many items per chest.

I'm not sure why you would still have too many items in your train. Well, there is the problem of every inserter trying to put in that last couple of items all at once. But I'm sure you have tested it all. Oh btw, if you do get problems with that, here is how you might fix that: you let all inserters work according to the old scheme as you had it previously (you know, dividing number of items left by stack bonus + 1) and then have just one inserter per wagon work according to my proposals. So it and it alone tops off the wagon.

Without being able to read the wagon content (Vanilla Factorio) the other approach of actually doing this when loading the buffer chests, like you suggested, works as well. The downside of that is that you cannot use a balanced loader (combinator based), or at least it's not obvious to me how that would work (maybe you know).

Balanced loader, as in, some contraption that makes sure that every wagon gets loaded equally (also when resources are scarce)? If not, then I'm not sure what you meant.

To sum it up, here's how the loader will look now:

One constant combinator outputting (ItemType * -2^31) to all inserters. All inserters and chests connected to the constant combinator. Inserter set to "Filter; Read Hand (hold)". (-DesiredItemCount) needs to be added to the circuit. The SmartTrains station output (it does output the total cargo) needs to be added as well (it updates every 12 ticks by default, which is just about fast enough since an inserter requires ~12.5 ticks for a rotation).

If you ever get problems with inserters being to fast, note that inserters work at different speeds when they are oriented differently. I'm not sure why but I think this is because inserters like to drop-at and grab-from different places in front of them and that means they will spend more or less time actually stretching their arm. Just have 2 inserters inserting from a box onto a belt, one facing north and one facing south. You'll see they will desync. Factorio is weird....

Now, well end up with at most (DesiredItemCount + TotalInserterCount * [InserterStackBonus + 1]) items in the wagon, so we have to subtract (InserterStackBonus + 1) for each inserter that we use from the target item count.

still not sure why

Edit: I've found out that it's enough to subtract 1 stack worth of items per wagon. Which makes a lot of sense, thinking about it, because that means the inserters will shut down before touching the last wagon slot, assuming that they all work in tandem (they usually do in a train station). If the inserters are not synchronized then it's necessary to subtract the full theoretical margin as calculated above.

What I said above about inserters working at different speeds with different orientations. They might desync because of that.

I take it. It's neat. Thanks again for helping me out.

Not a problem. Love to help out my fellow factorians.

[siggboy]

I'm not sure why you would still have too many items in your train. Well, there is the problem of every inserter trying to put in that last couple of items all at once. But I'm sure you have tested it all.

The wagon is loaded from chests, and the inserters are usually synchronized (it's not something we should try to control anyway). We must avoid that the inserters pick up any more items as soon as there is not enough space left in the wagon to drop everything off. The inserters can not pick up partial stacks from chests, so we have to stop loading one batch earlier.

The minimal safety margin is (WagonCapacity mod [BatchSize * InserterCount]) (per wagon). With 6 inserters loading ore, as in my tests, this happens to be (2000 mod 78) = 50, which is why exactly 1 slot remains empty in the wagon (50 units), and it's the safety margin that you need.

Oh btw, if you do get problems with that, here is how you might fix that: you let all inserters work according to the old scheme as you had it previously (you know, dividing number of items left by stack bonus + 1) and then have just one inserter per wagon work according to my proposals. So it and it alone tops off the wagon.

Not possible, because I'm loading from chests. It's not necessary for my purposes, the wagon does not have to be completely full. If 50ish items per wagon are not used this is not a big deal with wagons carrying at least 2k units (400 for rocket components).

Balanced loader, as in, some contraption that makes sure that every wagon gets loaded equally (also when resources are scarce)? If not, then I'm not sure what you meant.

No I'm talking about using a combinator to load a row of buffer chests evenly from a belt.

It's explained here: https://redd.it/4e03g2 (MadZuri was not the only one who came up with this, but his version is the best because it only uses 1 combinator).

In 0.13 the result is not perfectly balanced, because the inserters load more than 1 item from a belt now. It's still good enough. For the train loader I need at least enough items per wagon to fill the wagon, otherwise the throttling will fail; so a balanced loader for the buffer chests is a must (it would be very unusual for a train station to not use a balanced loader anyway).

I'm currently thinking about how to marry the balanced loader scheme with a filter inserter; that might open a way to load a mixed belt into a buffer and still keep it balanced. That would be very valuable for my multi-provider.

If you ever get problems with inserters being to fast, note that inserters work at different speeds when they are oriented differently.

I did not know; it's a bit ugly.

Just did a quick measurement, an inserter moving from N to S is a little faster than from S to N. The difference is ~230 items after moving ~6500 (13 at a time), about 3.5%; it's of course the worst case, with lower stack sizes (normal inserters) the difference will be less than 1%.

It's probably not something that's useful in a practical sense, also I think it should be fixed.

Now, well end up with at most (DesiredItemCount + TotalInserterCount * [InserterStackBonus + 1]) items in the wagon, so we have to subtract (InserterStackBonus + 1) for each inserter that we use from the target item count.

still not sure why

Loading from chests -> wagon (not belt -> wagon). See above.

If the inserters are not synchronized then it's necessary to subtract the full theoretical margin as calculated above.

What I said above about inserters working at different speeds with different orientations. They might desync because of that.

in practice I'd either have one row (flank) of the wagon dedicated to a product, or use all of the inserters to load each product, so they'd all be affected equally in any case.

I'm not even sure if a "desync" would be a problem at all -- probably not, as long as the cargo updates are fast enough. In my limited testing I did not run into any problems, it always worked reliably, and with the expected result (capacity mod total_batch_size remainder).

I take it. It's neat. Thanks again for helping me out.

Not a problem. Love to help out my fellow factorians.

The funny thing is, I remember you asking us in another thread about some general help regarding combinator design, and in my answer to you I pointed out, among other things, that it's useful to know about the integer arithmetic in Factorio. Now you've used that knowledge to great effect, and gave me a good idea. So thanks for returning the favour.

Now let's make a balanced loader for mixed belts .

[terror_gnom]

Another possibility to load "stack perfect" are bots I use them at my smart furnace setup

[siggboy]

I saw that setup, but I think with Jupiter's technique you can make it a lot more compact. Your smart furnace setup uses a lot of combinators. It's not very practical because it makes it difficult to use with speed beacons.

[terror_gnom]

I just use 1 controller for 20 furnaces (100 in total) so there is plenty of room for beacons

[Radical]

I'm just returning to Factorio for the 0.13 and this was literally the first issue I had with game mechanics!
I am a big fan of optimal solutions and in this case I wanted to have always-equal amount of belts and inserters on a belt feeding to green science production. Simply synchronising the encircled inserters which take items out of assemblers (done with circuit) did not work because the left one would always grab two belts and right one always one inserter. I am in favour of ability to remove the stack bonus!