Talk:Redstone circuits

This page is getting incredibly messy, so I'm going to attempt to do some cleaning and sorting. Anything resolved or not replied to since last year has been moved to the archive. From now on let's try to keep like topics together instead of duplicating, and stick to the new sections =) --Mwr247 23:19, 29 April 2011 (UTC)

Page Layout
For discussions pertaining to the layout of the page as a whole.

Standards
Discuss standards here, like table use, image placement, categorization, etc.

Redesign
So there were a few topics I archived, mostly old, regarding a redesign to the page as a whole. Fact is this page is just growing so large and cluttered with every possible circuit design, and space isn't being effectively utilized to present them in space saving and efficient way.

For one, I think listing every possible variation of a circuit design is just overkill. Maybe we could have a subpage for each one which would list that, but really we only need one or two on the main page for people to test and understand the logic.

Secondly, I seriously believe we need to deviate away from MCRS for our diagrams, and even more so away from these animated images. MCRS was a great idea and works fine for testing designs, but it really lacks in the way of presentation to people who are new to this (and even some of us old to it). Call me biased but, something closer in design to the master image would be great. maybe we could find someone to make this or convince the MCRS creator to change the standard? As to the animations, they are just horribly annoying, confusing, and lead to worsened standards since few know how (or at take the time) to put them together. In place of these, perhaps some sort of paged content area, where the viewer could hit next and back to navigate between the levels (possible in wiki formatting? I'm sure we could put together a template for it).

Anyways, these are just my thoughts. Anyone else have anything to add? --Mwr247 23:41, 29 April 2011 (UTC)

General Descriptions
Changes, issues, and suggestions relating to the main text for the page belong here.

Compromised
Would it be possible to go a little more into detail about what it means if it's compromised and what adverse affects could result from compromised circuits? Youssarian 19:54, 13 February 2011 (UTC)
 * Not necessary if you spend the half-second to build the connection and realize what they mean. That is, when you connect wires like that, they share their ON/OFF state throughout the entire wire, until they get to something their state is independant of, such as the output of another gate. Diodes now can cut allow A while not contaminating your inputs.Firehound 09:42, 14 March 2011 (UTC)

Confusing terminology in Basic Mechanics
It seems to me the descriptions in Basic Mechanics are confusing and possibly using the same word for multiple meanings. In particular:
 * Redstone wire is defined as “active” if it is “immediately adjacent to a powered block”.
 * “The block under a pressure plate powers itself and all horizontally adjacent blocks when the pressure plate is activated.”
 * “Redstone wire beneath [a block with a pressure plate on it] will still be powered, because it is adjacent to the powered block above it.”

This indicates that the rule for redstone wire is indeed that it is active if it is “immediately adjacent to a powered block”, whether or not that block is actually able to transmit power into the block containing the wire (indeed, a block with a pressure plate mounted would not normally be able to transmit power to redstone beneath the block). This all reflects game reality as well.

However, another rule states that “A device, such as a door, a minecart track, or a block of TNT, is activated when an adjacent block is powered.”. Now, a device on top of a block will activate when redstone wire running up to the block is active, which makes sense given that “Redstone wire powers the blocks horizontally adjacent to the ends of the wire only.”.

However, running redstone wire up to the side of a block will not cause redstone wire underneath that block to become active, despite the fact that the block is “powered” (according to the activating-devices definition); the problem is that it's not powered according to the “transmitting” definition.

I therefore propose that the problem is overuse of the word “powered”. For example, I think the first bullet point at the start of my discussion should be that redstone wire is active if it is immediately adjacent to a transmitting block, not to a powered block. I think the section could do with some cleanup in general to strictly differentiate between powered blocks and transmitting blocks. Thoughts? Hawk777 05:47, 18 March 2011 (UTC)

Redstone General
For discussions on things pertaining to redstone as it relates to circuits.

Changes/Discoveries
Changes and discoveries relating to redstone circuits belong here.

Max distance runs
I've done some experiments and found that the farthest you can get from a redstone circuit is 17.5 chunks (281 blocks). In other words, if a clock generator is placed in chunk #1, as soon as you cross the midway point of the 17th chunk it will cease operating. Important to note that it will not begin operating again until you are within 10 chunks (160 blocks). I have only tested this in one direction (North/South) so I'm not sure if a diagonal makes any difference - probably doesn't. That makes the largest redstone circuit design effectively 17x17 chunks (272x272x126). Smidge204 22:00, 9 October 2010 (UTC)
 * Excellent work, thanks. I think the maximum circuit design would be 35x35 chunks, though, as long as the player is standing directly in the center. I think this belongs as a technical note on the main article. --TaviRider 17:29, 20 March 2011 (UTC)

Bugs
Discussions pertaining to redstone bugs as they pertain to circuit designs belong here.

Problems with Redstone Torches
Rewrite: I've noticed when a the power going into a torch changes for one tick that the torch will not correctly update the next tick to what it should have been. This can lead to problems with edge triggering and making certain designs that require that have problems. This could be the cause of the T flip-flop E design not working and I believe its why some of my creations do not work properly. On rare occasions like maybe 1/15 or so attempts the torch will correctly update when this happens like it's supposed to but it's unreliable. Also this problem does not occur with redstone repeaters.

Here is an example. (this happens in minecraft but I'm using the simulator to easily explain it) A 2-tick edge trigger is attached to an RS Nor Latch to show that the power doesn't affect it even though it reaches it.

So is there anyway to contact mojang on this serious issue? It causes problems for designs using edge triggers and makes certain things either impossible or much more complicated to build. Jrob 17:11, 18 March 2011 (UTC)
 * I believe that the torches are behaving as designed. They need to be powered for at least one full tick before they will deactivate. I consider this one of many practical limitations that keep redstone from causing too many block updates.

That said, if you still want to report it to Mojang, post it on [Mojang's GetSatisfaction page|http://getsatisfaction.com/mojang]. --TaviRider 17:28, 20 March 2011 (UTC)
 * I guess this makes sense, but there must be some way to fix edge triggered to behave properly. Maybe all redstone devices including wiring should only change state at the begginging of a tick, this way nothing will get powered half way through a tick leading a torch to not recognize that first tick.

Jrob 21:43, 23 March 2011 (UTC)
 * I have run into the same issue with design E some work some the edge trigger fires too fast. So I redesigned the edge trigger to be adjustable. [[File:Vertical_pulsar.gif]] The arrow is a relay and on setting 2 has always worked for me when the one in design E failed me. --Yssaril 22:53, 23 March 2011 (UTC)

Gate Designs
For discussions pertaining to the gates and their designs.

Design Standards
This section is for the discussion of design standards and methods and what should be included.

Missing Logic Gate (For Completeness)
The truth tables made me notice the list of gates is incomplete. Some are on the list or are input-switched duplicates of those on the list: nor; not a; not b; xor; nand; and; xnor; A implies B; B implies A; or. Some are trivial: always off; b; a; always on. That leaves two possibilities (one and it's input-switched version): b and not a, a and not b. I know it's a simple gate, but it should be included for completeness; It's basically just invert one input, join inputs, invert if anyone can put together a diagram (or an 'and' gate with one input inverter removed).

JK to T flip flop
Is it worth noting that a JK flip flop can be used as a T flip flop by connecting both J and K to a single input? I verified this myself with design C, with the clock either always on or just connected to the same input as J and K. I realize that most flip flops can be used as other types but the simplicity of creating a T from a JK makes it the most useful I think.
 * Is that really all that useful? For any given layout style, the TFF is a bit smaller than the JKFF; it seems counterproductive to eat up more space building a JKFF only to use it as TFF. Hawk777 03:40, 28 April 2011 (UTC)

New Designs/Discoveries
Have a new design or discovery you want to submit for peer review? This is the place to discuss.

Update with new Redstone Repeaters?
So is anyone going to update these designs/schematics with the new Redstone Repeaters? I'm sure that some of these can be simplified a bit using the new repeater blocks. SpikeX 19:50, 24 February 2011 (UTC)
 * I've already tested and proofed some smaller designs for the RS NOR/NAND gate designs incorporating the new delay/repeater/diode block (2x3x1 and 3x5x2 respectively), and other gates could no doubt benefit from their inclusion (clocks and pulsars being some of the most significant). I think we need some official diagram image representation and then get to work on rebuilding some of these =D --Mwr247 20:50, 25 February 2011 (UTC)
 * 1.3 is the first version I have played, and I've noticed some of these designs no longer work, particularly when they involve edge triggers. The power will come on and off too quickly to trigger the torch.  The wonderful thing about repeaters is that adding one to one side of the non-triggering edge trigger seems to always work.  It's been a while since I did circuits and this is helping me remember my lab class... but would greatly appreciate updated circuit diagrams with repeaters nonetheless!
 * Joren (talk) 22:23, 1 March 2011 (UTC)

Compact T Flip-Flop
I was trying to make a T flip-flop more compact using repeaters, and this is the result:

Is this worth adding to the wiki?

Output is at (3,3), and (4,7).

Input is to block (3,2). RT-073 20:20, 4 March 2011 (UTC)

Edit: It seems to only work when the button is to the north or east of the flip flip... Has anyone figured out if the south-west rule affects repeaters?

RT-073 19:03, 7 March 2011 (UTC)

New T Flip-Flop design
I found a new design for T Flip-Flops. It is really small: only 6x6x2 ! I added it to the page as "Design G" but I am not allowed to upload files so it is currently a link to an external image. If someone could upload it and add it as a thumbnail under the other designs... :)
 * Please sign your statements so we know who you are ;) Anyone want to test this for functionality? --Mwr247 23:19, 29 April 2011 (UTC)

New Monovibrator Design
So I came up with a new monostable circuit design that doesn't rely on torch burnout, would this be something that we should include on this page? --cptroot 12:06, 26 February 2011

Two-Way Repeater
A while back, I created a new type of redstone circuit (as far as I can tell) which acts as a two-way repeater, essentially serving as an elongated strip of redstone. Unlike normal repeaters, which only work in one direction, this circuit allows a signal to be sent through it from either side. It does not have a traditional input or output, but rather two spots which serve as both input and output, depending on what is attached to them. Whenever either one of them is receiving power, the other one is also receiving power. Whenever one of them is off, both are off.

Also, this circuit even tells you the direction the signal is flowing. Of the two torches which appear unlit in the diagram, whenever the circuit is powered, one will be lit. It will be the only lit torch in the circuit, and it will face the direction the power is moving. Thus, if there is an input from A, the bottom-right torch will be lit. In short, the primary purpose of this circuit is to simulate the function of redstone wire without restricting signal direction like a repeater, but it also happens to indicate which direction the signal is flowing.

Anyway, can I have some feedback on whether or not this should be added to the main page? Sorry, I posted the above without signing. Tamugetsu 18:07, 10 March 2011 (UTC)Tamugetsu

Redstone Repeater XOR Circuit
I've come up with a new 4x3x3 XOR design using the properties of the new (1.3_01) Redstone repeaters; I wasn't sure of the repeaters graphic but its easy to identify. --Dingmatt 22:24, 28 February 2011 (UTC)

Binary Counter
I have a binary counter set up that seems pretty simple... It's just a counter, a couple T Flip Flops and some AND gates. And instead of drawing out a diagram for every single piece (it is more than a few, I assure you), you could show how the outputs of the pieces should be connected. It's pretty simple once you have the T Flip Flop, Counter and AND gates down.
 * 1) Counter connects to the T Flip Flop (A), our 1 value, and presto, you can count from 0 to 1.
 * 2) The output also goes to the next T Flip Flop, (B). This is our 2's slot. You know have a binary counter that goes up to 3.
 * 3) The output from A and B go into the AND(a) item. The output from that AND(a) is sent to T Flip Flop (C), our 4 column. It is important that the output from A and the output from B are the input to the AND(a) gate.  If you invert to extend the length, invert back again. Also, the output from AND(a) must be the input to C. I can't stress this enough.
 * 4) Now that you can count up to 7, it is time to add the next piece. You use the outputs from sources AND(a) and T Flip Flop(C), and plug them into the next AND(b). The output from that connects to T Flip Flop(D). You can now count to 15.

