Id like to know if there is a way to make it irrelevant how fast you toggle the switch. The result should allways be a single short impulse. This is the regular behavior:

Regular behavior

And this is the behavior when it is toggled too fast:

Behavior when toggled too fast

It looks like the repeater is "locked" into a permanent signal by the other repeater. Is that true, can I change that in any way?

Im using this construct in combination with commandblocks that test for a player in a certain area every tick. With this error here, the whole thing leads to a wrong outcome and not the desired result.

Sidenote: Im playing on a 1.8 bukkit Server with worldedit, worldguard, multiverse and citizens. Client runs with optifine on 1.8.

Any suggestions? Am I missing something?

  • 7
    please use default texturepack when creating images :) May 5, 2016 at 14:08
  • 2
    or at least something close to vanilla (i.e. faithful) May 5, 2016 at 22:44
  • MEH! What is this candle-craft?
    – Fennekin
    May 7, 2016 at 5:47

3 Answers 3


The reason why it stops working is the repeater happens to lock the other repeater when it is powered. Chances are that design was not made to be spammed. A solution I'd suggest is make a fill clock (if you want your construct to be activated every tick all the time) or if you want it to pulse when ever you flick the lever (just like the pulse generator you where using) you can use the second design I listed.

(note: all screenshots are in 1.9 but everything listed will work in 1.8)

Design 1: The Fill Clock. This is when you have 2 commandblocks running a fill command twice every tick, and looks something like this. enter image description here

The commands the command blocks are running (from top down) are

/fill ~ ~-1 ~5 ~ ~-1 ~ redstone_block

/fill ~ ~1 ~5 ~ ~1 ~ stone

How it works is the top commandblock is run after the bottom commandblock. So the area get filled with stone (unpowering all commandblocks along the blocks) and then instantly replaced with redstone blocks re-powering them all.

Design 2:

So this design uses the same principal as design 1. It will power what you want for 1 tick, and it looks like this. enter image description here

From the top to bottom the commands are

/setblock 297 91 983 minecraft:stone

/setblock 297 91 983 minecraft:redstone_block

The commandblock to the right has the command /say hi just to prove that the stone block beside it (the block the /setblock targets) does it powered for 1 tick. and it looks like this enter image description here

Hopes this helps!

  • I don't really use redstone programming much (nor I play minecraft these days), however that is pretty much what you should do in digital circuits, however I'd like to add that the very same clock can be used to compare the vcc (MC terms: redstone torch) and know if the signal is getting there; Furthermore you can use it on all other devices you want to have the same frequency with (instead of building a clock per device)
    – Oak
    May 6, 2016 at 10:58

If you point a repeater into the side of another repeater, and power the first, this will lock the second repeater to whatever output it was last. Simply depowering the first repeater will solve this. However, in my opinion, it seems rather futile to make a pulse generator using repeater locks. My favorite design works in most situations and uses sticky pistons (1x2x3):

> # R
# T #

# Block
> Repeater (1 tick)
T Sticky Piston (facing up)
R Redstone

This is actually a design for a T-flip-flop that mattbatwings uses in one of his Logical Redstone Reloaded videos but I prefer using a comparator in subtract mode and a repeater canceling the signal at least 2 ticks later, but the one-tick version only works in bedrock, but there are plenty of Java edition rising edge monostable circuits, and if you just replace the repeater that locks with a comparator in subtract mode and extend the delay on the repeater that would be canceling it, it should work.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .