Combinators: How do I make a belt with at most 100 gears

[mrvn]

I want to have a supply belt running through my base with all kinds of items so I don't have to run back and forth all the time (or later wait so long for a logistic robot to catch up or when I'm out of roboport range). For that I need to limit the number of items of any one type on a belt so there is room for many types. For simplicity say I want at most 1000 iron gears on a belt at any time. I have a gear factory with an inserter that needs to be stopped when 1000 gears are on the belt.

Now one way to do this is to wire the inserter to *EVERY* tile of the belt, set them to hold the count and stop the inserter at 1000. SImple idea but the number of wires needed is excessive.

Another Idea I had would count the number of gears placed on the belt and number of gears taken from the belt and compute the difference. But how do I count gears taken off the belt by a user?

Since the belt is a loop should I forget about limiting it to 1000 gears and rather allow a new gear to be placed on the belt if one hasn't come by for a certain amount of time? Or, just thought of it, check the 20 belt tiles after the inserter and if there is no gear on it then enable the inserter?

Other ideas? Have you build anything similar?

[Deadly-Bagel]

Belts are already fairly CPU intensive, wiring each one to the circuit network isn't a viable solution for large bases. I would suggest the memory option of inserters counting objects going on to and off of the belt, this shouldn't be a problem for a components belt since you should be crafting very little yourself late game or you could also have supply points along the belt.

However overall this solution has many problems. What happens if you have 100 gears on the belt that don't get used? They would sit at the bottom. Throw in a couple of other items that aren't being used and you're clogging the lower end of the belt, potentially blocking inserters from picking up items they need. If you let the belt carry them past all the inserters, what happens when something needs 100 gears? If you're determined to go this route you'd be better off having a supply/demand system where a part of your factory requests resources to make the required number of items, and exactly those items are put on the belt. Not sure how you'd get around the inserter stack size, probably have an overflow system that loops back into the supply would be the easiest approach. Of course this would mean fair delays in receiving items but that's the downside of using belts.

As for a system everyone else has implemented, you're looking at the logistic network. The only reason to do what you're trying to do is for a technical challenge, but what's the point if you don't work it out yourself? =P

[mrvn]

The belt is a loop so there is no lower end. Items just go round and round and round. It's also not ment for established factories. Their throughput in goods is just way to high to have a single belt loop for everything. The problem I want to solve is that often (prior to blueprints and construction robots) I'm at one end of my empire trying to build something and I'm missing one more pipe. To build the pipe I need some steel, which I have already used to build the other pipes for this. Or I'm missing one copper wire so I can build an electrical mast. Then I have to walk all the way to where those things are produced and back to place the final piece.

And yes, it's partly for the challenge. Doesn't mean we can't meet it together.

[Deadly-Bagel]

If it's a loop you could have one belt connected that sends items to the network (select the correct option) as they pass over it. Use a memory setup (arithmetic combinator each * 1 looping to itself I think) to remember how much is on the belt. Then you need a way of timing a rotation, simplest solution would be a "key" item like alien artefact (if that won't be normally present on the belt) that triggers a restock and reset of the system. This will work for items manually taken off as long as you ensure you don't pick up the alien artefact (which is why I'd recommend it as it tends to visually stand out from nearly everything), the alternative is to count how many ticks it takes an item to travel around the loop and set up a timer, though this then becomes very hard to expand.

You could tie this in with previously suggested inserter logic to count items going on to and off of the belt, only for an immediate response when items are taken off for production. Wouldn't need to have it on all inserters as the above would pick up anything not counted.

[mrvn]

I have nearly figured it out. Meaning it works nearly perfect (and good enough for me).

To be flexible with expaning using a total count of items doesn't work. Instead an item should be on the belt every so often. I figured out a relative simple design using just 2 wires, 2 inserters, a chest, some transport belt and a number of an item you don't care about. Below I've chosen coal as useless item and iron plates as the item to control.

The first part to build is a timing loop. Place the chest somewhere with one inserter going in and one going out. Connect the two inserters with the belt and put a few coals in the chest. Now one inserter takes the coal out of the chest, puts it on the belt and the second inserter puts the coal back into the chest. The length of the belt acts as a delay while the number of coals involved produce a hysteresis effect. Meaning the setup will remember multiple items on the main belt going by, not just one.

Having the timing loop it's time to connect the two wires. The first wire goes between the inserter taking coal out of the chest and the main belt where the iron has just joined the belt. Make the belt just read and hold the count of iron plates and the inserter enables if iron plates > 0. So every time an iron plate goes by it takes a coal out of the box. The second wire goes from the box to the belt just before it joins the main belt. Keep that on enable/disable and set the trigger to coal > X - 1, where X is the number of coals in the timing loop. Now whenever the box is full a new iron plate enters the main belt. This causes coal to be removed from the chest and no more iron plates are allowed to enter. Take care to only have iron plate on one side of the belt of 2 iron plates will enter and the setup won't be able to count them separately.

The amount of iron plates on the main belt can be changed by the length of the timing loop. Put enough coal in the chest so the inserter can run continiously or the gaps won't be even and it can miss iron plates going by. Putting too much coal in the chest has no effect, the chest just never becomes empty.

Note: The same setup can also be used to remove items from a belt. Set up a (filter)inserter connected to the chest with enables when coal < Y. If too many iron plates come by then some will be taken off.
Note 2: The inserter doesn't count pulses. You would need an arithmetic combinator to do this properly. So if iron plates are too near to each other only one coal is removed from the chest. But it will leave enough gaps in the belt between items for my purpose.

[Deadly-Bagel]

So your solution has a system where it says "every time I see a coal, there should be an iron there as well"? That's not too bad. Instead of the coal buffer, you could instead use a combinator timer.

