, computers.Importing the blueprint Isn't working for me, says "Failed to import string: unkown version ('H').."
Combinator mesuring belt throughput
-
skillabstinenz
- Inserter
- Posts: 43
- Joined: Thu Aug 18, 2016 12:13 am
- Contact:
Re: Combinator mesuring belt throughput
Re: Combinator mesuring belt throughput
Read from when your quoted post is. These strings are for an old mod for Factorio 0.12 that was used before Factorio supported blueprint strings. You will need to use https://mods.factorio.com/mod/blueprint-string/ to import those strings.skillabstinenz wrote: ↑Mon Feb 10, 2020 9:20 pmImporting the blueprint Isn't working for me, says "Failed to import string: unkown version ('H').."
My Mods: mods.factorio.com
Re: Combinator mesuring belt throughput
I hadn't realized there was a whole thread of these, so I'll move my original post here:
The production stats display is nice, but I wanted to see how many items a certain part of my factory produces/consumes, so here's a simple but informative combinator setup:
Input (green wire 1) is connected to the inserters and belts where you want to measure the throughput (read contents in pulse mode). In addition, the constant combinator adds T=1 to the input. So, once a tick we have the throughput of that tick plus signal T=1.
The top right combinator (T < 60) accumulates that input on the red wire 1 for the first 59 ticks and resets on the 60th tick.
The second combinator on the top right takes over that accumulated input plus the input from the 60th tick and passes it on to the green wire 2. So, once a second (60 ticks) we have the throughput of the last second plus signal T=60 as a single tick data pulse.
Wait, that's one input pulse per second the same way we had it before per tick? Yes.
The two rightmost combinators on the second row work exactly the same, except the input accumulation goes until T=3600 and then pulses the data to green wire 4. So, once a minute (3600 ticks) we have the throughput of the last minute plus signal T=3600 as a single tick data pulse.
You see where this is going, you can stack that as far as you like - the third row measures 10 minutes, you could add rows for 30, 60, 120 minutes etc.
Since I can't read the pulsed values in each row, I want to store them and replace them when the next pulse comes. That's where the left three combinators in each row come in:
- The left combinator is a memory cell (i.e. loops its content back into itself) that resets when T is not 0, i.e. when a data pulse comes in on 2.
- The second combinator simply forwards everything to red wire 2, so the memory cell sees the pulse content in the first tick after the reset. The output includes T, so
- The third combinator forwards negative T to 2, so the data cell sees only the throughput values in the first tick after the reset and stores them.
The memory cell outputs its content to green wire 3 so I can read it in the tooltip on mouseover.
The storage/reset mechanism is the same for each row. In the second row (1 minute) and third row (10 minutes), I have an additional arithmetic combinator that divides by 60 and 600 respectively and puts the results on red wires 5 and 8, so the power pole tooltip shows not only the accumulated values over that period (green) but also the average per second (red).
Example: in the last minute, the inserter has moved 386 coal (roughly 6 per second).
Blueprint:
The production stats display is nice, but I wanted to see how many items a certain part of my factory produces/consumes, so here's a simple but informative combinator setup:
Input (green wire 1) is connected to the inserters and belts where you want to measure the throughput (read contents in pulse mode). In addition, the constant combinator adds T=1 to the input. So, once a tick we have the throughput of that tick plus signal T=1.
The top right combinator (T < 60) accumulates that input on the red wire 1 for the first 59 ticks and resets on the 60th tick.
The second combinator on the top right takes over that accumulated input plus the input from the 60th tick and passes it on to the green wire 2. So, once a second (60 ticks) we have the throughput of the last second plus signal T=60 as a single tick data pulse.
Wait, that's one input pulse per second the same way we had it before per tick? Yes.
The two rightmost combinators on the second row work exactly the same, except the input accumulation goes until T=3600 and then pulses the data to green wire 4. So, once a minute (3600 ticks) we have the throughput of the last minute plus signal T=3600 as a single tick data pulse.
You see where this is going, you can stack that as far as you like - the third row measures 10 minutes, you could add rows for 30, 60, 120 minutes etc.
Since I can't read the pulsed values in each row, I want to store them and replace them when the next pulse comes. That's where the left three combinators in each row come in:
- The left combinator is a memory cell (i.e. loops its content back into itself) that resets when T is not 0, i.e. when a data pulse comes in on 2.
- The second combinator simply forwards everything to red wire 2, so the memory cell sees the pulse content in the first tick after the reset. The output includes T, so
- The third combinator forwards negative T to 2, so the data cell sees only the throughput values in the first tick after the reset and stores them.
The memory cell outputs its content to green wire 3 so I can read it in the tooltip on mouseover.
The storage/reset mechanism is the same for each row. In the second row (1 minute) and third row (10 minutes), I have an additional arithmetic combinator that divides by 60 and 600 respectively and puts the results on red wires 5 and 8, so the power pole tooltip shows not only the accumulated values over that period (green) but also the average per second (red).
Example: in the last minute, the inserter has moved 386 coal (roughly 6 per second).
Blueprint:
Re: Combinator mesuring belt throughput
What you might be interested in, is the term "running average". So you can compare your solution with already existing ones.
If I recall correctly, measuring the running average of items (doesnt matter if on belt or by inserters), can be done with 4 combinators.
If I recall correctly, measuring the running average of items (doesnt matter if on belt or by inserters), can be done with 4 combinators.
Re: Combinator mesuring belt throughput
Just a note, ((n-1)/n)^n converges on 1/e, so the interval you set in that is responsible for about 63% of the result, prior history accounts for ~37%. So it's a "mostly the last n ticks" average. With a 1/60 decay per tick, after one second of a constant "100" input you'll read about 63 (~63% of 100 + ~37% of 0), after two you'll be close to 86 (63% of 100 + 37% of 63) and so on. ln(100) ~ 4.6, two digits of a 1/60-decay readout are affected by about the last 275 ticks, ln(1000)~6.9, three digits of a 1/600-decay readout are affected by the last ~4145 ticks.disentius wrote: ↑Thu May 21, 2020 2:46 pm Running average here:
viewtopic.php?f=18&t=57857&p=344103&hil ... e+#p344103
There's an accumulated error in the result, it'll be a little noisy and too high by a factor near 2×(((n-1)/n)^n - 1/e). For that sixty-tick interval you're getting results too high by twice (59/60)^60-1/e, about 0.006. for small inputs the final division truncates that out, any error less than the last digit won't show. So, for a 600-tick interval doing belt-pulse averaging you can use a 1000 premultiplier and the ~0.0006 error is truncated away. Three items per eight ticks is ⅜ items per tick, 0.375, feed a full blue belt lane through a pulse-read, premultiply by 1000 and the readout converges on 375 in a little over a minute. Do it with 1/60 decay and the readout cycles 382, 380, 378 after about five seconds, high by ~0.006.
The source of the error noise isn't hard to see: you're not subtracting 1/60 of the current value, integer division truncates, so that truncated and hence un-subtracted remainder sticks around.
Re: Combinator mesuring belt throughput
I'm trying to use this blueprint post 1.0 but the blueprint is so old and I can't piece together how it works anymore. Can anyone provide an up-to-date blueprint string of this or a comprehensive explanation of how it's built? Struggling to get just the right counter so I'm betting my hopes on this one.XKnight wrote: ↑Sat Jul 23, 2016 10:58 pm Don't even expect that someone would have any problems with throughput measuring in 0.13...
But if this is a dedicated thread, then I also share contraption (it served well to me in lots of experiments so it is time to see the big world):
Actually, it doesn't measure throughtput per second, but it measures throught per interval (if you want throught per second you can divide output value). Also, output value is stable during measurement because it is stored in memory cell.
Blueprint
Re: Combinator mesuring belt throughput
mine posted a bit back here should work
viewtopic.php?p=426304#p426304
Also it is explained, i dont remember the details, if you ahve any doubt please just ask me. Cheers!
viewtopic.php?p=426304#p426304
Also it is explained, i dont remember the details, if you ahve any doubt please just ask me. Cheers!
Re: Combinator mesuring belt throughput
Ok, I'll take a look at that one as well.
Also I did some beta branch stuff and managed to convert the old blueprint if anyone wants to use it, turns out I've managed to find to this something similar:
https://pastebin.com/2xYDjtya
Also I did some beta branch stuff and managed to convert the old blueprint if anyone wants to use it, turns out I've managed to find to this something similar:
https://pastebin.com/2xYDjtya