Talk:Redstone circuits/Clock

Small vertical repeater clock
I just learned a small vertical repeater clock (I think it's a 2-clock) from this video. Output is to the left. I'm going to attach a picture -- can someone with MCSim skills to a diagram for it? --Mental Mouse 15:09, 15 December 2012 (UTC)


 * This circuit would be a good addition to the article -- it's smaller than the others and it's 1-wide (though not tileable) which makes it sufficiently interesting. : )
 * A schematic isn't necessary if a screenshot can illustrate the circuit sufficiently, so consider going ahead and adding the circuit to the article. However, this screenshot could be improved -- you might want to take a look at the style guide I used for creating screenshots for Redstone Circuits.
 * Your picture is a 2-clock, but the torch will burn out unless the repeater is set to at least 2 ticks, making it a 3-clock, so this clock is good for a range of 3 to 5 tick pulses (0.6 to 1.0 second periods). You can toggle this clock on and off with a lever (or other power signal) on any of the four required opaque blocks (you retain smallest circuit volume by attaching a lever underneath the central block, either to it or the block supporting the redstone), by powering the redstone, or by locking the repeater. Output really can be taken from any part of the circuit (except the repeater), not just the left. &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 18:29, 15 December 2012 (UTC)


 * Hmm. I had one of these running for a couple minutes in my lair, with the repeater on default, and neither torch burned out, but I might not have waited long enough.  I'll look at the style guide -- I already know I'd need to switch back to the default textures.  PS:  I wasn't sure if it was a 2- or 3-clock because it does have two torches along with the repeater.  Thanks for confirming.   --Mental Mouse 20:56, 15 December 2012 (UTC)
 * Got one running now, and I noticed something interesting -- two of the maps visible in the background are flickering, from their usual state to another that shows more (apparently valid) mapped area. (Uploading screenshots now.)  Also, a redstone lamp next to it does not flicker quickly, it stays mostly lit with occasional flickers of darkness. --Mental Mouse 21:14, 15 December 2012 (UTC)
 * ETA: And now it's burning out within a few seconds... not only on minimum delay, but on the next delay setting as well.  Also, the maps should be showing the larger amount of territory, it's the smaller amount that doesn't match the copy I'm carrying. --Mental Mouse 21:20, 15 December 2012 (UTC)
 * The higher torch in the video isn't part of the clock, per se (unless you've got it feeding back into the clock in some way), the video is using it to change the clock's usual 5 ticks on/5 ticks off output (the video's repeater is set to 4-tick delay) into a 1-tick off pulse every 10 ticks (the torch on the bottom turns off but the torch on the top doesn't turn on until a tick later: an incorporated falling edge detector) to make the piston retract and then instantly extend again. My builds only burn out when the repeater is set to 1 tick, in all four orientations (v1.4.5). I can't see any difference in the maps you posted. I think I remember someone else saying that maps in frames don't always update properly -- you may need to pop it out, look at it, wait for the updates to load, and then put it back in the frame (which doesn't explain what's happening, but might fix it). &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 00:51, 16 December 2012 (UTC)
 * On closer inspection, the flickering maps are changing to a (the same) different, less complete map (which is not map #0, map #0 is one of the flickering maps (and the copy in my hand didn't flicker). I tried popping a couple of them off the wall and putting them back, and saving and reloading, but that didn't help.  It also continued happening after I turned off the clock, so it may or may not be related.  Regarding the clock, that's interesting -- but the lamps I tried stayed mostly lit whichever end I put them at.  --Mental Mouse 02:19, 16 December 2012 (UTC)
 * And... I just looked at it again, and it's behavior seems different (I hate when that happens). Both torches are definitely alternating at roughly 50:50, and lamps match that if the left lamp is a block up -- if it's on the ground, it does stay mostly on-- because it's being lit by two alternating torches!   It is definitely not producing 9:1 pulses that I can see, though I could believe I'm missing them on that second lamp.  Also, the maps are back to normal. --Mental Mouse 02:32, 16 December 2012 (UTC)
 * Redstone lamps take 0 ticks to turn on, but 2 ticks to turn off (even lamps moved by a piston) -- and if the signal turns back on within that time, the lamp won't turn off (try running redstone over a lamp from a short clock -- you'll see the redstone turn off, then the lamp). The two-torch falling edge detector produces a 1-tick off pulse, which isn't long enough to turn a lamp off (or some other redstone components -- you can extend a 1-tick off pulse with a sticky piston moving a block over a torch to power a repeater). But if you power a lamp from the 5-clock itself, not the falling edge detector, it will flash on a 7/3-tick cycle (5 ticks on, 2 more ticks on after the power turns off, then 3 ticks off before the power turns on again). Pistons are a better way to observe the behavior of a circuit since they react instantly to both rising and falling edges (or oscilloscopes can give precise read-outs for non-short pulses).
 * There's a lot of really unintuitive behavior like this in redstone components. Jeb said at Minecon that the Redstone Update will affect the timing of some components, and I'm hoping things like this get fixed (or at least made more predictable). &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 03:13, 16 December 2012 (UTC)
 * Amen on the fixups... on the other hand, adding a Nether ore sucks when I've already had to explore lots of it to find my fortress. But that's another discussion entirely.... --Mental Mouse 14:42, 17 December 2012 (UTC)
 * Just to note, I've confirmed that this clock still works in 1.5. Also, it can be turned off by a lever on the base block any of the blocks, or by pulling the upper block away with a piston.  (It seems to start fairly reliably when the torch is placed.)  --Mental Mouse 12:02, 16 March 2013 (UTC)

Boat Clock broken?
It appears that the Boat Clock in the video does not work anymore. I'm using 1.4.7 and it doesn't seem to work as shown in the video. Can anyone else confirm?

--Ioncupcake 08:09, 25 January 2013 (UTC)

Better Piston Clock
For anyone who wants to throw this in the article, here's a very simple and controlled piston clock. I actually created another one that requires less room as well, 3 x 5, and if anyone wants me to post it just reply on here. 

199.187.203.27 07:32, 4 February 2013 (UTC)

Hopper Clock
2 hoppers facing each other gives a 4clock, might be useful editing that in.

89.233.84.253 02:43, 27 April 2013 (UTC)
 * Whoops, my goof. You are right, though as it turns out, it's not quite a 4-clock -- I've got one running on an ocilloscope, and it's putting out 4 ticks high but only 3 ticks low. --Mental Mouse 21:17, 27 April 2013 (UTC)

COMPACT Piston Rapid Pulsar
I just made a compact rapid pulsar using pistons and the new Redstone block. It's dimensions are (X x Y x Z) 1x2x1. Pretty compact!

I don't know how to work with the schematics, so I'll just post a screenie.

--Icrawler 03:01, 28 April 2013 (UTC)


 * This is slower than a rapid pulser: it produces a 1 tick on, 2 ticks off pulse. But it is more compact than the 1-wide rapid pulser in the article (the one that looks like a bridge of blocks), so it might find a use.
 * Ideally, images should only be uploaded for articles. If you just want to talk about a new circuit you made, the forums (or reddit) are a better place since you'll get a lot more responses.
 * &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 04:09, 28 April 2013 (UTC)

Efficient use of the clock multiplier.
I've been looking at the relative efficiencies of extending a repeater loop vs. adding a multiplier, and when to break a multiplier bank into two. The results are a little odd, especially for the latter, so I'm not ready to put them into the article without some feedback. What I've got so far:
 * If you have a 5-repeater loop (20 ticks), it's slightly cheaper to double it with more repeaters than a 2-latch multiplier. If you want to triple it, or if the loop is any longer, the multiplier wins unambiguously.
 * The odder part: Once you have a multiplier with N=3, doubling it by extending the bank is only slightly cheaper than adding a second bank with N=2, but if you want to go much past that, you're better off adding a second bank with N=3.

So it looks like the max-efficiency uber-clock would look like a 5-repeater loop (possibly 6?), followed by a series of three-latch multipliers.

This is just from some pencil-and-paper noodling, not rigorous analysis, I'd appreciate if anyone else would look at it and see if they come to the same conclusions.. --Mental Mouse 13:34, 8 June 2013 (UTC)


 * Looks right. Sequences of N=3 latches seem optimal.
 * &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 15:17, 8 June 2013 (UTC)
 * On closer examination, accounting for dust and space complicates matters:
 * R is repeaters, D is dust (I'm counting the ED torch as dust), and TR is total redstone, that is 3&times;R+D . L is length, that is blocks used in the 5-wide corridor.
 * I'm assuming the repeater loops are within the multiplier's 5-wide path. Note that repeaters always use 4 dust (the corners), with a possible fifth to match an odd repeater.


 * So, a a 12-loop beats 4&times;3, a 15-loop beats 5&times;3, and a 16-loop beats 4&times;4, both on total redstone and space. Also a 9-multiplier edges out &times;3&times;3.  Beyond this, the results seem less surprising.   --Mental Mouse 22:13, 8 June 2013 (UTC)
 * Whoops, found major errors in my table. Serves me right for calculating in the edit buffer.... ;-(  Most of the anomalies went away. --Mental Mouse 01:20, 9 June 2013 (UTC)
 * Oh my, it seems 2 toggles are much cheaper than a 4-multiplier. You might say, they clean its clock.  ;-)  On the other hand, they might not be shorter after bringing the input and output into line.  --Mental Mouse 13:02, 9 June 2013 (UTC)
 * However, it's just L5 in the ring here, L3 oscillates. --Mental Mouse 13:24, 9 June 2013 (UTC)

Spawner Clock
I had an idea about using spawners for clocks/timers and I just realized that it could be added to the wiki. The only problem is that I'm not quite sure how and in what way, so I'd rather leave the editing to someone more experienced. Now this is something that can only be made using mods or external tools, but the result is completely vanilla (so this is mainly usable for people making adventure maps), so I think it's worth a mention. Here is my video explaining the concept. What do you think? --Lord blex 18:45, 22 July 2013 (UTC)
 * I haven't listened through the whole video, but from the first part and your description here, I think this would be best placed as a tutorial, something like "Spawner Clocks For Adventure Maps". Right now I think it would do best in the "Technical" section, but it would be cool to collect enough similar tutorials to have a whole section on building maps and related engineering, not just that lonely tutorial on making "challenge maps". --Mental Mouse 23:31, 23 July 2013 (UTC)

Credit where due
I notice the citation style for first known publication has been altered. Fair enough. However, Sethbling's design does not include the additional output circuitry that I added when I independently invented the build. Put simply, the current citation implies that the entire design is down to Sethbling, which is not true. So I would like to ask how it would be best to reassert my contribution to the long period hopper clock design. Would something like this be okay? Earliest known publication of core design: 22 January 2013 Augmented design independently published: 8 June 2013 -- Sorceror Nobody (talk) 15:30, 30 October 2013 (UTC)

EDIT: Same goes for the clock multiplier, too. Certainly, the original design is suitably cited, but Mental Mouse and I put a fair bit of work into streamlining and generalising the design on the wiki. The design as the wiki presents it is therefore not just the product of the original citation -- Sorceror Nobody (talk) 15:35, 30 October 2013 (UTC)


 * We do not have an official policy on how to credit designs. In fact, there are some admins who don't think credit should be mentioned, because it creates ego problems like this (you may have noticed that in the rest of the wiki, references are given as raw web addresses without mentioning usernames and the rest, due to frequent problems with people trying to promote their own youtube videos).
 * My feeling is that "earliest publication" is useful, not because it says who created it (we're not curing cancer here), but because (a) it provides an idea of how long the circuit has been around available for others to use and gives a sense of how circuits have evolved over time, and (b) it provides a way for the reader to get more info about the circuit which may be out of the scope of the article.
 * If you had published your circuit earlier than SethBling did, then that would be worth mentioning. However, your version is really a very minor variation of his design (you just added an edge detector to shorten the output pulse) and probably out-of-scope for a clock circuit article (changing the lengths of pulses belongs in Pulse circuit).
 * My preference would be to restore SethBling's design to show the original published concept (and which also is a more general version that people can more easily adapt to their own requirements), and just say "Use a pulse limiter to reduce the output pulse", since there are many pulse limiters to choose from, not just the one you used.
 * &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 19:04, 30 October 2013 (UTC)
 * I do agree that really credit should be all or nothing as names go. I mean, I knew it would probably be interpreted as such, but this wasn't an exercise in ego stroking on my part, it was more about the separation of contributions. Still, fair points, all in all; I see no reason to debate further : ) -- Sorceror Nobody (talk) 17:11, 1 November 2013 (UTC)
 * It's tough to manage such credits on a public wiki. One idea that occurs to me, is to include an originator's name in the edit comment when adding their design, so it's at least visible in the history.  However, some changes are significant; notably, adding a new functionality without sprawling the circuit way beyond the original limits is non-trivial.  (When I was working on the automatic chicken farm it took me 3 tries to get the timer arranged so the works stayed comfortably under the chicken floor, which is way bigger than the final circuit.) --MentalMouse42 (talk) 19:53, 1 November 2013 (UTC)

Design E and NS-Quirk
What is NS-Quirk? Link's invalid. And I try to build (1.7.2) all 4 orientation (NS/SN/EW/WE) of E design and see no difference(all 5-clock) Is info about 4-clock here valid yet? If no, need add maximum version to the article. VpArth (talk) 17:17, 18 November 2013 (UTC)
 * It is entirely possible that design E is obsolete, I haven't had a chance to try and verify it recently. --MentalMouse42 (talk) 01:17, 21 November 2013 (UTC)
 * The North-south glitch was a vagary of redstone behavior, where in some circuits, torch timing depended on which direction they were pointing. Given the nature of the game, people natually started accounting for it in their circuits.  I wouldn't be at all surprised if the devs have finally stamped it out. --MentalMouse42 (talk) 11:00, 22 November 2013 (UTC)
 * I recently designed (and yesterday constructed) a piston door for my base on my current world. The east-facing door worked fine. The west facing one, two pistons were firing fractionally too early during the opening sequence, causing them to not extend due to blocks that should have moved out of the way fractionally beforehand. Talk about timing being too perfect.
 * Anyway, since the entire build was done symmetrically between east and west, I concluded that it was down to orientation sensitivity. I mean, I could be wrong, but honestly I don't know what else might explain a difference in behaviour between two builds that are 100% identical apart from the direction they point in. So I'm inclined to believe it hasn't been stamped out -- Sorceror Nobody (talk) 17:01, 28 November 2013 (UTC)
 * Was it down to torch timings? If not, the original NS-glitch might well have been replaced by some subtler bug. --MentalMouse42 (talk) 21:09, 28 November 2013 (UTC)
 * Hard to say. Each door consists of two halves that are symmetrical apart from one added circuit that only exists on one half -- the one that connects the internal button to the door circuit (the external button is pretty much wired straight in). Since the west door had the same malfunction regardless of which button was pressed, I believe I can discount those two torches.
 * This brings me to the other four torches in each door, those that power the upper and lower pistons. In each half, both pistons are powered by torches facing in the same direction as the door. The upper piston is powered directly by its torch; the lower, the torch powers a short redstone wire leading into a block, which in turn powers the piston. The same redstone output leads into both torches, so they should trigger simultaneously.
 * I don't really know enough about the bug to tell whether it would explain this. I can whip up a schematic or something for you to look at if you want to analyse it -- Sorceror Nobody (talk) 17:40, 30 November 2013 (UTC)
 * EDIT: Hm, after having checked that everything is identical to the creative test version I built to start with, and then having pasted the actual door back into creative and testing it, I'm not getting the malfunction. Which I guess implies something to do with survival world lag? Though I'm not certain why there'd be more lag on the west door since the whole span of both doors and the space between them is only 30m side to side, and more to the point is in the spawn chunks, so nothing should be loaded on the west side that isn't loaded on the east. And even if it is just down to lag, I get the feeling that the lag should only amplify an existing timing oddity rather than creating one, since otherwise I'd still expect the top and bottom pistons to be simultaneous. Though perhaps that's down to a difference between piston directions?
 * I guess I can only leave working it out for someone who understands the subtle quirks of redstone better than I do -- Sorceror Nobody (talk) 18:21, 30 November 2013 (UTC)