Have another decider with the input connected to this loop that says "if [count signal] = [max signal] output 1 Iron Plate", connect that to arithmetic combinator "Iron Plate * -1 output as Iron Plate" and connect that to your Iron Plate Inserter, which is also connected to the belt and has logic to activate if Iron Plate < 0 (only thing I'm not sure is if inserter received is activated for one tick, will it still deliver the item?).

This is a much more expandable solution and you can somewhat tweak it for different items (eg if you say [count signal] < [1/2 max signal] you will ensure that half the time there will that item passing over the belt).

Anyway I should point out my original solution doesn't count total items, the EACH signal keeps the items separate which you can then have an array of decider combinators only picking out one signal to process.

I'll play about with both tonight.

[dragontamer5788]

Another Idea I had would count the number of gears placed on the belt and number of gears taken from the belt and compute the difference. But how do I count gears taken off the belt by a user?

This is a subject that I'm going to address in my next topic of my combinator guide.

In essence, wire up "pulse mode" on all of the inserters that remove from the belt. Create a memory-cell. Then multiply by -1. Add the result to the (other) memory cell you made that counts the number of gears that were placed onto the belt.

[Linosaurus]

I have nearly figured it out. Meaning it works nearly perfect (and good enough for me).

That's a really cool system. A simple and less flexible system is to just always add items with a slow inserter, then when they come back from the long loop you remove them again with a fast inserter to prevent build up.

For practical purposes, a personal supply train with filtered inventory that's automatically filled up at home base is nice. I use it for building mining outposts, but not for in-base work.

This is a subject that I'm going to address in my next topic of my combinator guide.

I think mrvn was talking but the player removing stuff from the belt.

[Deadly-Bagel]

I think mrvn was talking but the player removing stuff from the belt.

Yep, if something is manually removed by the player there isn't a way to count it. Therefore I'm going to experiment with a pulse counter that counts items as they loop around the belt, and restock when necessary.

[Deadly-Bagel]

Ahahah...

About halfway through I realised something, if you're using any sort of timing you need to be aware that the different lanes of a belt have different distances to travel in a standard loop. To get around this, have one corner of the loop turn the opposite direction and use an underground belt to go under itself. This means each lane has three clockwise corners and three anticlockwise corners and the lanes even out. You can sort of see this on the left of the images within the 2nd spoiler and onwards.

So if you're using the circuit network instead of a key item, you need to count how many ticks it takes for an item to complete a rotation. Not sure if this is perfect but as far as I'm concerned it's a "close enough" approach as with inserter stack size you're almost always going to be a few items out anyway.

Counting Belt Length

This decider loops to itself and keeps a count of anything passing over the belt (which is set to Pulse mode):

BeltLength1.jpg (169.64 KiB) Viewed 6264 times

This decider starts ticking once one iron becomes present on the belt, and stops ticking once the iron loops back around:

BeltLength2.jpg (174.58 KiB) Viewed 6264 times

This decider takes the ticks from the last one and counts them:

BeltLength3.jpg (173.31 KiB) Viewed 6264 times

Drop a piece of iron onto the belt and wait for it to pass over the circuited belt twice to time a full rotation. The last decider will contain the number of ticks in a full rotation.

Now that you know how long a rotation is you can create a simple loop counter, in my test my loop was 732 ticks so I will use that figure as an example. Note unless otherwise stated assume we are using green wires. Set your counter decider to work when T (the signal we'll be storing ticks on) is less than 732, and output everything:

Counter

Counter.jpg (623.57 KiB) Viewed 6264 times

Connect the input to its own output, a belt, and a Constant Combinator which outputs T = 1. Connect the output to another decider with a red wire, which will be pulsing the total count of a finished rotation with the condition T = 731:

Pulser

Pulser.jpg (623.51 KiB) Viewed 6264 times

Next bit can probably be optimised, this is just a basic solution I threw together. I connected the pulser to the input and output of two deciders, one with green cable and the other with red. Each one is set to work when T = 731:

Memory Buffer

MemoryBuffer.jpg (619.45 KiB) Viewed 6264 times

These act as a memory buffer that hold only the count from the previous rotation. Note when you place these, both will be identical and as rotations are finished they will toggle on and off together. Simply swap one over by rotating the operator (< > =) which will disable it and break its loop. The next time the belt finishes a rotation it will activate, and the other will deactivate. These two memory buffers are connected to a "joiner", I've used a Decider working when [0] = 0 but you could also use an arithmetic combinator saying [each] * 1 output [each].

Joiner

SignalJoiner.jpg (637.94 KiB) Viewed 6264 times

Now, at this point we are still carrying on the T signal 731 from the timer, to tidy things up I added a Constant Combinator outputting T = -731 to null the signal but this is entirely optional. Note the combinator below that is a signal splitter which uses the same settings as the joiner.

Connect the first signal joiner to the inserters (helps to use power poles here), tick "Read Hand Contents" and set [desired item] < [quantity]. Again note your inserter stack size will throw out your figures by 1-3 units, can't be helped.

Inserters

Inserter.jpg (616.29 KiB) Viewed 6264 times

Use red wires to connect all the inserters to the splitter mentioned above, which again just needs to be always active so use something like [0] = 0 or swap it for an arithmetic combinator. Connect its output to the input of the memory buffers, again using a different coloured wire for each. We do this so when an inserter grabs an item to put on the belt, it is added to the count of items for that rotation. As long as the chests are stocked the inserters will only activate at the start of a rotation so as long as there is room on the belt the new items should always be counted in the next rotation so shouldn't be added twice.

And that's basically it. Item quantities can be easily configured in the corresponding inserter, and there isn't any worry about accidentally picking up a key item. The whole circuit fits tidily into a 7x2 space next to the belt and can count any number of items, simply keep adding inserters and connecting them up. If you really want to you could connect a belt on the other side of the loop at exactly the half way point in to your counter, and halve the number of ticks. This will provide a better response time.

Main problem is it's not easy to expand as you need to recalculate the number of ticks and set it in four combinators. If it's prone to expansion you should be able to use a constant combinator to provide most of the deciders with the duraction, and work out how many ticks per belt then multiply by the size of the loop.

Without seeing your solution I can't be sure... but if the length of the belt isn't evenly divisible by your iron plate distance then you might end up with twice as many items on the belt as you want, or even worse it could slowly rotate around and just fill up the belt (imagine dropping an iron plate every 5 belts but the loop is 6 belts long). Post a screenshot because I'm not sure I understand correctly.

[mrvn]

I realized that going for number of items on the belt is a mistake. As you mentioned you have to know the length of the belt and then compute how often an item has to come by the scanner. It's also impractical since as you resize the belt the same number of items will be spread thinner and thinner. So when you have to wait for 5 steal plates to come by it takes longer and longer. What I actually wanted was to have a constant (average) time between item. So the belt doesn't choke with to many items but it never takes too long for an item to come by.

I tried doing the counter thing with combinators but I did run into 2 problems many have probably faced:

1) each cobinator takes 1 cycle to change. If you put combinators in series the cycles add up. Now it can happen that you get 2 input signals before the first signal passes all through the combinators and they get confused.

I think I need something that takes pulses from a belt, sums them up for N cycles and outputs a combined signal for the duration of N cycles.

2) While you test things get confused. Inputs and outputs get cross connected, counters run away, things get out of sync. Now how do you get everything back on track?

