## Combinators for measuring throughput

This board is to show, discuss and archive useful combinator- and logic-creations.
Smart triggering, counters and sensors, useful circuitry, switching as an art , computers.
jcranmer
Long Handed Inserter
Posts: 90
Joined: Wed Jun 29, 2016 9:59 pm
Contact:

### Combinators for measuring throughput

When I was testing compressed blue-belt production (back before the update that did inserter-based compression), one thing I needed to do was actually gauge whether or not the belt was actually a full 40 items/second of throughput or merely 38 items/second. I realized that there's no actual forum posts that I could find on the subject, so I'm posting my notes.
##### Belts
Belts are easy to check with flow: there's a circuit condition that says "update every time a new item shows up." Building a flow meter is as simple as counting how many of these events occur in a given time period (say, a second). There are two ways of doing this, both of which are shown here:
Belt flowmeters
The bottom contraption is a high-resolution flowmeter: it will show you the total amount transferred over the past 60 ticks and will update that counter every tick. The wiring is pretty simple: the stack of combinators are a shift register of 10 items, with the outputs all connected. The first 6 registers on the left column each change their input to a different output signal (EACH * 1 -> [0], [0] * 1 -> [1], [1] * 1 -> [2], etc.), and the bottom register combines the sum all of outputs of all combinators into a single signal output.

The top contraption is a low-resolution flowmeter: it will update every 60 ticks with the amount transferred over the previous 60 tick interval. Its advantages are that it's more space-efficient, and you can multiplex different items on the same flowmeter and read them individually. It uses a clock to send a [GREEN] control pulse every 60th tick that sets and resets the signal.
Hi-res belt string
Lo-res belt string
##### Fluid flowmeters
Fluids are harder, because there's no pulse mode. However, there is a trick that makes it possible: the amount of fluid transferred in pipes is proportional to the difference in fluid height. So take two tanks, put them next to each other, and read the difference between their levels (that's a combinator of [EACH] * 1 for the upstream and [EACH] * -1 for the downstream tank). Because of fluid mechanics, it's difficult to accurately convert that to an exact fluid count, but it's possible to eyeball it to an approximate number--I divide the value by 45 to convert steam flow to approximate power consumption for my nuclear power plant. It's off by a little, but I just need enough to make sure I don't turn all my nuclear power plants if I'm using ⅓ the power. The other difficulty is that, because you're using tanks instead of pipes to read fluid height, it takes a long time for the values to quiesce when dramatic changes occur.

I'd really like it if there were a circuit network on pipes to measure fluid height or, better yet, amount_transferred.

IGotBaconSoda
Burner Inserter
Posts: 15
Joined: Thu Mar 24, 2016 7:45 pm
Contact:

### Re: Combinators for measuring throughput

For your low-res meter, you can do moving average across a time period in 3 combinators. It also tracks items individually, but lacks the exact-count precision you have (since the average technically updates every tick, and never stores the exact number passing by). I can send you the solution if you don't fancy the puzzle.

I like your idea on the high-res one, and might try one with a register myself once 0.17 drops.