How to generate a predetermined number of pulses?

Motivation: I have a grinder that spawns spiders which are then moved to a very small space. When they accumulate in big enough numbers, I pull a lever and let a piston crush them 11 times. Then I can kill them with one hit and harvest experience.

This becomes a problem once there are a lot of spiders - the game starts to lag and it is difficult (if not impossible) to have the precise number of hits.

Question: For some n, how do I create a circuit that generates n impulses before shutting down?
Or in this case, how do I make a piston hit exactly 11 times?

• You should be able to do this by using a lot of repeaters, something similar to youtube.com/watch?v=EfwmkHruBsw (second example) but with only one piston. It may be a bit clumsy for higher numbers though. I'm at work now so can't give you a more concrete example yet. – Hex Feb 29 '12 at 12:16
• Your title and description seem to contradict each other. The title says that you want to output a certain number of pulses, but the description suggests that you want to check for a certain number of pulses coming in (like spiders falling past a tripwire). Which one is it? Alternatively, @SF., which of the two do you want? – Fabian Röling Jan 29 '20 at 19:41
• I have for now assumed that you want a number of output pulses. – Fabian Röling Jan 29 '20 at 23:43
• @FabianRöling: Output, I don't see the ambiguity, OP wanted to generate 11 pulses on a pull of lever. – SF. Jan 30 '20 at 0:20
• I read it as "when enough spiders have passed by [whatever detection mechanism]". Because crushing them specifically 11 times does nothing useful, only crushing them for a specific time. But whatever, the asker probably isn't here anymore and my answer fits to your interpretation of the question. – Fabian Röling Jan 30 '20 at 0:39

Lightweight version
It seems I overcomplicated things a bit on the first attempt, this version should be better and more compact, at least for smaller numbers (first example produces 4 pulses). It's also possible to connect the "start" for another pulse straight from the second torch).

For this setup to work with a high pulse count you will need to put repeaters every 15 blocks in the redstone line, and for each of those repeaters there will need to be extra ticks between all stone blocks. This exact setup will work for your 11 pulses (last 6 blocks of 11 shown):

Heavy version (no limit)
Basically an outer "zig-zag" circuit that will send a new pulse straight through the middle line each time it passes a stone block. I tested it with up to 11 pulses, and you can just extend it as much as needed. Obviously it gets quite clumsy with a large number of pulses.

• Great job on the updated design. Be sure to account for the repeater(s) required when expanding to a higher pulse count. – user9983 Feb 29 '12 at 20:48
• @OrigamiRobot Excellent point. It might require some tweaking to work with high pulse counts. If all else fails, the bottom one (clumsy as it is) should work for longer distances. – Hex Feb 29 '12 at 21:55
• Now your heavy version is too heavy! You should get the same effect and save a lot of space/redstone if you just modify your light version by placing repeaters in the output line every 15 blocks. – user9983 Mar 1 '12 at 13:32
• @OrigamiRobot That was my first thought as well, but it messed it all up by causing too much delay (all the pulses prior to the repeater ceased to work). Ran out of testing time though, maybe I'll give it another shot tonight. – Hex Mar 1 '12 at 14:09
• You could probably fix that by increasing the delay on the repeaters between blocks by one tick for each repeater the output will need to go through. – user9983 Mar 1 '12 at 15:06

The problem of generating many short pulses can be broken down into generating one long pulse and then letting a clock run as long as that pulse is active.
Having a clock running as long as an input is active is easy, it's the classic comparator clock.
And how to generate a long pulse easily? Whenever long times are involved, hopper timers are always the solution.

Here is an example circuit that outputs 2 pulses per item that you put into the hopper, therefore giving you a range of 0 to 640 pulses:

The concept can be applied to slower clocks for lower pulse number multipliers, you can put something in between which slightly lengthens or shortens the pulse to get uneven pulse numbers and you can use an arbitrary input other than the button, for example something shorter to have 2 output pulses for 1 item (this example outputs three pulses for a single item, because the button lets the piston retract longer than the circuit itself would).

The blue circuit is the long pulse generator, the lime circuit is a regular comparator clock that turns the long pulse into lots of short pulses.

Note that this circuit probably abuses a bug, but a very widely used one: Pistons do not receive signals from their front