Is there some trick to reseting combinators to a default state? Do I have to add a reset logic to every memory cell and counter?

[Deadly-Bagel]

1) each cobinator takes 1 cycle to change. If you put combinators in series the cycles add up. Now it can happen that you get 2 input signals before the first signal passes all through the combinators and they get confused.

I'm... not sure I understand. Yes, it takes one tick per combinator to pass on each signal, but this works on both ends. Say you loop is 100 ticks long and the first count hits your counter at 2 ticks, so it's behind. When the input stops, it takes 2 ticks for it to realise that so the last count comes in at 102 seconds, so it will still show 100 ticks. Perhaps where you have gone wrong is I used a red wire to connect the first (bottom) combinator to the second (top right) but didn't say that, if you use a green wire yeah your counter will run away from you.

2) While you test things get confused. Inputs and outputs get cross connected, counters run away, things get out of sync. Now how do you get everything back on track?

Easiest way is to open the memory combinator and click the comparator (<, >, =) three times. This ensures that for at least one of the comparators, the condition will no longer be true and it'll stop looping to itself. This is more difficult if you have two memory deciders connected to each other, you'll either need to disconnect them or set both to comparators that aren't true.

If you need to reset the whole system it might be best to disconnect the input first.

[mrvn]

1) each cobinator takes 1 cycle to change. If you put combinators in series the cycles add up. Now it can happen that you get 2 input signals before the first signal passes all through the combinators and they get confused.

I'm... not sure I understand. Yes, it takes one tick per combinator to pass on each signal, but this works on both ends. Say you loop is 100 ticks long and the first count hits your counter at 2 ticks, so it's behind. When the input stops, it takes 2 ticks for it to realise that so the last count comes in at 102 seconds, so it will still show 100 ticks. Perhaps where you have gone wrong is I used a red wire to connect the first (bottom) combinator to the second (top right) but didn't say that, if you use a green wire yeah your counter will run away from you.

Say you have an arithmetic combinator connected to a compare combinator and that looped back to the first. That gives you a loop of 2. The arithmetic combinator counts the number of items passing through the scanner and the compare combinator zeroes out the value when it gets a R(eset) signal. Now your combined speed is 2 signal change every 2 cycles but the belt provides 1 cycle pulses. It will start counting all the pulses given at odd and even times separately.

Solution: lengthen your input signals or shorten your loops.

[Deadly-Bagel]

Well a counter is simple enough but if you just want an average number of items per section of belt you could simply set it to say 600 ticks (10 seconds). That way you can be sure that at least the set number of items will pass by technically within 20 seconds (as you could have the first lot bunched up at the start, then the next lot bunched up at the end). Tweak as you wish.

As for the input, the system I posted only does one tick of input every x ticks (in above example this is 600). There is one tick where the item will not be counted but you are more after a general limiter rather than an exact measurer.