throughput detector - very simple (only wires)

[Case]

While playing around with belt throughput I found this very simple detector. It works for all belts and can detect even the slightest deviation form the max throughput - instantly.

Setup

troughput_detector_setup.jpg (104.56 KiB) Viewed 5796 times

Deviation

troughput_detector_deviation.jpg (77.52 KiB) Viewed 5796 times

Just place 9 wires in a row and set it to 'read belt content' => 'hold'. The result is 64 when the belt is fully compressed otherwise less. Why? Well 64/9 = 7.1111 and this is very close to the max item count for a belt tile (7.1444 I guess).

Case

[Yoyobuae]

Just place 9 wires in a row and set it to 'read belt content' => 'hold'. The result is 64 when the belt is fully compressed otherwise less. Why? Well 64/9 = 7.1111 and this is very close to the max item count for a belt tile (7.1444 I guess).

That IS the exact max item count for a belt. 64 spaces in belt tile (32 per lane) and each item takes 9 spaces.

[ssilk]

That should work also with pulse mode, cause on each belt must be 1 item per lane enter per tick. So it should show always "2". Untested!! Needs less CPU power.

[Case]

If you just want to know if the belt is fully compressed you are right with the plus mode .. but if you want to calculate the deviation from the max throughput the pulse mode will not work because you can not detect which side ticks. Though there is some interesting math for the plus mode, in theory you could make a perfect splitter just with wires. For 50/50 it would be 8x = zero / 1x > zero from there you need the fractions for the split result and it should work - well in theory.

[Yoyobuae]

That should work also with pulse mode, cause on each belt must be 1 item per lane enter per tick. So it should show always "2". Untested!! Needs less CPU power.

Doesn't work, belt lanes can desync. So you may get two "1" pulses instead of a single "2" pulse.

[ssilk]

Ok, disbelievers , I tested it out:

Screen Shot 2017-03-29 at 16.38.53.png (324.12 KiB) Viewed 5649 times

Which means: The throughput is 2 items per tick/9 belts = 2/9 items per tick = 0,222222222 items per tick = 13,33333332 items per second. Which is exact as in theory https://wiki.factorio.com/Transport_belts/Physics

That doesn't change if the items on the lanes are shifted:

Screen Shot 2017-03-29 at 16.42.32.png (359.57 KiB) Viewed 5649 times

The throughput is the same in any case, as long as the belt is fully compressed.

What you mean is the density. The difference between density and throughput is also explained well on that wiki-page. That can be measured of course only with the hold-mode. But it goes hand in hand: If the throughput is lower than 2 the density must be of course lower. (all for basic belt of course)

[Yoyobuae]

Oh, you meant wiring 9 belt tiles in pulse mode. In that case shifted lanes wont matter (there's a pulse every cycle).

But the signal is not clean when belt is not 100%. It probably flickers between 1 and 2. With hold mode the signal is 64 if and only if the belt is fully compressed.

[ssilk]

With hold mode the signal is 64 if and only if the belt is fully compressed.

The same with pulse mode: The signal is 2, if and only if the belt is fully compressed (and has full throughput).

The hold mode is useful, if your belt is eventually not moving, or if you want to count the density super-exact.
And I think my assumption with "pulse needs slightly less CPU" is wrong. Both should take equally much CPU. So the hold-mode seems to be a bit more useful.

I just want to be correct, and not the last word.

[DaveMcW]

Hold mode is very accurate and simple IF you assume the items are constantly moving.

Pulse mode can detect when items are NOT moving, but you must sum it over 32 ticks to get an accurate reading.

[Yoyobuae]

Backed belt detector using hold mode:
https://gfycat.com/IllustriousMeanHamadryad

Only the bit between the two middle splitters and the combinators are part of the detector. The rest is just to implement a priority splitter.

Needs combinators though (for schmidt trigger). Then again, "summing it over 32 ticks" requires combinators as well.

[brunzenstein]

Backed belt detector using hold mode:
https://gfycat.com/IllustriousMeanHamadryad

Only the bit between the two middle splitters and the combinators are part of the detector. The rest is just to implement a priority splitter.

Needs combinators though (for schmidt trigger). Then again, "summing it over 32 ticks" requires combinators as well.

Blueprint?

[Yoyobuae]

Blueprint?

Code: Select all

H4sIAAAAAAAA/8WVUW+bMBDHv0rFM1QBtd2kznvY16gmZPClsWZsdD6qRojvvnNIIiCEkqrT8oLi89++
+93ftnJ3xpXS3OWiBUuaNHjRtlZWICIFpVaASemqQltJDqO4dp4nOSvad5Gk94/xXiRZFyuNUB7Gn+LS
WUJn8gJ28k07FO1xoZwj6qDmPbYaPeVev1ppREv7mjd800iNNFHc798HE5DlLupiD0E+UWiC6jRdo7NJ
bSQBz+aca4khZxH9iGLXUN1Mt1sQ13tOtrGUb9FVubYsFoQNdCFobV8rV/ESpdFv0SIopnYAuM+1Emlc
aiwbTeEP4xmEMl7iFQHsSPDQ8fBLlH24WDor/9aFX3zsG2foSVq62rh0Vde22hBgsMNqbEyMXbGJtVXA
23BGaxr866zNjsqs+wzodEQB3msE7xNfG01cyNS7zGBz/ziEkF1oCaX1tUNKCjA0XmETFhjJZxiesgMr
CwO50j58xVYaD+fUEaTKd5LNHRbg4vzBa+f4abSfWDkFAe0cnktnTAANnfj9BlyLtHwljUmMrOqxKOsJ
Xadyvg/mr4MFo/UG5x4Mz/nP6IprPjowa9qdhGrStf3+4spECM1baeSUGSeNrTZjpc2nrDS+1J5uxrm5
heZ/Oz0PN9f1lS6Zvy0LI8s/i4fgH1qFYejywGzhUbi4SrqrD8KcbIK3G7wJzwjUoL3Ln8Gqv0pKe7q8
CAAA

[Case]

Well you can do this with only wires as well ... not sure if it is viable because you need the space for the wires.

Backed Detector

BackedDetector.jpg (162.56 KiB) Viewed 5534 times

Condition Top

Top.jpg (104.67 KiB) Viewed 5534 times

Condition Right

Right.jpg (115.72 KiB) Viewed 5534 times

Condition Left

Left.jpg (85.2 KiB) Viewed 5534 times

Wires

Wires.jpg (80.09 KiB) Viewed 5534 times

I have not fully tested it yet but it looks ok so far. Maybe with a bit more thinking you could get away with less wires as well.

EDIT: The plus mode is bleeding once in a while .. so I changed the images to the hold mode - this should work as described

[Case]

Seams the shorter version is the way to go ....

Backed Detector shorter

Shorter.jpg (122.22 KiB) Viewed 5531 times

The condition is x=64 in this case and I had to shift the first wire after the splitter because it gave the false item count from time to time.