Resource counting with combinators

[JasonC]

I'm sure this thread probably already exists, but I also occasionally see a post about it on the forums / reddit, usually followed by much confusion / over-complication.

So I want to share one basic technique for counting resources inserted into a chest with combinators. The fundamental thing about how signals work to remember is that it takes 1 tick for a combinator to process its input and produce an output. With that in mind it's relatively straightforward to construct a counter:



In this setup, the output of C will be a count of the total number of items inserted into the smart chest. If you want to count items removed from a chest, change the condition of B to "each < 0". A manual reset can be done by temporarily changing C to "each * 0" -- this is just a very basic example of the concepts.

The way it works is as follows:

• The input of A is the current inventory of the chest. It outputs the negative of that value on green. But because it takes a tick to process, it is always the negative value of the inventory of the previous game tick.
• The input of B is the current inventory of the chest (red) and the negative value of the inventory of the chest from the previous tick (green). It acts to implicitly sum these two values (count t - count t-1) thus producing delta items per tick, then a filter (> 0) so we only monitor increases.
• The input of C is its own output (red) and the delta item count from B (green). Since B's output is per tick, this effectively acts as a running counter by summing C's previous output with B's momentary output on each tick. The output of C is then the count of items inserted. (It's not important that this is each * 1; it just needs to output identity; so each + 0 works just as well, as does each > 0 -> each with a decider [or each < 0 if you're counting resources removed].)

There is an important caveat here: To do this reliably, you need to have this set of combinators per chest. You don't want to chain multiple chests together as input for just one of these. The reason is that you can run into a situation where items are removed from one of the chests on the same tick as items are added to another chest, and in this case, you'll miss counts (one set of these combinators monitors total resource changes per tick, it doesn't have any awareness of how many chests/tanks/etc. comprise the input).

If this thread already exists then, sorry for creating noise. If not, then I hope this clears things up and gives at least a basic starting point for more complex combinator logic.

[MadZuri]

This is an incredibly useful circuit, and many of us use it for belt counters. Well, something very similar, at the very least.

[golfmiketango]

There is an important caveat here: To do this reliably, you need to have this set of combinators per chest. You don't want to chain multiple chests together as input for just one of these. The reason is that you can run into a situation where items are removed from one of the chests on the same tick as items are added to another chest, and in this case, you'll miss counts (one set of these combinators monitors total resource changes per tick, it doesn't have any awareness of how many chests/tanks/etc. comprise the input).

If resources flow in and out of our contraption, don't we need at least two chests, and an inserter between them, and some gizmo that ensures only the input or the middle inserter operates at a time? Plus maybe a belt to nullify inserter stack-size? I think it's a really interesting but infuriatingly difficult thing to get this right if resources are intended to flow through, rather than just into, the device.

[brunzenstein]

More of this please! Digestible also by layman

[golfmiketango]

Here's a work-in-progress prototype I've been hacking on:

ItemCounterPrototype.png (1.04 MiB) Viewed 27709 times

It's intended to be able to count items "passing through" a fully-compressed belt. It seems to stutter a lot when you start it up, before settling down into the correct polyrhythm* to achieve 100% compression, in practice, from a fully compressed source... which makes me wonder about the possibility of manually orchestrating inserter timings....

Anyhow, I'm hoping to shore it up a bit before showing of the mechanics as it is pretty kludgy as is -- more of a proof of concept.

* polyrhythms are the nifty crap that happens when two different rhythms are superimposed -- they work like the interference patterns waves create when they are not of the same wavelength, but since polyrhythms are composed of discrete rhythmic events like drumbeats or inserter thrusts, you tend to get undulating clusters of proximate occurrences.... here's a simple musical example, although a polyrhythm you're likely to create with inserters in factorio is typically going to be more complex -- perhaps so complex it will appear random unless it happens to settle down into a visibly repeating pattern of items on a belt.

[brunzenstein]

Here's a work-in-progress prototype I've been hacking on:

the individual combinators settings would be interesting for understanding the inner working of the beast as well as the mods required.
Blueprint?

[kann_]

One combinator per chest should be enough. Each combinators should have a different output "resource". Then you can store all chest values on one storage cell instead of one per chest. Then you can use Each>0 = Resource(input count) to sum all the different signals.

[golfmiketango]

One combinator per chest should be enough. Each combinators should have a different output "resource". Then you can store all chest values on one storage cell instead of one per chest. Then you can use Each>0 = Resource(input count) to sum all the different signals.

I am sure we can't sum the chests. Items are flowing into and out of those chests, one-at-a-time, due to conditions I placed on the smart inserters. The smart inserters putting items into the chest act only if the chest is empty. The smart inserters taking items out act only if the chest contains one or more items.

Consider what happens if we sum the items in the chests. If the number of items in the chests stays the same, is that because:

• Nothing happened
• One chest output an item but another chest got an item put into it
• Two chests output two items but another two chests got items put item them
• etc..?

And we could identify a similar (in each case, finite but substantial) number of equivalent explanations for why the sum of items in all the chests increased or decreased by the entire range of possible numbers, except the unlikely corner cases that all the chests were full and all simultaneously became empty or vice-versa.

Since we can't learn anything by looking at the sums, we will need at least one combinator per chest. That much is clear, I hope.

What I initially had hoped was that one output combinator per chest would be built, which would emit a "1" for one tick, only, each time something landed in the chest. I was hoping that somehow if I accepted two limitations, I might be able to pull this off:

• Only one type of item is measured
• The inserter rules above are presumed to prevent more than one item from ever getting into the chests

My initial idea was something like this:

Code: Select all

 chest
  |
  +   +-+
  Ri Gi |
 +-----+|
 |     ||
 | X=1 ||
 |(X:1)||
 +-----+|
  Ro Go |
  +   +-+

It did turn itself off after one tick, but if the item was still in the chest, then it would turn itself back on in the second tick. I couldn't think of a one-combinator solution to this problem. Perhaps somebody else can?

So just to make it work I kludged together a mechanism that would turn itself off after a single tick with a two-tick delay. Something like this:

Code: Select all

 chest  +---------+
  |     |         |
  +   +-+-+ +-+   +
  Ri Gi | | | Ri Gi
 +-----+| | |+-----+
 |     || | ||     |
 | X=1 || | || X=1 |
 |(X:1)|| | ||(X:1)| 
 +-----+| | |+-----+
  Ro Go | | | Ro Go
  +   +-+ | +-+   +
          |       |
          +-------+

X is in this case the number of tin plates.

Assume an item goes into the chest.

The left combinator will go on in tick 0. In tick 1, the right combinator will be activated and the left combinator deactivated. In tick 2, the output of the right combinator's output will prevent the left combinator from activating, but since the right combinator consumes its own output twice, it will also be deactivated. So, hmm... It seems to me that in tick 3, we are back where we started and the left combinator should go on. Therefore I must have made a mistake transcribing what I really did. Let me describe just the results, as that will get me where I'm heading with this:

What I actually did caused the right-hand combinator to activate only for one tick. But, just as I was declaring victory, I discovered that I couldn't wire all those up to the same accumulating combinator, because the right-hand combinator did not have any output-only wires left... so if I wired them all together they would all confuse each other and it would break. Then I discovered that, as implemented, the left-hand combinator was always active for precisely two ticks per item being put in the box, and had a free output terminal on red, so I wired those together, accumulated, and divided the sum by two.

You get the idea -- my implementation sucked, which is why I didn't describe it. An improved version is in the works. OP's contraption uses the same number of combinators and also doesn't suffer from the following flaws of the pictured design:

• Lack of output-only wires preventing summation by combining wires
• Dedicated to measuring a single, hard-coded resource
• Needlessly complex

Anyone got an idea for how to output a single tick of output when a signal goes from 0->1, and stay quiet until we go back to zero and then back to one, again, with a single combinator? Then I can eliminate a whole row of combinators. But, otherwise, I plan just use OP's two-combinator design and de-specialize the whole apparatus to not depend on item-type.

[golfmiketango]

Here's a work-in-progress prototype I've been hacking on:

the individual combinators settings would be interesting for understanding the inner working of the beast as well as the mods required.
Blueprint?

See the post above. Although I am using Bob's mod, test-mode, and many others, those are all incidental usages that shouldn't affect the workings of the apparatus. I even tried not to exploit the longer underground capabilities Bob's mod affords to express-belts (except in the "feeder" mechanism where I was more generous to myself). Also, this is measuring tin plates, which I liked because they have a nice contrast to the black cement. But that shouldn't be important.

[JasonC]

Anyone got an idea for how to output a single tick of output when a signal goes from 0->1, and stay quiet until we go back to zero and then back to one, again, with a single combinator?

You can do this with one combinator if you don't mind having to use both red and green for the output with the implicit summing. It's combinator A from the OP. Consider the following crappy ASCII art:

Code: Select all

     /-------------------------\
     |                         |
     |  +-------------------+  |
IN---o->R                   |  \----->R
        | each * -1 => each |
        |                   G-------->G
        +-------------------+

The sum of R+G on the right will always be the change in the input in the last tick. So for your case, when IN goes from 0->1, the R+G will momentarily be 1. When IN goes from 1->0, R+G will momentarily be -1. So if you can make your circuit work with this logic, you can use it as an edge detector. For example, if you attach both red and green to a lamp, and set the lamp to anything > 0, then the lamp will flash for 1 tick when IN increases (i.e. 0->1) but not when it stays the same or decreases:

Code: Select all

     /-------------------------\
     |                         |
     |  +-------------------+  |      +--------------------+
IN---o->R                   |  \----->R                    |
        | each * -1 => each |         |   lamp, any > 0    |
        |                   G-------->G                    |
        +-------------------+         +--------------------+

If you set the lamp to any < 0, it'll flash on the falling edge instead. (Unfortunately you can't really get both edges at once with this circuit since there's no not-equal operator in circuit conditions).

Note that this combinator doesn't behave exactly as you describe, since it outputs a value on both 0->1 and 1->0, but by using >0 on the next element in the series, you filter out the 1->0 case and effectively achieve what you're going for. Still, it's not quite perfect, if you're running the output to e.g. a counter you might not get what you want. But it's the closest you can get with just one combinator as long as your receiver can filter with a condition (otherwise you have no choice but to run it through a >0 decider, thus using two combinators).

In general, though, just remember that since the game implicitly sums red + green on inputs, you basically get a free combinator-less addition that can sometimes help you.

Hope that helps.

[golfmiketango]

Anyone got an idea for how to output a single tick of output when a signal goes from 0->1, and stay quiet until we go back to zero and then back to one, again, with a single combinator?

You can do this with one combinator if you don't mind having to use both red and green for the output with the implicit summing. It's combinator A from the OP. Consider the following crappy ASCII art:

Code: Select all

     /-------------------------\
     |                         |
     |  +-------------------+  |
IN---o->R                   |  \----->R
        | each * -1 => each |
        |                   G-------->G
        +-------------------+

The sum of R+G on the right will always be the change in the input in the last tick. So for your case, when IN goes from 0->1, the R+G will momentarily be 1. When IN goes from 1->0, R+G will momentarily be -1. So if you can make your circuit work with this logic, you can use it as an edge detector. For example, if you attach both red and green to a lamp, and set the lamp to anything > 0, then the lamp will flash for 1 tick when IN increases (i.e. 0->1) but not when it stays the same or decreases:

Code: Select all

     /-------------------------\
     |                         |
     |  +-------------------+  |      +--------------------+
IN---o->R                   |  \----->R                    |
        | each * -1 => each |         |   lamp, any > 0    |
        |                   G-------->G                    |
        +-------------------+         +--------------------+

If you set the lamp to any < 0, it'll flash on the falling edge instead. (Unfortunately you can't really get both edges at once with this circuit since there's no not-equal operator in circuit conditions).

Note that this combinator doesn't behave exactly as you describe, since it outputs a value on both 0->1 and 1->0, but by using >0 on the next element in the series, you filter out the 1->0 case and effectively achieve what you're going for. Still, it's not quite perfect, if you're running the output to e.g. a counter you might not get what you want. But it's the closest you can get with just one combinator as long as your receiver can filter with a condition (otherwise you have no choice but to run it through a >0 decider, thus using two combinators).

In general, though, just remember that since the game implicitly sums red + green on inputs, you basically get a free combinator-less addition that can sometimes help you.

Hope that helps.

I guess it doesn't help to count a resource flowing through with a single combinator per chest. But, what you've shown is perfect when what you want to do, instead, or in addition, is to keep a running total of the quantity buffered inside the chests. Also, it's potentially quite convenient that if we chain them like:

[ first order derivative combinator ] -> [ high-pass filter combinator ]

(in other words, exactly as pictured in combinators "A" and "B" of your OP), I can accomplish both by wire-summing signals from the middle of the chain into a "buffered storage count accumulator" and wire-summing signals from the filtered end into an "in-flow count accumulator" (like combinator "C" in OP). If I were buffering meaningful quantities rather than working with just one item at a time, (i.e.: a similar device that pulled from chests rather than belts and thus expected an unpredictable number of items to wind up in the chests), I could then calculate exact cumulative throughput by taking the difference, which is pretty sexy. However for purposes of my "belt counter" thingy, it's probably acceptable to ignore buffering.

[golfmiketango]

You can do this with one combinator if you don't mind having to use both red and green for the output with the implicit summing. It's combinator A from the OP. Consider the following crappy ASCII art:

Code: Select all

     /-------------------------\
     |                         |
     |  +-------------------+  |
IN---o->R                   |  \----->R
        | each * -1 => each |
        |                   G-------->G
        +-------------------+

[It's perfect for] wire-summing signals ... into a "buffered storage count accumulator"

Well maybe not perfect since we can't chain together the red wires feeding into a bunch of these without mixing them up. What we could do, however, is, i.e., run green wires to the chests, and chain them together with all the green wires coming out of the ascii-art accumulators.

[kann_]

I am sure we can't sum the chests. Items are flowing into and out of those chests, one-at-a-time, due to conditions I placed on the smart inserters. The smart inserters putting items into the chest act only if the chest is empty. The smart inserters taking items out act only if the chest contains one or more items.

You didn't read my guide correctly. I never said to sum up all the chests. I suggested to count each chest on a different resource and use one combinator to store all of those signals. If you post the last edition of you problem as blueprint string I can show you what I mean.

Actually there are even more ways... best is probably to activate all input inserters if all chests are empty and activate all output inserters when all chests are full. Than you can actually just sum up all chests.

wire all chests with input of arithmetic combinator sum/#chests=iron, this will be 1 if all chests have one iron otherwise 0.
wire (same color) combinator output to every input and output inserter.
wire (different color) every chest with every input and output inserter.
input inserter rule: iron=0
output inserter rule: iron=2 *might not work due to inserter timing, in that case it will get a little more difficoult

To count you just wire the combiantor output to one of those incrementor memory cells and multiply by chest number. Probably also works by just wiring the chest directly to the incrementor memory cell without multiplying

[golfmiketango]

I am sure we can't sum the chests. Items are flowing into and out of those chests, one-at-a-time, due to conditions I placed on the smart inserters. The smart inserters putting items into the chest act only if the chest is empty. The smart inserters taking items out act only if the chest contains one or more items.

You didn't read my guide correctly. I never said to sum up all the chests. I suggested to count each chest on a different resource and use one combinator to store all of those signals. If you post the last edition of you problem as blueprint string I can show you what I mean.

Yeah, I had a feeling I might not have understood you entirely. But I don't see much utility separating the resources when we can capture them all at once with "each"... maybe I still don't understand you. A blueprint will be coming eventually, but for now, I have some real-life stuff I gotta do first -- I'm sure this goes without saying, but feel free to just ignore me and post your own design.

Actually there are even more ways... best is probably to activate all input inserters if all chests are empty and activate all output inserters when all chests are full. Than you can actually just sum up all chests.

I would like a counter to introduce minimal side-effects when only a very few resources are flowing in, all the way down to just a single item, so I don't think that'd work for my purposes. If anything, I'd like the production version of the device to separate and preserve belt-sides. In fact, ideally, it would even have all the distances from the input to the smart inserters to the output be exactly equal, such that items emerge, as nearly as possible, in the exact configuration they arrive in, although I am not sure what kind of fidelity is practically possible in that regard and fear I'll wind up futzing around with it forever if I get too picky about it.

[golfmiketango]

FFF #138 is must-read material for anyone interested in this counting biz!

[siggboy]

Anyone got an idea for how to output a single tick of output when a signal goes from 0->1, and stay quiet until we go back to zero and then back to one, again, with a single combinator? Then I can eliminate a whole row of combinators. But, otherwise, I plan just use OP's two-combinator design and de-specialize the whole apparatus to not depend on item-type.

I'm sure this is impossible, for the following reason:

What you want is an edge detector for a rising signal. So there's the temporal component (signal changing from one tick to the next), which you can only isolate by delaying the signal. This requires 1 combinator.
Then you need to compare this delayed signal (from 1 tick in the past) to the present signal (to detect the change and, optionally, to distinguish rising from falling edges). This requires another combinator. It can never be the combinator that you used to delay the signal, because you can't delay a signal with an operation and use the same operation to compare the past version to the present version, because the delay has not happened yet.

If we did have an "oracle" combinator that can view 1 tick into the future it might be possible, however . Or we'd need a combinator that can do more than one operation during the same tick.

Regarding your counter contraption:

1. You do not need smart inserters on both ends. It's enough if you have smart inserters removing the items (each connected to the chest in front of it), and configure it to only act when the chest is not empty (otherwise the loading inserter might skip the chest and hand the item directly over to the unloading inserter, and then the item won't be counted).
2. You do not need that many chests/inserters to count a blue belt. 20 inserters/chests is already more than enough.
3. Your layout can be more compact.

Here's my version (I've tested it, it's count-perfect). There are 22 chests in this version, so you can remove one column, 20 inserters/chests is enough for one blue belt -- well 20 FAST inserters is enough, the smart inserters are a bit slower, so probably 22 chests is the correct number or otherwise some backlog might be building up in the chest, albeit very slowly.

Oh, and by the way, this will be entirely moot in 0.13 because we'll be able to count belt contents directly .

counter.PNG (1.87 MiB) Viewed 28400 times

Here's the blueprint:

Code: Select all

H4sIAAAAAAAA/+Vd247bNhD9lcCPrR3wphsK90eCYuHYSiLAlg1ZLrJY7L/XkhatRUqjM2QKe7Vv2ZijGZ65kBwOyd3x0/643ew/Pa1f8rIu6iI/r19eys0h
Xy92+bbY5dVqezx8LcpNfawWy9PxfG10LNcvP9erZPm8XqWfo9fl9liW+bb54Ur+ZSEXf61fqnx3/VT71eenYrdWarktqu2lqJu/5Ovr8nuV5yXRRr1eG31Z
qMGv2Q1bIXbFmwxvsq9fvhXVuX46F9/LzX79Uj+frh37u6jqy2a/WHb97H5c5Zvtj0X7lXO9Keu1uP7zcNpUTcfXiz8Xy+OlPl2Y3zo9P22Pl7J++lYdD09F
ef3AelFXl3zRSIwCHfOANgDQBgVa9hsub37SH0kHEU8HGtCBgx9o7Lc6iMZ/UnLmKtE8lcSASmJUJQTuzjfmrAPD00EE6CBCdaDHdeCEtznrQPF0kAA6SFAd
mHEdON+Ysw4kTwcpoIMU1UE8roPsA+mAqYIMUIED35gKsnEVSPmBdCBYOtBiWgf9NpQOknEdOK40YxXwZkVaAipwLHh0sfCRbJ037Gpg+avh5a8UH8PYz3We
71fbH/m5tic97YIshprGeFODN9V4U4U3lXhTATeVGd40tZoe8l1xOazy/dXCq2K7Oh33uU3TSpKAjkBYbmut/3LeVEX945DXV6Z0DipGndAKdj3e5sbdXNe0
w6TlVP+JGuJX11nk8ZRf3arp3eI3D79iohex0NMEeimJnp0NmQd6MQs9RaCXkOjZI8c80DMs9CICvYxEz045zAM9zULPjKOXKRI9O5c8D/QUC72YQC8i0bNT
jvNAT7LQSwj06DHXTlTNAj0eeCkBHh327AzTLMATLPAyAjx6vmLnhmYBHm/IkGIcPSkmJst2XmcW+PEGDUmsNaSQNH7vb7WR/zxV+fm8qqtNeT4dq3r1Nd9b
a8u3tfVyV1Qdeu3yD6ePHHrj0J9P+6Kuc2fAb+fqulEexX2MOiKpv23O9aooz3k1xjh6xRpHVuMpuXRQr4x/rzSnV4bZK+kvl2SyUv6sFAcCwZOry9d4ydWR
MiAQITbUZYv8BE1HBKVCwEq2CR/jRTXRRfoLccc39AsRHb7oL0SODHAA7GDz1HIUQhyHEJsQYh1CLEOIVQBxCGMRQBuCFtbfybGd6dZj48oknwA5TWAYcMMI
LwhQQeR8+Xqd2TX/aVlU9Pm/CczQ3HVoBh/1a8mMfuVO996irg6JmZHzBa+YqUK+0E0dmSkS/dllHGNLfmprj9oTTIHd9NTdD/w1i4lfuZYYs+Nms7UFFbfj
1KrFEFHPjOG9LQ3m+K3MNLWGblKHQxqi1C970p8Pm2p0euX6nkExM46NvEnEMZBN+Vz/KMrv1L6x05ehDcnkzY9+VY15qnEQY38Qk7uBONKXgVCK9iV9KIOI
OQYB1MKn0YBBDDGOOIyBAvA0BhkbDmOgxDZjxBHtbTaZO9bc2QWMvwtkD+UCmmMQQN17JnCDkP4G8VgDi+SACBTsZkMDy2DhDocxUK2dDcWRsUyUv/aiB3Nn
4d+VhxrQBMMckIrZLMHskGX/QLW0FHgUCQgiDxWJOa6MVIBKgc9O/Ufmbv/ukXzZPyx1e2kPYxCckRmpvZaiXxM5tjY2/KVxfz2a9GfBcC4qIDkTE6mZ8ajF
CVtSZNZZjKEQNcSFE5SlSMGvcsJF89W+7EOz9iEuHBtsEOlzUSAXzqKkkb3PBZwrSc6aq5G9zwVc2UlOjqH5ap8LuIyTnIVrg1CfiwG5pCwuxuKCzh0yFpfY
4gL6i2J54VX2fsra8pexrKLMutgpPrM3Ixs6EZzfliHZaT0twtgOV+PBImTTZtUG4yAAVOAHslABROAH0kD6ZJye2j1PCMOh6GJPumBDDXWV2A8nHSo34F8k
vfGT2wQHhkC5Ccckqzo87Uv50Qk/MkpKBJ3AoEHohhCaggjhGmjJfgYR6n+E29PDWxI6uFGREqEPHJkCxxVqXKMcw9N/JeWIkLx+PiFD7YuaP1F8Q50xdOJD
TT0pualxnKILHY+k3zgoPec5MtR7JTEvg+j95ivd6i1EbiLsUHyzUL6B8Ur5xStFxR2kpr/Lm/UYD5fpDN2hpm+qcYZ+f3+H55BCeOVbFBmHEJsQYh1CLEOI
VQixCCBuPXqSeLp+T/kU/Uk/kdNwkaNp7tPVfkHrrtbKQ7uggLxVVw2nbrNWaD0bmFKzque0leeeyk9ItLwL3oRErhCNEljIGBUy4giJXL8ZC1jICBUy5giJ
3E8ZZWBBg+Zwhq5hNDA8ug/PVE4FQtJw+oNcaRhruD8S749C+6M4/UGupovBbYK2NzBn5GLCGN1q4zBGroJLJKpCXIMCVCAjZGsBVIioRKGdUXBnNNgZhjFq
gQT8BNx/Y0QpLYCteWVtmdNb84q7u+RMRPjpK4XZK26wErVYzixDKXRrk+PUqr9/qhS6F8wJlspYTOAJksTHLYnGeckZh1V/F1tptLqAMxfS0mICj+sSnfZI
zmCtUktfGSwPOnmQnAmttuxHo9vvnLmeyiwm8GREJriRonPpbpGH4mM5sUZH/4zDhK4bmMqagfik6PDIiZzaLhGy7NvAqlZWZJ9eSaougoHHMKxA4KTGBsbX
xKqzSdwrbTxSff0hFZReD9fmJc5Vm6M3+Jvof0r/idvs3++BB+8Om/1+td8cThZ0MUfVE3evexRn5n/n1VR55nqBGXqXhhw5gTt5OYcPnfakM550ypNOetIJ
P7o2eAachO4yjSOniycvnghiHLeMrVhOJMJGTo8ORJTsHscGgasjRs/2Tx6fhPuu7ljITaTeGLq7x8kE4PKNkFs//PRueHp3h8Y7613z5L/HOUfg3pSQa1P8
9K54uN3vFBaRe2XI/4D+LgP0rnz1zoOtO4LxQGoXPPH1w2k9QOnCV+e8ECkf7TYEXqTqTng8lM7JID19WVPwXU0B82dnXcNPbGsXpimSm7ulJl6KiKCWEdzS
wC013FLBLSXcUqAt25Ub1jLtt0RfdIj75jl8FtQ5AJT1E3laONf4Ei8UuI0fvlgLfaPAC81mOdZD073Ul0BznjcAt0siT9vMLDSdK34pNN/ffcDoCxCethlZ
aDpPZFBozvM9De2PplXmJZ3nWig05/m2i/RH0/Z0u0CIRNNpPAs0lT+aqYWmU1NNofn+CrDBFyT8wLTO+mvpvE9CgTnLx0yEP5jaAtN5roQCc5Zvm/gPQdbZ
fS2dvV4KzFm+deIfM63rFrTkrIPcxg8PJpqzCEh5GJucl/Jo1w08gdvJcViW5GbhjR4MAN9wbC6vJZYz/erSybezmxV/6mXp0IGADH5VVdvPqtrG/67eTp3E
PfbHHTk+kGkYd0G8nz1kWzNWSuSvFOTgSeZU58DOYB8FIlbgc1eS8VcSclyk34hWkqQ8x/HAOStF+ysFOZPUb0QrRVFKmaiPm5dSlL9SkINIGVyB6TgDkaSZ
u1Kkv1KQM1r9RrRSDKUU5zszVkqATpDja1mG6yShdOJ8Z8Y6Eb46gU7hWY1onUSUTpyRacY68R7loTN9ViNaJx/JFbzHcegMp9WIhj2mXMGZD7xDnbwui20r
7UtR7vJmaCDzPlcEunZqSSUXr9/9o8rrS1V+evojL3f/AN6EzvL8lQAA

[siggboy]

wire all chests with input of arithmetic combinator sum/#chests=iron, this will be 1 if all chests have one iron otherwise 0.
wire (same color) combinator output to every input and output inserter.
wire (different color) every chest with every input and output inserter.
input inserter rule: iron=0
output inserter rule: iron=2 *might not work due to inserter timing, in that case it will get a little more difficoult

I don't see this working at all, for several reasons (I've tried something similar briefly).

If both inserters are active at the same time, the item won't even land in the chest. One inserter will simply hand the item right into the next, as if the chest wasn't even there.

Also, how do you ensure that ALL inserters put an item into ALL of the chests at the same time? The item flow in on a belt, they don't get dropped with a helicopter onto all inserters simultaneously. The chests will not fill evenly -- but that needs to be the case, otherwise your counting algorithm will be completely wrong (you divide by chest count).

If I understand you correctly, what you're trying to do is activate all inserters along the belt at the same time, but only if all chests are empty, so you can pretend there's always the same amount of items in all chests, and that way you can just divide the sum by the number of chests and get a count per chest. The problem is that you pretend that there's a full belt of items in front of all inserters, so they can all grab an item, and then the belt will fill up again for the next round.

So this already requires that you fill the belt before you start the contraption, and even then it will stop working right at the moment when the input belt is not 100% compressed -- because your inserters need to remove items EXACTLY as fast as the belt brings them (if they're too slow the belt will clog up, if they're too fast you won't be filling the chests evenly any longer).

Now, if everything is perfectly synchronized, then you don't need a counter at all, because I can tell you that 22 smart inserters are required and the item count will be exactly 2400 items per minute .

[siggboy]

keep a running total of the quantity buffered inside the chests.

What do you mean by "running total"? You get the total count of items in all chests by summing up the chests... ie. connect all of them with wire. No combinator required.

Also, it's potentially quite convenient that if we chain them like:

[ first order derivative combinator ] -> [ high-pass filter combinator ]

(in other words, exactly as pictured in combinators "A" and "B" of your OP), I can accomplish both by wire-summing signals from the middle of the chain into a "buffered storage count accumulator"

The "buffered storage count accumulator" will contain the total number of items in all chests. Which is what you get by simply connecting all chests with wire (see above).

and wire-summing signals from the filtered end into an "in-flow count accumulator" (like combinator "C" in OP). If I were buffering meaningful quantities rather than working with just one item at a time, (i.e.: a similar device that pulled from chests rather than belts and thus expected an unpredictable number of items to wind up in the chests), I could then calculate exact cumulative throughput by taking the difference, which is pretty sexy. However for purposes of my "belt counter" thingy, it's probably acceptable to ignore buffering.

"Throughput" is a velocity, it only makes sense if you measure it "per time unit" (e.g. per second/minute/...). What do you mean by "cumulative throughput"? The throughput across all chests?

I think you got carried away a little and now you don't see the forest anymore for all the trees.

[siggboy]

Anyone got an idea for how to output a single tick of output when a signal goes from 0->1, and stay quiet until we go back to zero and then back to one, again, with a single combinator?

You can do this with one combinator if you don't mind having to use both red and green for the output with the implicit summing. It's combinator A from the OP. Consider the following crappy

I love the simple edge detector (your version), but "implicit summing" by putting R+G together is cheating . In order to take the implicit sum you need another combinator, making it a two-combinator solution.

(I'm sure that you know this as you were alluding to it in your post.)

Sadly, it's often not possible to put R+G together and use the wire-sum technique, because you need the edge signal on a single wire, or you need to have it already filtered (only rising or falling edge). But some day I'll find a way to use this nice edge detector and I'll be able to save one combinator, yay .

[siggboy]

Alright, I'm taking another stab at this, before moving on . It's fun after all.

So I've made another circuit that actually calculates the Throughput through the buffer chests (instead of simply integrating over what gets added, which is kind of useless without any point of reference).

accumulator.PNG (203.09 KiB) Viewed 28378 times

The combinators do the following (going from the lower left to the upper left):

1 - (lower left) A clock/counter that increments a value every tick
2 and 3 - Clock divider; We multiply by 2^25 and then check for negativity - the result is a signal that oscillates between 0 and 1 with a period of exactly 128 ticks (about 2 seconds)
4 - This is an accumulator (integrator) that is active while the clock signal is 0; so it will integrate over the amount of items added to the chests for exactly 64 ticks, then reset to 0 for another 64 ticks, then starts integrating again etc.

Technically we already have our result (throughput per 64 ticks), the other circuits are just to hold this value so you can look at it (or update a nixie tube or something).

The middle column pulses out the result from the integrator just before it resets (after the full cycle of 64 ticks), the right combinator is a register that holds the value for the other 64 ticks (while the integrator is accumulating data).

As a result you get the throughput of the belt over the last 64 ticks, held for another 64 ticks, then it updates again.

Done.

(64 ticks = 1,07 seconds).

I get around 41-43 items/1.07 seconds on a compressed belt. When I disconnect half of the input the value drops to around 20.

Pretty much what is expected from a compressed blue belt (40 items/second).

One last remark: Of course it would be TRIVIAL to calculate the throughput per TICK (it's what the array of buffer chests pulses out every tick). Unfortunately this value is less than 1 on average, so what's displayed would not make much sense (1 tick is not long enough, the signal is smeared by aliasing effects).

Blueprint:

Code: Select all

H4sIAAAAAAAA/8WWYY6bMBCFrxL5Z2uqAElaaeuTrFbItSfJSGAjY3YXody9E0hbyEIgKNX+C2HmYb7neUbbVWqVTFeJqMF49AiFqGsjMxBMg0INLlA2+4VG
eusYz21BRdaI+l0E8bctr0QQnbhGB6r5P+LKGtNekNQzC9mLqB1okm2eUCWoRcgVOlWiP19Qf+fWj9OJHxyA6TVs+g1U88yiSeVwUCu6KqEiWrPGy5Ivry3q
PbrCJwUejExF7aucmLyi86VMGW8RtTeDCtLUvrFGp/DSeLGmn1ku3ZmaYIJxW/q8nKcGr+Aqf0RzaBTzKlG2ND7ZO5slaEhGMO9KYOeVX7ySDv0xA49q3K71
Yruu6Q9ADecaFN+m/+9FFhlQwFnsqgc9ZH8a0FkTWEfwuM2B/DlTYF9GDBru7HCfmpFoMfNofETiaTt2D7JjwTDQEz5zEuamVjhtyUes27lYrzNmamLCnsG7
h5siTYfjoDM/73Kmk3iDruxlWtwdUK0z664xu1mz8n3MlomD5FHxA1Idu2TjeLvdbOJoTsTcUlwW8It29ugB+7H0/yb4X4hhl15wF70mghZtvhnsZm++m4X9
gd9+AtKviwa+QzUDjWUWQEqEHKHNbQp9qOuW6N1fhA0BehCqpqVGo+GdSm65SctqyyI+ehCQ5pMDXzqzSp7A6N+hxFAr/woAAA==