That's as far as I've gotten, but you could follow the same pattern and potentially make it longer. The problem is, I use a 5-timer and the 8 column is *just* changing by the time the 1 column changes for the next number. You would have to have a timer that runs even longer than that. Or condense the counter somehow that I overlooked this early in the morning, so that there isn't so much delay.

Please respond with any comments, questions and concerns. -unsigned comment by Chevnoir 12 Nov 2010
 * Starting to build this with T-flop design E (edge triggered). What T-flop design are you using, FYI? --JellyfishGreen 12:02, 29 November 2010 (UTC)
 * I have successfully made a 35 bit Design E t-flip flop counter that when wired to tick once a second, will last a year before resetting, however this was simply by daisy chaining them together without any AND gates. May I ask, what is the significance of the AND gates and why are they needed for the design? --Crozone 12:25, 7 February 2011 (UTC)
 * This is brilliant, by the way. Mizusajt 07:44, 13 February 2011 (UTC)

Design Issues
Finding problems with designs on the main page? Post them here.

T-flip flop design F is NOT a T-flip flop!
I've tested the design. Once it recieves a fixed input, the output pulses on and off like a clock. This is not what a T-flip flop is supposed to do! --Munton 14:34, 13 March 2011 (UTC)
 * Seems the diagram is missing, but the table and body still reference it. Should be removed? --Mwr247 23:19, 29 April 2011 (UTC)

XNOR A not working
I've successfully built all the other gate types, but XNOR style A isn't working for me. It's behaving like AND instead of XNOR. Can someone confirm that the gate diagram is correct? --TaviRider 19:03, 16 October 2010 (UTC)
 * I cannot manage to reproduce any of the XNOR gates. Do any of them work? --bazzaNZ
 * I was able to get XNOR A to work. For XNOR B, it seems that the direction that the switches face matters. --TaviRider 01:05, 6 March 2011 (UTC)

Diagrams
For discussing proper creation styles and presentations for the gate diagrams, as well as issues with the present ones.