Combinator mesuring belt 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.
Please provide if possible always a blueprint of your creation.
Post Reply
User avatar
Optera
Smart Inserter
Smart Inserter
Posts: 2069
Joined: Sat Jun 11, 2016 6:41 am
Contact:

Combinator mesuring belt throughput

Post by Optera » Sat Jul 23, 2016 4:07 pm

Since I couldn't find a contraption to show belt throughput /second, I thought I'd share what I meshed together from a clock and XKnight's memory cell.
2016-07-23-18-04-32-7180810.jpg
2016-07-23-18-04-32-7180810.jpg (380.93 KiB) Viewed 19293 times
Blueprint

User avatar
siggboy
Filter Inserter
Filter Inserter
Posts: 988
Joined: Tue Mar 29, 2016 11:47 am
Contact:

Re: Combinator mesuring belt throughput

Post by siggboy » Sat Jul 23, 2016 9:44 pm

While I was trying to make your contraption smaller, I came up with a variant (which also happens to be smaller):
throughput.PNG
throughput.PNG (164.28 KiB) Viewed 19244 times
This one measures the average throughput per second (configurable) and resets automatically every minute (also configurable).

It keeps outputting the current value at the top combinator.

Short explanation: The right register counts the ticks and the total counts from the belt. It is set to clear every 3600 ticks. The middle one divides the counter by 60 (to get from ticks to seconds). The left one negates the counter, so we can subtract it from the register output. The top one then divides everything by the number of seconds.

Edit: I've come to realize that the posted solution is slightly braindead. The combinator that does "Yellow * -1" to subtract the counter is not necessary. One can instead do (in the middle combinator) "Yellow / <interval> -> S" (signal "S" is then the amount of intervals passed, e.g. seconds). Then divide by "S" instead of "Yellow" in the top combinator.

For a stable output (register buffer) combine it with the idea shown in XKnight's contraption below.
Blueprint
Last edited by siggboy on Sat Jul 23, 2016 11:53 pm, edited 1 time in total.
Is your railroad worrying you? Doctor T-Junction recommends: Smart, dynamic train deliveries with combinator Magick

User avatar
siggboy
Filter Inserter
Filter Inserter
Posts: 988
Joined: Tue Mar 29, 2016 11:47 am
Contact:

Re: Combinator mesuring belt throughput

Post by siggboy » Sat Jul 23, 2016 10:13 pm

Another variant: you can also put the belt to "hold" mode, and divide by the original tick count in the top combinator (the two bottom left combinators are not needed in that case). The result is a number from 0 to 7 which is the average number of items on the belt tile (rounded down). This can be used as a measure of belt density. (Related thread: viewtopic.php?f=8&t=29479)
Is your railroad worrying you? Doctor T-Junction recommends: Smart, dynamic train deliveries with combinator Magick

XKnight
Filter Inserter
Filter Inserter
Posts: 329
Joined: Thu May 28, 2015 10:40 pm
Contact:

Re: Combinator mesuring belt throughput

Post by XKnight » 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

User avatar
siggboy
Filter Inserter
Filter Inserter
Posts: 988
Joined: Tue Mar 29, 2016 11:47 am
Contact:

Re: Combinator mesuring belt throughput

Post by siggboy » Sat Jul 23, 2016 11:43 pm

XKnight wrote:Don't even expect that someone would have any problems with throughput measuring in 0.13...
Not everybody eats combinators for breakfast and spends so much time investigating game mechanics like you do :). For some of us, this is actually hard, so a thread like this is very useful.
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.
It's much like OPs solution, but you have found a better way for keeping the register updated.

Thanks for posting it.
Is your railroad worrying you? Doctor T-Junction recommends: Smart, dynamic train deliveries with combinator Magick

User avatar
Optera
Smart Inserter
Smart Inserter
Posts: 2069
Joined: Sat Jun 11, 2016 6:41 am
Contact:

Re: Combinator mesuring belt throughput

Post by Optera » Sun Jul 24, 2016 5:46 am

siggboy wrote:While I was trying to make your contraption smaller, I came up with a variant (which also happens to be smaller):

This one measures the average throughput per second (configurable) and resets automatically every minute (also configurable).
Works like a charm. Summing over 3600 ticks instead of 60 makes the reset tick unnoticeable.
siggboy wrote:Another variant: you can also put the belt to "hold" mode, and divide by the original tick count in the top combinator (the two bottom left combinators are not needed in that case). The result is a number from 0 to 7 which is the average number of items on the belt tile (rounded down). This can be used as a measure of belt density. (Related thread: viewtopic.php?f=8&t=29479)
Thanks for the link, perhaps density will come in handy for something.
siggboy wrote:
XKnight wrote:Don't even expect that someone would have any problems with throughput measuring in 0.13...
Not everybody eats combinators for breakfast and spends so much time investigating game mechanics like you do :). For some of us, this is actually hard, so a thread like this is very useful.
Couldn't put it better. Quite often your builds use game mechanics I wouldn't ever though of using.
XKnight wrote: 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.
I'm happy my solution uses only one more combinator (after division for throughput/s) than yours. :D

