Resource counting with combinators

[siggboy]

If your belts were going north or west, then it got weird.

Isn't the belt behaviour going left ("west") unchanged? In that case the splitter bus would have to run from left to right.

I've never noticed a problem with my splitter-buses, and I'm sure I did have some going right-to-left, and that should have been before the update (it was one of my first longer games, I used the splitter bus to unload trains, it was OK though).

Maybe the right-to-left behaviour does not matter on a splitter-bus because the splitters are immediately connected.

Edit: OK, so I've done a few tests and couldn't really see a difference between the left-right and right-left cases.
I'm also not a fan of my splitter-bus idea any longer. It's a waste of splitters, and not necessary to compress a belt(-lane).
One splitter per wagon is enough, this here seems to work and it's how i'll probably unload my trains in the future (with the new fancy inserters it's probably 2 inserters per wagon with all bonuses researched):

Screenshot-1.png (190.84 KiB) Viewed 5721 times

[kann_]

Let me revive this thread and ask a question.
I am currently building a resource counter to compare the flow of iron/copper/steel and control my smelting area accordingly.

So I want to measure the item flow = items/time.
What are good concepts for that? Just reset the counter every minute and store the final value? Some other averaging?
I remember there was a guy showing his build that averaged over the last 5 minutes in steps of one minute, but I can't find it. It was a very neat build with 5 + 2 combinators, but had almost no explanation how it worked.

[siggboy]

Oh, that was just discussed in another thread at length.

The best way to do it is to wait for 0.13 and then you can count the belt directly.

Another easy method is to use the smart chest balancer. If you use Madzuri's version that I linked, then you need only one combinator.

With that setup, all the smart chests will have the same amount of items, and you'll have the (negative) average amount already as an output on the combinator. Then you can easily count the throughput and just multiply by the chest count for the total throughput.

Maybe one way to do it is this: viewtopic.php?f=8&t=25005&start=10#p159640

[chipotng]

Hi there,

I extended the counter with Flip Flop (RS) to reset the counter.

It keeps track of all input and output of a chest. So you can see the delta (+/-) since last reset.

Factorio4.png (606.35 KiB) Viewed 5652 times

Lamp as optical feedback for RS-state

[Gertibrumm]

For all .13 excited people:
An exact counter with reset functionality which will count belt and inserter throughput in my .13 builds:

counting.jpg (169.45 KiB) Viewed 5613 times

Dont confuse yourself with these mocup singnal processors, they are only for simulation of the single ticks .13 inserters will output

The counter takes input signals single tick wise, it adds up ingoing signals every tick with the already existing one in memory.

The reset signal (red circuits in this case) must be only one tick wide to not start flickering (second tick must be empty signal for successful reset)
Thats where signal shortener comes in handy. (Look up minecraft signal shortener for explanation)

Signal shortener is inverter(takes 1 tick to process) and AND gate with input form inverter and signal source(1 tick delay from inserter creates 1 tick output at AND gate)
(This is also a positive edge detector)

[siggboy]

For all .13 excited people:
An exact counter with reset functionality which will count belt and inserter throughput in my .13 builds:

What you've shown is an accumulator that can be reset to 0, but it is not counting throughput. "Throughput" is "unit count per unit of time".

Also let me point out that you do not need two combinators just to make a reset to 0. In your example, you can simply apply a large negative "Blue Circuit" value (e.g. -2^31) to the counter/accumulator, and that will reset it to zero. The decider/negator are not necessary at all.

If you reset it this way, then the "reset" signal also does not need to be 1-tick wide, further simplifying the setup.

[Gertibrumm]

Thanks a lot, I knew the thing wasnt sorted out completely.
I was in disbelief that the "adding" of signals also includes negative signals :/
Well this

[siggboy]

The simplest possible "counting unit" looks like this:

Decider combinator "IF F=0 THEN output everything (input count)", and connect output to input. The signal "F" can be anything, it's the reset signal for the counter (it's the only signal color that you cannot register).

You can pulse signals into the register and they will all added together (accumulated). To erase the register apply any signal value "F" (does not have to be single tick).

There is no better way to implement a register if you can provide single tick inputs. Anything more complex is either needlessly restricting or it does provide special properties (that you do not need for your throughput counter).

[OppyLock]

So, with the simple decider counter with reset described above ... how would I store the value of the counter for use elsewhere in the factory upon receipt of the reset signal?
Imagine a loop belt that has 10 copper plate on it and a single coal (for the reset signal). How can I get 10 copper as a stored signal until the next loop of the belt?

[golfmiketango]

So, with the simple decider counter with reset described above ... how would I store the value of the counter for use elsewhere in the factory upon receipt of the reset signal?
Imagine a loop belt that has 10 copper plate on it and a single coal (for the reset signal). How can I get 10 copper as a stored signal until the next loop of the belt?

The way I would attack this is:

• Determine exactly how long my belt-loop actually lasts in game ticks, using either my own, or somebody else's, science.
• Identify and steal somebody's timer-design, appropriate to the number of ticks I have determined I am looking to make a metronome for
• Identify and steal somebody's memory cell design.
• Glue pieces together. Optimize.
• (very plausibly) Figure out a vastly superior implementation exists; throw all of this work out in anticipation of implementing it; never get around to returning to this MKII design, but instead find an alternative half-assed implementation based on splitters and robots; use that instead

Seem like a lot of work? Get used to that; combinators greatly reward squinting, head-scratching, paper waste, whiteboarding, and so on.

I'd say combinator programming is kind of like constructing python or java bytecode by hand; you have a potentially very powerful execution engine and set of "i/o libraries" at your disposal, but a very low-level language with which to express your will. In such circumstances, compact designs to the point of near-obsfucation are rewarded.

It gets easier with practice. Identify the bits of functionality and cobble them together. Take breaks when you start to fantasize about smashing your computer. Nobody is likely to "just tell you" exactly how to achieve what you want -- it's too much work to get everything "just so" relative to your particular needs, especially if this is your first nontrivial combinator build (which I'm surmising to be the case, sorry if I'm way off base and sound like a pedantic ass ).

[OppyLock]

Yep. Combinators are a surefire way to inspire frustration that's for sure
I've done many combinator projects in the past, but the thing they all had in common was that phases and timing didn't play a part. They have all been contraptions that worked with total levels of stuff and then did other stuff based on that.
This is the first contraption where I'm thwarted by the phases. I can do the count OK, but just can't seem to hook up any memory cell that doesn't suffer from feedback and run wild for a time leading to vastly inflated counts.

I'll keep struggling. That is the joy of factorio after all
My goal is to have an indeterminate length of belt that once per cycle re-populates the belt inventory to a desired level. This would be cool to enable a smart rainbow belt ... to keep a stock of say 40 R/G/B/P science packs looping.

[siggboy]

I can do the count OK, but just can't seem to hook up any memory cell that doesn't suffer from feedback and run wild for a time leading to vastly inflated counts.

A simple memory cell will only work correctly if you give it single ticks of input. You can hook an inserter in "pulse" mode directly to the memory cell and then it will be a counter. Each tick will be added to the memory.

If you need to store "hold" signals in a cell then you need to take precautions. For example you can make a memory with a "write" signal, but then again the write signal needs to be single-tick.

I've designed a little memory that can take "hold" signals. It simply takes the first tick of input it receives, and then ignores everything after that. When you want to write a new value, then you need to reset the memory. The reset signal does not have to be single-tick. So it's quite easy to use.

The description is here: viewtopic.php?f=8&t=20732&start=60#p169788