How it works

The button flips the state of the memory cell behind it (redstone torch turns off, repeater turns off, other redstone torch turns on, other repeater turns on, ensuring that the first redstone torch stays off). That makes the sticky piston retract the redstone block, which unlocks the hopper in the back and locks the hopper in front, causing items to flow from the back hopper into the front hopper. Once the back hopper is empty, the comparator on it turns off, turning on the corresponding redstone torch and flipping the state of the memory cell back to its starting state. That extends the piston again, causing items to flow from the front hopper into the back hopper.

As long as there are items in the front hopper (so from shortly after the button is pressed until the moment when the front hopper has emptied itself into the back hopper after the piston has extended again), the comparator on the green concrete is receiving an input power of at least 1. That powers the comparator, turning on the redstone wire, the repeater and the other redstone wire that points sideways into the comparator. Because the comparator is in subtraction mode and the side input always has signal strength 15, this turns off the comparator output, the redstone dot, the repeater and the other redstone wire, causing the comparator to turn on again, if it still detects items in the hopper.

The input can be pretty much anything, not just a button, as long as it gives a pulse of at least 2 redstone ticks. Even if the input turns on and off multiple times in the first half of the time that the circuit runs, nothing happens differently. If the input is longer or reappears in the second half of the intended runtime of the circuit, then the circuit just runs longer than expected. If there are very short inputs a few times in quick succession, a redstone torch might burn out (which fixes itself after a while) or the sticky piston might leave the redstone block behind when retracting, due to a bug, this will not fix itself. You can prevent this by putting a pulse lengthener directly at the input, for example a repeater on second setting should be enough.

Size and materials

The blue circuit without the input button is 3 blocks long, 3 block high and 5 blocks wide. You need 8 regular blocks (the 3 with redstone torches on them need to be solid, the other 5 just need a solid top surface), 2 redstone dust, 3 redstone torches, 2 repeaters, 1 comparator, 2 hoppers, 1 sticky piston and 1 redstone block.
(You could get the button inside the 3×3×5 box by placing it on the underside of the block, but you will likely want a different input anyway.)

The lime example circuit is 3×2×2 and you need 6 regular blocks (the 2 top ones need to be solid, the other 4 just need a solid top surface), 2 redstone dust, 1 repeater and 1 comparator.

Checklist

• Did you use a sticky piston?
• Is the comparator in the lime circuit on subtraction mode, but the one in the blue circuit not?
• Is the desired number of items in the hoppers and are the hoppers sufficiently protected from having additional items accidentally fall into them?

You should be able to build everything from the screenshot, but maybe you prefer a structure file download: https://drive.google.com/file/d/12izYFzNhMzO3K4FzFar05yWSu6j2j2fs
This file should not get deleted, but if it ever is, just tell me that I should get it back from my January 2020 backup.

Alternative 2×3×11 design

This design is just 2 blocks long instead of 3 and also 3 block high (displayed here as 2.5 blocks high, the same works with the other circuit), but it is 11 blocks wide, uses more resources. Maybe this is useful for someone.

The principle and the timings are the same, except that using just 1 item does actually output the expected 2 pulses and that the duration from pressing the button to the first output pulse is longer. Here the right hopper is the one that a comparator can be attached to for running a clock.

You need 12 blocks (the 5 with redstone torches on them need to be solid, the other 7 just need a solid top surface), 3 redstone dust, 3 redstone torches, 3 repeaters, 1 comparator, 2 hoppers, 1 sticky piston and 1 redstone block.

A 1 block long design is probably also possible, but it would very likely be higher and even wider than this one. If someone wants me to attempt to create one, just tell me in a comment.

you could use a loop of minecart tracks and put several detectors on it connected to the pistons. A good example in use would be in this video:

shown at the time 2:18-2:38. The system that is being used is the T-FlipFlop which is explained in this video:
Using this you can test it out and calibrate it to your EXACT needs.

• -1 Please provide more details of what you are suggesting. If possible, an example would help a lot. – user9983 Feb 29 '12 at 21:15
• The concept is actually so simple the video was entirely unnecessary. Just start a minecart on input pulse, run it over a specific number of detector rails. – SF. Feb 2 '20 at 14:07