User avatar
siggboy
Filter Inserter
Filter Inserter
Posts: 988
Joined: Tue Mar 29, 2016 11:47 am
Contact:

Re: Combinator mesuring belt throughput

Post by siggboy » Fri Jul 29, 2016 11:41 am

BlakeMW has shown me the way to build a compact counter that keeps a running average. So there's no need for clocking into a register explicitely, and the output is continuously updated. It's also possible to change the "window size", that is, how quickly the counter reacts to changes in the input.

So you can display long term trends with a slowly adjusting counter, or short term trends with a quick adjustment.
belt-counter.png
belt-counter.png (129.68 KiB) Viewed 18997 times
A basic setup requires 3 combinators, in this version there's a constant combinator for configuration and another one to scale the output value for display.

The idea behind it is to take the exponential moving average, one version of the formula for that is:

avg_new = (n * avg_old - avg_old + input) / n
or, equivalently
avg_new = avg_old - (avg_old / n) + (input / n)

The average is kept in a register. You then take (avg / -n) in one combinator (this one reads from and feeds back into the register) and (input / n) in another (that's the input from the belt into the register).

You can also think about it this way: each tick you subtract a fraction from the current result and at the same time add a new piece of input. The result will then converge to the average over the past few ticks. How many ticks depends on the value by which you divide (higher values only subtract tiny bits, so it's takes longer to converge, ie. the process is more "smooth").

Now, usually if you try to add (input / n), then this will often fail unless the inputs are large values. So it's better, or even necessary, to not divide the input at all, and instead scale the result value (the average) down by "n" before displaying it. In fact, it's even better to scale the input up, so you get more precision in the output (since we only have integer operations that's the only way to get fractional results).

The value "n" is what influences the smoothing of the output. The larger this is, the longer does it take for the average to settle, but it also makes the output more stable ("smooth") because it takes into account more of the history of past inputs.

If you pick these constants (scaling and window size) correctly, and average over multiple belt tiles, the results are almost exactly the theoretical values (so you can measure 26.66 units/minute from a red belt, or 766 units/minute from a stack inserter loading from chest to belt).

I really love this setup and I'll be using it for my belt counting needs. It's also great for other things, like measuring long term trends in accumulator charge, coal supply, train count at a junction etc.


In the blueprint the input is scaled by 60, and the smoothing factor is 100. This gives a readout of "items per second" if you connect to a belt in pulse mode. If you want items per minute, scale the input by 3600 instead of 60.
blueprint
Is your railroad worrying you? Doctor T-Junction recommends: Smart, dynamic train deliveries with combinator Magick

User avatar
Optera
Smart Inserter
Smart Inserter
Posts: 2069
Joined: Sat Jun 11, 2016 6:41 am
Contact:

Re: Combinator mesuring belt throughput

Post by Optera » Sat Jul 30, 2016 5:35 am

For me this design is showing random numbers.
2016-07-30-07-28-21-7808321.jpg
2016-07-30-07-28-21-7808321.jpg (472.59 KiB) Viewed 18944 times
Top counter is my version showing throughput/5s
Bottom one is your version with input set to 300. Should be for 5s too according to your description.

User avatar
siggboy
Filter Inserter
Filter Inserter
Posts: 988
Joined: Tue Mar 29, 2016 11:47 am
Contact:

Re: Combinator mesuring belt throughput

Post by siggboy » Sat Jul 30, 2016 7:34 am

I've just tested it again with the blueprint that I've posted above (imported it just to make sure there was nothing wrong with it).

It works fine for me. When I connect the blueprinted circuit as it is preconfigured to a compressed blue belt, I get "40" as the readout (items/s). When I put "300" into the input driver, like you've tried, I get "200" as the readout (well, actually "199" but that's due to rounding).

So you've either changed some of the other values by accident or you have some large value in the counter (in that case you need to reset it). I really don't know what else it could be.

Maybe you have the belt in "hold" mode instead of "pulse" mode?

In any case, there's nothing wrong with the counter circuit as I've posted it, it must be some error on your end.
Is your railroad worrying you? Doctor T-Junction recommends: Smart, dynamic train deliveries with combinator Magick

User avatar
Optera
Smart Inserter
Smart Inserter
Posts: 2069
Joined: Sat Jun 11, 2016 6:41 am
Contact:

Re: Combinator mesuring belt throughput

Post by Optera » Sat Jul 30, 2016 12:32 pm

Odd...when i connect it to only one belt it seems ok, when connecting it to all 8 output belts the result goes wild.

User avatar
siggboy
Filter Inserter
Filter Inserter
Posts: 988
Joined: Tue Mar 29, 2016 11:47 am
Contact:

Re: Combinator mesuring belt throughput

Post by siggboy » Sat Jul 30, 2016 1:21 pm

Optera wrote:Odd...when i connect it to only one belt it seems ok, when connecting it to all 8 output belts the result goes wild.
If you connect to 8 belts the input will be multiplied by 8. You have to compensate for that by reducing the factor in the input driver. If you actually want to connect 8 belts in parallel I suggest you simply divide the output by an additional factor of 8.

The result going "wild" suggests that overflow is happening. Scale the input and outputs correctly and it's never an issue.
Is your railroad worrying you? Doctor T-Junction recommends: Smart, dynamic train deliveries with combinator Magick

CaptainKonzept
Burner Inserter
Burner Inserter
Posts: 8
Joined: Wed May 03, 2017 8:07 am
Contact:

Re: Combinator mesuring belt throughput

Post by CaptainKonzept » Wed Jun 07, 2017 7:26 am

siggboy wrote: A basic setup requires 3 combinators, in this version there's a constant combinator for configuration and another one to scale the output value for display.

avg_new = avg_old - (avg_old / n) + (input / n)

The average is kept in a register. You then take (avg / -n) in one combinator (this one reads from and feeds back into the register) and (input / n) in another (that's the input from the belt into the register).
Cool! Do you think you can provide the settings in text form or post a vanilla blueprint string (0.15)? That'd be awesome.

totobest
Inserter
Inserter
Posts: 26
Joined: Mon Dec 26, 2016 12:46 am
Contact:

Re: Combinator mesuring belt throughput

Post by totobest » Fri Jun 09, 2017 11:45 am

CaptainKonzept wrote:
siggboy wrote: A basic setup requires 3 combinators, in this version there's a constant combinator for configuration and another one to scale the output value for display.

avg_new = avg_old - (avg_old / n) + (input / n)

The average is kept in a register. You then take (avg / -n) in one combinator (this one reads from and feeds back into the register) and (input / n) in another (that's the input from the belt into the register).
Cool! Do you think you can provide the settings in text form or post a vanilla blueprint string (0.15)? That'd be awesome.
I concur!

mrvn
Smart Inserter
Smart Inserter
Posts: 3237
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Combinator mesuring belt throughput

Post by mrvn » Fri Jun 09, 2017 12:05 pm

I guess the next step would be to not just measure but drive belt throughput. Say for example the steel plant should be 50 iron plates per second.

User avatar
DemiPixel
Long Handed Inserter
Long Handed Inserter
Posts: 72
Joined: Mon Mar 21, 2016 7:27 am
Contact:

Re: Combinator mesuring belt throughput

Post by DemiPixel » Sat Jun 10, 2017 8:55 am

mrvn wrote:I guess the next step would be to not just measure but drive belt throughput. Say for example the steel plant should be 50 iron plates per second.
Scan belt for items coming in, then have another belt to detect items going out. Increment a signal when an item goes through the in and decrement it when it goes through the out. Put a transport belts which can stop itself before the "out" belt. If the signal is larger than a number, stop the belt because too many items are coming through.

All the details regarding how many items fit on a belt and the speed of belts can be found on the wiki and used to get a more specific numbers.

Anson
Fast Inserter
Fast Inserter
Posts: 235
Joined: Sun May 22, 2016 4:41 pm
Contact:

Re: Combinator mesuring belt throughput

Post by Anson » Tue Jun 13, 2017 7:07 am

DemiPixel wrote:Increment a signal when an item goes through the in and decrement it when it goes through the out. Put a transport belts which can stop itself before the "out" belt. If the signal is larger than a number, stop the belt because too many items are coming through.
i think this won't work like this ...
when too many items went in and thus the count is high, the output(!) is stopped and thus the count will increase even more from more items coming in and none going out.
the "stopping belt" would have to be in front of the input.
this simple method also doesn't react on throughput, but only on the number of items in a specific region, and thus has to be finetuned for every different application.

i would implement this by having a simple counter (pulsed count from the belt) that stops the belt when a given count is reached, and that is reset by a timer. thus it would allow eg 50 items to pass and then stop the belt for the rest of the desired intervall (eg 5 seconds), resulting in an average throughput of 50/5=10 items per second:
Througput Limiter.PNG
Througput Limiter.PNG (188.55 KiB) Viewed 14367 times
Factorio 0.15 blueprint, using the creative mode mod:

Code: Select all

0eNq9mEGPoyAUx7/KhrNuhNpOx+ye5jrHuW0mhuprS6JgAJtpJv3uCzqtjqsW2clc2iD0x5P/e3+g72hX1FBJxjVK3hHLBFco+fOOFDtwWthn+lwBShDTUKIAcVra1p4qHWpJuaqE1OEOCo0uAWI8hzeU4Etwl5BDxnKQYSbKHeNUC9kDkMtrgIBrphm08TSNc8rrcgfSzDAbSYAqocxvBbfTG164CtDZfpkpciYha/tiG+eATBaSySh5M0JeLSRjZ3K8jBw5g9fLwO4Rb/z0w/f1e/Ajk/vk7Y0Mb5UEpZwlHMDJCPzxBs8kUM1OEJYih9QWTahELTOYTr4B3yzunhUaZFs616K8zcCk4GFVUA3IRnKtudH+15FYcbR4JW4LMYbrIlMlLYoQCvMmkmVhJQqYTF88yiKLQ4vGNQqQ8UItRZHu4EhPzPiTGZ8xmdVMp6Yvv0H2TCqd/uN3JyZ1bZ50b9eMCOEE8qyPjB+s41nH1dTa7zqyrbKisnHDBP1q+j9mBE53BaQ5U/YbJVrW0PWanMnTI+W5jUybRVHDEdfn7VCbW+bV2/l5+9LKxo7th4S8b7rMtEjUoZq2yYxRARa6HJkTM54ripMwcUzxHMoZr72cwsGCsJ+7RQ7kzt2uedPfQKcMYhjzeG73PcM5mV/aHK5tAuM7B4ApxnOPsYqi/ilgIkEPEoAPUxRvP6conkrR7dwhZMrEo5/ry/i6fUA6T1AeptCsowLLSJcu3CfLCJCodVUvnToT1TltNEj3UpQp44bResjF3SWGEjTnuHGxHhpxiSMI93Rs2o+OWj8u0jr6Nqk72x+6/m8PCZ9mJNzTQv2nhjNCDfeFKSFItEiIb6m5p68XYri3f0VR/bv1ztfCUsEGtKmdnWCfnT0aRREf1OgZgay89lqHEzmJve5rLuS11x3ThbzxubC5gB98rpgu4K1PKph7hNlYmj8Ukt4/GAEqqPmZefZylKI+HE25/XhmpRloPcbUpmovSHFM1qsNjrHJqb8GdMlS
- the constant combinator in my layout is set to T(1) and L(300), T for the timer and L as the limit of 300 ticks for 5 seconds
- the first decider is set to: "if T<L then T(input count)" to create a timer of L ticks (L set in the constant combinator)
- the second decider combinator creates a clock signal C of only 1 tick length whenever the timer is zero: "if T=0 then C(1)"
- the third combinator is the counter which gets pulsed inputs from the belt and adds them to the itemcount: "if C=0 then iron(input count)"
- since those wires are all red, the itemcount is available at the belt too and can be used to enable the belt only when iron<50 (in this example).
as a result, the belt lets items pass at full speed and counts them until the condition is met.
when the timer resets it causes a 1-tick pulse on C that resets the itemcount and in turn re-enables the belt.
the second combinator and the conversion to a C clock (that is 0 all the time except when triggered) is important so that while counting items no other signal (like the timervalue etc) are also added up and make it difficult to have a reset condition on the third combinator.
this also makes it easy to use "everything<50" on the belt and "if C=0 then anything(input count)" on the counter, and thus use the blueprint for nay kind of item without the need to adjust the item types.

Anson
Fast Inserter
Fast Inserter
Posts: 235
Joined: Sun May 22, 2016 4:41 pm
Contact:

Re: Combinator mesuring belt throughput

Post by Anson » Tue Jun 13, 2017 8:46 am

almost the same as in the last post, but with additional display, last-minute-display, etc, here are screens and blueprints of the throughput counter that i use since quite some time. i got some ideas for it from lots of posts and videos, but then created this myself from scratch ...

the advantage of my setup is that i get (almost) exact results instead of "running averages".
but the disadvantage is that i get those new results only at every end of the intervals and they are immediately reset.
thus i have added some memory to store the static value of the last interval.
Throughput Counter.PNG
Throughput Counter.PNG (468.69 KiB) Viewed 14360 times
detailed description of the timer and counter : see previous post.
this version displays the currently measured throughput on the big nixie tubes, and since that is a running count also the final count of the last minute is shown on the small nixies. the other small nixies count the seconds so that you can easily see when the next static display will be finished.

and here are the details to all the combinators :
Throughput Counter Wiring.PNG
Throughput Counter Wiring.PNG (132.51 KiB) Viewed 14360 times
marked red :
all "pulsed belt sensors" can be chained and connected to the red input wire 1
the output wires 2 (which are directly connected to the input wires 1 and the counter E) show the current count durin the current intervall.
the output wires 3 (which are connected to the memory G) show the throughput of the last intervall.

marked blue:
A,B,D,E: same as the combinators in the previous post.
C: simple "divide T by 60" to get the current timer value in seconds.
F: this combinator forwards the count from the counter E to the memory G. because of the runtime (1 tick per combinator), this combinator's new values are the old outputs from E on exactly the same tick when combinator E itself resets. And one tick later similar happens for F and G when F is reset (to no longer forward any values to G during the current intervall)
G: memory cell that stores the last intervall's counts. the clock C (from combinator D) is connected to all of EFG, and may also be forwarded through F together with all desired signals. thus the memory cell has to hold values when C<2 (especially 0 OR 1), and to guarantee that it is reset (and C is not only increased from 0 to 1), C would have to be 2 or more. combinator D can only output 1 or "input count", and a multiplier would add additional delays. but luckily there is a simple trick: D and G are connected by a red *and* a green wire, thus C is added to the input of G twice and C>=2 is guaranteed. I already have seen other setups in videos where similar setups have to be "primed" with some starting values. my version should require no such additional preparations.

blueprint with "comment combinators" (see screen above), mods: creative mode and nixie tubes

Code: Select all

0eNrdW1tzozYU/is7erZbdAGMp31K9yHTbrqz6zx1Mh5sK4mmGBghp5vJ+L9X4PgSWwIdDInbl2TA8CG+c9F3jsQLmiUrnkuRKjR+QWKepQUa//WCCvGQxkl5Tj3nHI2RUHyJBiiNl+VRKn4IPlSrGUfrARLpgv9AY7weNN6oZJwWeSbVcMYTdXAzcbj5Pi7U0IpAHRD4j1zyorCDsPXdAPFUCSX4honq4HmarpYzLvVL7rCKZZwkQ57wuZJiPsyzhOsH5Vmh783Scggab+gP0LP+x/QjNLmpvlhUHL8gXP6RfHH4FKGPcFS+yMEJ6q3v1uuDk9uxkN1YSrupOFXDebaciTRWmbSPRROFFkJuhlKh6NuVzJLpjD/GT0Lfq2+4F4ni0uINT0KqlT6zJ6O6YniFqvdcle6EGxzDhnFrxCAlB6cUUJNLWt8c/+SbQBiQR9o7j5874PEGwqMPpID1TsG3Dij4BqEgcHMlVutKoRsIrQUZAY2BezfG1w6M8dliDAjGFyNGCMK4NmKMzE4RAU1BejfF5BxTzJI4/RsSFNgzOPSwmvrsjkiMSNgtNMg+NMyszYWcr4Sa6t8WuzvvhSzUtGH2FzJLh3kSK76hYGNQnfzC8miZx7Ky6hj9itbu8zUJLdMzBs7P3mXn1DrfOX9eCs8dhCWAMQU4sLf13/fyPOZ5Z7leZHM9oKSh+xe/4BnktgPvu+5gBrkBOSBQWvm9m6ILcflbB6aYWExhpjGA0ch6p/GPDmj83gGNXzvw6FuQR+9F7lzyWIknPlxmCz4tc96wyFZybprY8as6wG9Nou16SP+WRmPqvDONZmRrLhiG4BmHQEywkTtsZEatn0R4Gs8SPl2IovyPxvdxUvDB7mdN7GL6GKeLcrZRenCaHiVXB1dsz28uLQ2gJzBAm+G4y2CTMcRzZ2LkzC/BdU70lOkhncKHZg8ywZOjPk0SL3MDYrBFNGGAmgueuZYjDFIR2kB8SG1qAwnalZX4/BTa1AN0zKL1msqtoCEhpAzxeqhC5lmec2lSg7jUCu3VID4OacaOT4z26aPSj7aQH8GrPs8IFIHVt/eOhI/Ok9+YHvNry6F0n0OL1Uw/vXqBEwZ00buJuZ3ftcnkx1bGtkFhpxwZ1qRICixxo52JexJl3y3pxNw8prDRY6/v4Xchza9A/XNgoYhx3xTc9FidmCnwz5GzTmqWWHKRSc/SoHa9yypqHTQXDYHQkRH5wnXt8fJZwGz5bwSkY+RMdNRa3DpoW+ZBdCmxrHlhiC61gRCILrWB0Fa6tHNZalldbqVNTyWHWy5iDKJOSQ/qtFCcJyatRFnQS5ec+XCtaVxgYIGTnKlDCMFqlbyfAcj5zeKjxOhYDbB9nlzwuVhox67tJb+K2NOZ0UTUK+KeqKKGqQbJs2XqlKYBylYqXwEg+ROXz+pRpA8b7Px5WgXx9F5my6lINdhm4gJY4LT8Ot3oMUAPkvP05NboVNMPEHF80HGFQMLjkiFyKxlY1MoVyIe5Av7PuILV8g22DEYQzwgca0Pfa7NqgdeXstBt6NHToMyfB/Ov2VhGI/jMkTYMig//YBo/iA/WY3xMuk+VVzVhUal/QFwcE02g3myJIme/JwAJELw6vQkHsuwc1gYPREo0tEV2fa9zdITvu8kGn4FiIfigWCh4iTGFppQD9n5pETOT7qYSQ8hYgsD3aqPpNMm9nWnK5Fb7u+8YY3vFH0uhHpdciXmtb4QN5c4eptPkGOjsmOk6btOtHaOfWxhaR15v6c+nNoaDNm3ZD1grN+9FDduMHr//ljvz6EetOqo9kn/dgZCagDYTR6366hdOwRfQZmKvFQX4/0QBbhUI+LJXV2Bbysk5SwsUtlHmbePIsPbw5gLT0kNAmz6Usa4+0OameMDg6JER/LIXIKwbaQIfTsDImd2g9ZIDbV5yCMJWPXradY/e/v1Wqzb9Sa/VMazbNUTph3XBSAcVSx9dsKChIXrcliQNFQkB9E8bkUB9B8d9IEHURtp+wAd7Rr8PvVYz+oV/b/g7JPRD3ErX0cvehvynnQIdUFXOHB98KTxASazzrj43eZTZ6uFRx/6nq/J2Lj/9o0txfbBcVlPrAOm0UWzyHWPEpwFmGK/X/wKyRXMh
vanilla blueprint with only nixie tubes mod

Code: Select all

0eNrVWsuOozgU/ZWR19CDHwES9axq27uu3aiFCDgVS7xkTKmiUv59DHnRYINNJVU9m4og5tice+851069g23W0IqzQoDNO2BJWdRg8+87qNlLEWftPXGoKNgAJmgOHFDEeXtVsDdGXdFsKTg6gBUpfQMbeHRmHxQ8Luqq5MLd0kz0HkYGD+/iWrhaBGyAQN8qTutaD0KOvxxAC8EEoycmuotDVDT5lnL5klesOo+zzKUZTQRniVuVGZUTVWUtny2LdgkSzyUOOMgPuTggyS3kYNZx/A5g+4fTtD8Lk1fr9j1613B9/HU89m5eloJU4dCuAH5bqUCwGQieBCFmIGgSZKUAcTuSx1DeCQmpcHyzxcDbYrrQCF5m0Zbu41dW8nZQwnjSMBHJ79LrkzvGaxHNZBnjZeFWWSy66mhrSsRtgXntRV7FPBbtFOAfcDRPC+hr0iCw4A1eePusV4aQfOilQ81LhzpFGQd6fQ60nDVl/DTpWW8GoGtz0FANOk0rLeJtRqOU1e0n2OzirKbO9WtO4zTax0Xa8i/k2iQ1gje9EZf7p6F5mUoQz4LNgbIgpGEXeuZMBMb0wqF2ZnFeKRBXF0QVhpXoeWqlgdhGr3QgxEY5dSA30bvUjCurZcuKrlp0umeWdjuWCcqN/Hzsh0nZdPVr5e5DFRhAdOmmIMFKsb0HCHZSVhXld5dsf1hv4eAGRrfa7gbo6jGw9kZPiRNae4X3iWQj8iG6gyG7UEfnTejrZisn79Y/IgB9OyvRNeWWiOwwxrpFIc9IHcMJcURwslXWWaOBdCNkiRwqkf9sexw23kQbKmzJRmDMM7GxN6Q2FbSysTcdiG9jbzqQYIm93d3dNPvGRRY3Vi8zk0OhjcmhB5hcLSjNPm9bgtbWnqXczmEzXUQTCNDa9dDnsR+s/A/ukAaqRcx6CnyT9JQmLJVJPVWa5GyGg+L01TydEW881RNEvTIumjjrcdWNcJ/m0tQBZSOqxgKSvlJ+EHtWvJywq0PUFXC042UesUKCnUzFIgLjJm58fuOAF05pMXoUj3sDByDDiYadBhz2myp4ZSrgRamAviwV4P8mFbSRn4nlsIqnM0M1WhloYufH/rXkrR1YR/uzhfPqMH70MLDveb95rzpY6iCEhrStrOrD71l4rz7IA+vj+f5S+TRRFl1nblMX4diTrLJZU0XGee9bdACXZl2FY7MPDyeLx6aT0IXo5+9RJ/gjjQReG/YNoVUxBF9UDDVtMSJbTemx931B0Tzf0UtCYy8h021DOG01rbpNfr82LLJbwx9zJvY5FSyZzI1wZq9zg7mrOvpSHku5iTsd+2zA3wsCLUvvYfqHAw3DxJv7IVN3xIPnjx4ItAcPleB/9imP9kcPguwJCIzZxUtOQvC9T0L0v38vOgwZbWrNzkIIWbTfwF+230B3sIZH7DfGe/3pDSCakX5ksVOdRbLq8JQn93IxXb5tev+l4oAsljkr7z3vedm87CVvfz21RNI2dSTJ9Sk7CEEr7EMCZSf3H3155Ds=
the above setup is easy to expand for more belts and input types: just connect more "pulsed belt sensors" to the red wire 1, and add more nixie tubes for additional types at outputs 2 and 3.
the setup also should be easy to expand to show more intervals by adding pairs of combinators like F and G. each additional pair (and corresponding nixies or lamps) can then be used to show a history of the last xx minutes (or other intervalls, set by L)

vanatteveldt
Filter Inserter
Filter Inserter
Posts: 913
Joined: Wed Nov 25, 2015 11:44 am
Contact:

Re: Combinator mesuring belt throughput

Post by vanatteveldt » Tue Aug 01, 2017 3:58 pm

totobest wrote:
CaptainKonzept wrote:
siggboy wrote: A basic setup requires 3 combinators, in this version there's a constant combinator for configuration and another one to scale the output value for display.

avg_new = avg_old - (avg_old / n) + (input / n)

The average is kept in a register. You then take (avg / -n) in one combinator (this one reads from and feeds back into the register) and (input / n) in another (that's the input from the belt into the register).
Cool! Do you think you can provide the settings in text form or post a vanilla blueprint string (0.15)? That'd be awesome.
I concur!
I wanted to understand / blueprint it as well, so I duplicated it and describe the settings here:
viewtopic.php?f=193&t=51471

Labor3
Burner Inserter
Burner Inserter
Posts: 8
Joined: Tue May 02, 2017 7:39 pm
Contact:

Re: Combinator mesuring belt throughput

Post by Labor3 » Wed May 16, 2018 9:51 pm

Hello everyone,

i edited Ansons circuit a bit. Now you can use it to limit the belt throughtput of items. or maybe you already know and use it. ^^
all i had to do is to set the connected belt on enable/disable too, choose the item and the amout... in my base it now limits the througput of all science items to 1k per minute.

Thanks Anson for your build! ^^
0eNrVXMFy2zYQ/ReexRQAQRDUtKdce2tunYyGkmALU4nUgJQnnow+oB/SH+uXlJTsSqEAanctxeYlHprU0/Lt7uNbgM73aL7ema2zZRNNv0d2UZV1NP3ze1Tbx7JYd79rnrcmmka2MZtoEpXFpjsy37bO1HXcuKKst5Vr4rlZN9F+Etlyab5FU76fXAUp7Tdr4mY3N2cfFPuvk8iUjW2sOYZyOHielbvN3LgW+VoQk2hb1e3Hq7L75hYy1pPouf2Rt9+ytM4sjudEF2IPXJDBObuOnuDRM3DoEg+uwOApGRzCiyLzAkHP8OjST8wkavujcdV6Njer4slWrvvAwrrFzjaz9tzyf5QH6+pmdqUBtq5a7g7gcb2wplyYeFss/uq6oWvEpui6kjPGuuPNtnBF031l9OvhipevNWUxX5vZ0tbdz2jauJ05nXWmWM5WRbnswmtaZur+Fa+/P166qZYtBjtGUB7vvO5ugHf/OLM8b0nbHukzxrtjofdf93tPGjQ5DRdJvnUeVvZxFTdmsRpvGrIA6zme9RSsCpyR0SGNywlSL+DBCzI6KHiC2Cfw4CUZHRQ8Xu8ZPHaC3HM4ekZGR+pMv+MfinV9g5b33ZOmpgOUbLxGwNMhGBUcErqgm8EMgE53gxqAnpA9FSR2SfZUEPSUjA5hRpGZgaDT/WB2Zx9y7j7iZFT+Q/R9oAz5QEE3gvrO/G/s2jaFex6vDRRZLw0hXyjoxhCgDwndGAI6OKH7QkjsgmytIOh0WwhhRpKZgaCTXSGEGLorhKDTXSGEGLI/g4CT7RmAF0m2Z4DIJd2dKQA63Z2lAHT6Wh0kdro7g8ROX62DoNPdGYQZujtLf6Y746OyBbLvzhQP+AJJd2fqZ/IvxsV/35aJkC+TdF8G6N2U7ssAvZtysreBxE5fr4Og030ZhBm6L4Ogp2RzA2FGUc0NBJzuyyDEkH0ZBJzsywC8KLIvA0SuTn1ab4r1Ojbr9nJnF/G2asUxKAHJGwRP5QHBU8K3HxzeC/qUelESGEo6jCJhKOKE8h5bUbHgMpM6Ud3D+odn3r9//xPtEZtGSSgpKYyIZJhO5UGJDyUXbDwxckbTEKMZgotXiRNepJOovd5A3IY8t+Uh5PDuBsiePdh1Y9wb3wFZVLuDKUO9DTKUpx6c6Ej2MHNS5Ho3b5k53OmlUH56UQH22r+QzCreX1nLTvawOw456oxhBI75WynjGH0LgQhMV4dAEoxGsjtIJOitiZt1tJJX8i5657UMFYLES4B3OzBL0brKxp4F1WdZhVhWJHn86Oo4SDdMHrPTI2hpFnZp3CAxyYtM9phRfmZeEE+FVA9U0pN1za5Yn432hyvizz9WT3+i/639QLVrtjsEpHky7rlZ2fLxiL19nh34mj24ajOzZQt2nPUxxZhflYSvk+jRGVNevC2lLx8ak0iE3MTFI2bS92+Tq/DeUtAIBVEvZeDDyXHNdqoodHeFEvwF0VIhjN/PMBLVrSSddZK/LLzZzRmMfs0Q9GeDnGEEPHT7f9xJtHNx0RZ+OlDmRvh9iUbNkSGQBOOQQiCoKVLcwSEB9rFvOUP+qEF5aATSKd7/eCcgjZ8rxbg5Tvs6nw970Dz4Em5GckfJB3dHA8mAeSOtSd5IvJs34h/UG8Gt0DVz06/xYavku9qb6JyU6OTdEi0utrU+RqKvSVDfil5IFKd75qtIqEIBDpY5Q1WOOnu6n1WOvGPlHKxwbTqMGdb7vrHCvtyusPomekBB8sFMX7rx4bq5OC9gkpJzVGGk71QYt52rPw8k/PAi/NsyjlP6kHAAnwn5aXQonG1WG9PYxWAOsyvW/QRzu44+5a/bHKy2xh3Xt6fRL4T8tTPf/TLEQkQnmBlN+serXGKmxRBIipnR5B1mtKF3vW82OOj+4jVnoS2/XGFG3xCttPEi/eDjhS9XsLki1+hRVY601NRFqQWdVI5fCJDev4tiDKMFyl+0nHGMLAVRULtrQRTU9pq6tzCJey0N9lc0OA89NDiTJFHJxiQqAiMqnBFW0pQfCb+UpkZacfqi4kSw4jKMrOhQK2uMrARRcoyshFA4w8iKvres8DslOWxvOOf4ntF+JIHuGT1WOlWQzoQkyvmYRJmHRbkdOQ8fnJ79/zmT6KkN+rg+qDPBs4zJvJXd/wD8r0s6
Attachments
screenshot-tick-29276269.png
screenshot-tick-29276269.png (3.17 MiB) Viewed 7952 times

cid0rz
Long Handed Inserter
Long Handed Inserter
Posts: 72
Joined: Sun Jul 31, 2016 5:52 pm
Contact:

Re: Combinator mesuring belt throughput

Post by cid0rz » Mon Apr 29, 2019 8:55 pm

Hi all,

Since this thread is older than this other one I think i may present here (very humbled and scared by the raycasting engine :S) my flowmeter with scrolling display. Basically is a sum of ideas taken from many places. I started with a basic design then tuned to two final variations:

- instant flowmeter - the number displayed is the estimation in items/min that are passing through that belt every time the flowmeter measures. A standard value I used to check is every 10 seconds (or 600 ticks).

- flowmeter with average - You need to wait for the 16 ticks of the graph to complete to get a correct average of the items passing through the belt also in itemps per minute. The displayed average is weighted, 50% is the current value and 50% is the average of the last 16 values.

In both cases the scrolling display prints the current instantaneous value (or a mask of it for the averaged) in a graphical way every time flowmeter reads. The display scrolls right to left

Here is a pic of both reading:
image


I've tested many versions across the factory, in these ones the upper number is just a total thousands counter, not to be confused:
image

Configuration:

There are two combinators to set in the flowmeter:

-signal P, is the measuring interval (should be set between 200 and 3600) I recommend P=600 which measures every 10 seconds. (WARNING when setting P in operation bad readings are expected and the average won't be valid until these results are discarded)
-signal W, is the Y scale of the graph. Set it for slightly below the designed output. (if you designed for 500/min, set W=450 for example, for a full belt W=2600 is a good value) the arithmetic combinators on the right part that operate on W scale the W setting so lamps turn on from the uppermost when flow is 120% than W, next when 100% is reached, next 80, ... til the last one 10%. That is a simplified explanation. I removed some combinators where i could but i didn't push too much since I'm not a specialist. If you improve the design i'd happy to see. Also if you have suggestions or feedback please let me know.

And finally the prints to test:

Instant:


and with average:



The prints come with a looping belt, only red signal is needed from the belt reading in pulse mode. If 65electronic circuits are placed on that belt, first filling the inner lane and then the rest on the outer you should get a measure similar to the 2k shown in the firs screenshot.

The digits used are:
viewtopic.php?f=193&t=19825&start=60#p282391
(but with use colors on so it's dimmed, i dont use night vision btw)

Post Reply

Return to “Combinator Creations”

Who is online

Users browsing this forum: No registered users