Perhaps I am being dense, but would it be possible to post a version of the schematic where you highlight what each section is doing? It'd be useful to see which parts are just signal carrying and which actually do the active part.
That.
This thread looks mighty useful, but I can't even figure out where you connect your minecarts to it, or what the diagrams mean. I think they are side views of two different layouts of redstone that don't interfere while doing the exact same thing. I don't know where the reset is for the RS NOR is though, need help on that too.
ok ive finnished my selector for my station and everythings going great ive got it hooked up to my tracks and its all going smoothly havent done too much to it in a while. thanks all to helping me make this. if you want a save file your gonna have to tell me how and where to upload it
Perhaps I am being dense, but would it be possible to post a version of the schematic where you highlight what each section is doing? It'd be useful to see which parts are just signal carrying and which actually do the active part.
That's a reasonable question. Let's start by assuming you've read the redstone circuits wiki page and built most of the sample gates and latches described there. (If you haven't, then building this will be painful. ) Here's a schematic of just the actual logic being performed:
All of the logic there is implemented vertically except for the input to the OR (in this case, the OR is just a horizontal line of redstone) and the output of the NOT after the OR. (which is a torch powering a horizontal line of redstone.)
I've labeled the diagram from the original post with which torch or redstone corresponds to the logic schematic above. All other torches are either signal extenders, used to allow signals to cross, or carry signals vertically. (The alternating torches below the button just carry the signal down, for example.) The various parts are implemented a little differently on each of the two slices for space reasons.
It's worth mentioning that NOT OR and NOR are the exact same thing, I just broke one out into two symbols so I could label them more clearly below.
Quote from Lollerpops »
This thread looks mighty useful, but I can't even figure out where you connect your minecarts to it, or what the diagrams mean. I think they are side views of two different layouts of redstone that don't interfere while doing the exact same thing. I don't know where the reset is for the RS NOR is though, need help on that too.
You're right, those are side views of two layouts to be built side-by-side in a repeating pattern.
To help understand it, I strongly recommend downloading the save game file and playing with it. There are some part labels there, too, and you can replace the buttons with levers to let you watch it run in slow motion.
ok ive finnished my selector for my station and everythings going great ive got it hooked up to my tracks and its all going smoothly havent done too much to it in a while. thanks all to helping me make this. if you want a save file your gonna have to tell me how and where to upload it
Awesome, congratulations! I don't have immediate advise on where's free and easiest to upload files, since I use my own hosted server.
Here's a schematic of just the actual logic being performed:
[...]
It's worth mentioning that NOT OR and NOR are the exact same thing, I just broke one out into two symbols so I could label them more clearly below.
For the logic-diagram-impaired, here's a brief explanation of the purpose of each component and the overall function of the circuit. (I had to spend a few minutes working it out in my head myself, so don't feel bad! Logic diagrams can get dense, convoluted, and downright obfuscated at times.)
RS NOR latches (the boxes on the right):
Remember which button was most recently pressed. The R (Reset) input "turns it off" and the S (Set) input "turns it on". The Q output is on if the latch is in the Set or "on" state, and ~Q (Not Q) is on if the latch is in the Reset or "off" state. (I believe only Q is needed for this design.)
OR in lower left:
If ANY button at all is currently being pressed, this sends a signal. (That signal eventually gets split up and sent on toward every NOR latch, for use in clearing the previously stored destination.)
NOT after that OR:
After this, the signal is now on only if "no button is currently being pressed", and turns off while a button is pressed.
NOR gates attached to R lines of latches:
These are connected to the global "no button is being pressed" signal coming form the OR and NOT, as well as to the associated signal coming from each specific button. The purpose is to reset every latch EXCEPT the one which is in the process of being set by the button press, but when no button is being pressed, to leave all the latches alone. So, the only case in which a latch should be reset is when both "some button is being pressed" AND "this button is not being pressed". You can translate that fairly easy to understand statement into an equivalent but slightly less intuitive statement that represents the logic used in this circuit, which just happens to be easier to implement with redstone than the easier-to-understand statement.
Circuit function:
As long as the signal from the NOT remains on ("No button is pressed"), every NOR's output will be off ("Don't reset my latch"). This allows the current destination to be retained indefinitely.
When a button is pressed, the signal from the NOT turns off. However, the NOR associated with that button is now receiving a signal directly from the button instead, and so it remains off ("Don't reset my latch"). The button signal also reaches that latch's S input and Sets it. All the other NORs receive no signal, so they all turn on ("Reset my latch"), and if any of those latches were in the Set state due to prior button presses, they become Reset (Off).
Each latch has an output Q which is turned on when the latch is in the Set state, meaning that this is the currently selected destination. These signals can be used directly by routing each of them to a single track switch, which requires running a redstone wire and repeaters plus one switch for each destination.
Alternatively, all the inputs can be routed to an encoder circuit (not pictured or discussed in this thread, so far as I'm aware) which would convert the N destination signals into a binary code, requiring only Log2(N) wires, and a branching tree of N-1 (?) track switches. In other words, 2 wires would be needed for up to 4 destinations (2^2), 3 wires would be needed for up to 8 destinations (2^3), 4 wires for up to 16 destinations (2^4), and so on. However, redstone encoder (or decoder) circuits can, themselves, take up significant space, so it's a trade-off, and a matter of preference. But if your track switches are a significant distance from your destination buttons, the reduction in signal wiring could significantly outweigh the extra circuitry for the encoder.
Thanks for the great explanation! I'll see about tacking an encoder onto the back of the button array, since that really is a lot smarter way to do the tracks. the1laz does all kinda of cool redstone stuff. There's a link to that thread in the original post.
There's a link to that thread in the original post.
Ah, wups! Didn't see (and/or remember) that. :smile.gif:
Quote from zorac »
Thanks for the great explanation! I'll see about tacking an encoder onto the back of the button array, since that really is a lot smarter way to do the tracks.
You're welcome!
Speaking of encoders... I'd been working on an easily scalable decoder design a few weeks back, but was having trouble figuring out how to make it work the way I wanted. Today, after posting that, I looked up some resources regarding encoder/decoder logic, and hit upon an idea that made my design workable. I just now finished implementing it - and I think that the same basic layout could be easily reversed and, with (potentially minor) alterations at the formerly "input" end, become an encoder instead!
This N-bit decoder design packs the output signals 1-wide, similar to your button array. It has a height of 4*N, a width of 2^N, and thickness of 6. It works on the principle of bit-masking every output which should be turned off, resulting in a final output with only a single line unpowered. This serendipitously results in a single lit redstone torch at the top of the stack of masks. (Although I have extra torches stuck to the front face of each level for debugging and easier visibility of the output.)
The one I built is 3 bits to 8 outputs. The masks used are:
~A = I0 OR I1 OR I2
~B = ~I0 OR I1 OR I2
~C = I0 OR ~I1 OR I2
~D = ~I0 OR ~I1 OR I2
~E = I0 OR I1 OR ~I2
~F = ~I0 OR I1 OR ~I2
~G = I0 OR ~I1 OR ~I2
~H = ~I0 OR ~I1 OR ~I2
I had started building it on Zorac's save from this thread, so I'm checking with him before posting it.
Here's the compact underground design, schematic and save game file. It uses Raken's NOR logic and Angel_Mapper's indicator lights. It's 1x15x10 high underground, a 4x3 high panel above ground, and you can move the underground part as deep as you want with 4 high repeater sections.
Noice, thanks a bunch! I'm definitely using this in my Grand Central Station heheh.
Quote from Enos Shenk »
One thing I am curious about...Is that the same Angel_Mapper of UT2004 fame? DM-Reconstruct?
this may be a dumb question but after looking at the save file i cannot figure out where one would run the wire to the track
That's a perfectly reasonable question! You have a few options:
You can combine the signals with a demultiplexer the way that the1laz does in his remote controlled minecart station. But when you have one latch per destination already built using this design, that doesn't really save much if any space.
If you have 8 turns in sequence, each one turning the cart out to a new destination, then you can run each output signal to a turning point. I put together an example with the 8 outgoing tracks and one incoming track and here's what the junction looked like: (destination 4 is currently selected)
It turned out quite simple and the underground wiring just involves sending the output signal to a torch. Fairly space-efficient, as minecart track arrangements go.
I included a sample train station terminal. My choice of features was a little different. The way you use it is: get in the cart, then push the 'go' button. There's boosters and a little buried logic to make sure it only takes one button press. There's a pressure plate to make sure the cart never leaves without you. It doesn't include things like separate incoming/outgoing platforms or other rider detection tricks, and there's no cart storage.
But it's a perfectly functional sample train station with 8 destinations and a very small footprint! The whole thing can be hidden behind one wall of most of the train station designs out there.
The save game is available here. I haven't finished putting nice signs and glass viewports and ladders everywhere, but it's 100% functional.
Feel free to ignore the destination section. There's a pressure plate and button at each destination to send you home, but they all share the same booster, which resulted in a fun but unnecessarily complicated pattern of boosters.
The save game is available here. I haven't finished putting nice signs and glass viewports and ladders everywhere, but it's 100% functional.
Nice. Although I appear to have a very high chance of making the minecart rotate by 90 degrees when I try to get out of it. (Which usually results in later accidentally knocking it into the booster track and having it merge into a frankencart.)
The save game is available here. I haven't finished putting nice signs and glass viewports and ladders everywhere, but it's 100% functional.
Nice. Although I appear to have a very high chance of making the minecart rotate by 90 degrees when I try to get out of it. (Which usually results in later accidentally knocking it into the booster track and having it merge into a frankencart.)
Yeah, that's a consequence of the cart sitting on a pressure plate. I think it'd probably be better to just omit the pressure plate and rely on the button.
Okay, tagging this thread for later reference. I really want to get into minecarts sometime soon. Thanks for the great diagrams and detailed expanations everyone!
Hi, I am relatively new to minecraft and redstone wire, however I do understand the concepts of logic gates since I am an amateur programmer. I have built a fully functioning automatic minecart station and I tried to use your design for button selection (the redstone schematic in the first post) but I can't seem to get it to work and I can't see what I'm doing wrong. I have tried rebuilding it many times and I have wasted much time so I think I will resort to MCEditing it into my map. The only problem is I'm not very good with MCEdit so I can't select the area I want, but I can paste/import .schematic files. I was just wondering if anyone had (or could make) an MCEdit .schematic file for an 8 button version of the hidden underground inline display version (the one at the top of the first post).
Any help would be greatly appreciated,
Thanks in Advance!
Rollback Post to RevisionRollBack
Super Compact Frame quarry & tutorial <--- Server I play on (owned/maintained/played-on by the guy who created WorldEdit - sk89q); Visit skcraft.com for info. Vanilla Survival also available.
Hi, I am relatively new to minecraft and redstone wire, however I do understand the concepts of logic gates since I am an amateur programmer. I have built a fully functioning automatic minecart station and I tried to use your design for button selection (the redstone schematic in the first post) but I can't seem to get it to work and I can't see what I'm doing wrong.
...
Any help would be greatly appreciated,
Thanks in Advance!
If you can post the applicable part of your save game online somewhere, then we can look at it and check it out! I'm bad with MCEdit, too, but I'd be happy to look at a partially built system and try to diagnose it.
Following the schematic itself isn't too difficult but my question is where is it all wired to to make these switches in destination? Would it be turn junctions?
That.
This thread looks mighty useful, but I can't even figure out where you connect your minecarts to it, or what the diagrams mean. I think they are side views of two different layouts of redstone that don't interfere while doing the exact same thing. I don't know where the reset is for the RS NOR is though, need help on that too.
That's a reasonable question. Let's start by assuming you've read the redstone circuits wiki page and built most of the sample gates and latches described there. (If you haven't, then building this will be painful. ) Here's a schematic of just the actual logic being performed:
All of the logic there is implemented vertically except for the input to the OR (in this case, the OR is just a horizontal line of redstone) and the output of the NOT after the OR. (which is a torch powering a horizontal line of redstone.)
I've labeled the diagram from the original post with which torch or redstone corresponds to the logic schematic above. All other torches are either signal extenders, used to allow signals to cross, or carry signals vertically. (The alternating torches below the button just carry the signal down, for example.) The various parts are implemented a little differently on each of the two slices for space reasons.
It's worth mentioning that NOT OR and NOR are the exact same thing, I just broke one out into two symbols so I could label them more clearly below.
You're right, those are side views of two layouts to be built side-by-side in a repeating pattern.
To help understand it, I strongly recommend downloading the save game file and playing with it. There are some part labels there, too, and you can replace the buttons with levers to let you watch it run in slow motion.
Awesome, congratulations! I don't have immediate advise on where's free and easiest to upload files, since I use my own hosted server.
For the logic-diagram-impaired, here's a brief explanation of the purpose of each component and the overall function of the circuit. (I had to spend a few minutes working it out in my head myself, so don't feel bad! Logic diagrams can get dense, convoluted, and downright obfuscated at times.)
RS NOR latches (the boxes on the right):
Remember which button was most recently pressed. The R (Reset) input "turns it off" and the S (Set) input "turns it on". The Q output is on if the latch is in the Set or "on" state, and ~Q (Not Q) is on if the latch is in the Reset or "off" state. (I believe only Q is needed for this design.)
OR in lower left:
If ANY button at all is currently being pressed, this sends a signal. (That signal eventually gets split up and sent on toward every NOR latch, for use in clearing the previously stored destination.)
NOT after that OR:
After this, the signal is now on only if "no button is currently being pressed", and turns off while a button is pressed.
NOR gates attached to R lines of latches:
These are connected to the global "no button is being pressed" signal coming form the OR and NOT, as well as to the associated signal coming from each specific button. The purpose is to reset every latch EXCEPT the one which is in the process of being set by the button press, but when no button is being pressed, to leave all the latches alone. So, the only case in which a latch should be reset is when both "some button is being pressed" AND "this button is not being pressed". You can translate that fairly easy to understand statement into an equivalent but slightly less intuitive statement that represents the logic used in this circuit, which just happens to be easier to implement with redstone than the easier-to-understand statement.
Circuit function:
As long as the signal from the NOT remains on ("No button is pressed"), every NOR's output will be off ("Don't reset my latch"). This allows the current destination to be retained indefinitely.
When a button is pressed, the signal from the NOT turns off. However, the NOR associated with that button is now receiving a signal directly from the button instead, and so it remains off ("Don't reset my latch"). The button signal also reaches that latch's S input and Sets it. All the other NORs receive no signal, so they all turn on ("Reset my latch"), and if any of those latches were in the Set state due to prior button presses, they become Reset (Off).
Each latch has an output Q which is turned on when the latch is in the Set state, meaning that this is the currently selected destination. These signals can be used directly by routing each of them to a single track switch, which requires running a redstone wire and repeaters plus one switch for each destination.
Alternatively, all the inputs can be routed to an encoder circuit (not pictured or discussed in this thread, so far as I'm aware) which would convert the N destination signals into a binary code, requiring only Log2(N) wires, and a branching tree of N-1 (?) track switches. In other words, 2 wires would be needed for up to 4 destinations (2^2), 3 wires would be needed for up to 8 destinations (2^3), 4 wires for up to 16 destinations (2^4), and so on. However, redstone encoder (or decoder) circuits can, themselves, take up significant space, so it's a trade-off, and a matter of preference. But if your track switches are a significant distance from your destination buttons, the reduction in signal wiring could significantly outweigh the extra circuitry for the encoder.
PS: This thread has a good diagram of a branching track-switch setup and some other ingenious ideas: viewtopic.php?f=35&t=59987&p=1157029
Thanks for the great explanation! I'll see about tacking an encoder onto the back of the button array, since that really is a lot smarter way to do the tracks. the1laz does all kinda of cool redstone stuff. There's a link to that thread in the original post.
Ah, wups! Didn't see (and/or remember) that. :smile.gif:
You're welcome!
Speaking of encoders... I'd been working on an easily scalable decoder design a few weeks back, but was having trouble figuring out how to make it work the way I wanted. Today, after posting that, I looked up some resources regarding encoder/decoder logic, and hit upon an idea that made my design workable. I just now finished implementing it - and I think that the same basic layout could be easily reversed and, with (potentially minor) alterations at the formerly "input" end, become an encoder instead!
This N-bit decoder design packs the output signals 1-wide, similar to your button array. It has a height of 4*N, a width of 2^N, and thickness of 6. It works on the principle of bit-masking every output which should be turned off, resulting in a final output with only a single line unpowered. This serendipitously results in a single lit redstone torch at the top of the stack of masks. (Although I have extra torches stuck to the front face of each level for debugging and easier visibility of the output.)
The one I built is 3 bits to 8 outputs. The masks used are:
I had started building it on Zorac's save from this thread, so I'm checking with him before posting it.
on topic: That's just...epic. I wish I had some knowledge on circuitry, or at least had redstone... lol
They look good to me, and don't wait for my approval before posting anything. Saves are free to anyone. :smile.gif:
Awesome, congratulations!
Thanks!
Yep, that's me!
Just making sure - some people might not regard a modification of something they made in the same light!
Here's the encoder and decoder mentioned in my previous post.
http://www.filedropper.com/modifiedzora ... andencoder
I should MCedit the encoder onto a working copy of the button array, but meh. I'm lazy.
That's a perfectly reasonable question! You have a few options:
You can combine the signals with a demultiplexer the way that the1laz does in his remote controlled minecart station. But when you have one latch per destination already built using this design, that doesn't really save much if any space.
If you have 8 turns in sequence, each one turning the cart out to a new destination, then you can run each output signal to a turning point. I put together an example with the 8 outgoing tracks and one incoming track and here's what the junction looked like: (destination 4 is currently selected)
It turned out quite simple and the underground wiring just involves sending the output signal to a torch. Fairly space-efficient, as minecart track arrangements go.
I included a sample train station terminal. My choice of features was a little different. The way you use it is: get in the cart, then push the 'go' button. There's boosters and a little buried logic to make sure it only takes one button press. There's a pressure plate to make sure the cart never leaves without you. It doesn't include things like separate incoming/outgoing platforms or other rider detection tricks, and there's no cart storage.
But it's a perfectly functional sample train station with 8 destinations and a very small footprint! The whole thing can be hidden behind one wall of most of the train station designs out there.
The save game is available here. I haven't finished putting nice signs and glass viewports and ladders everywhere, but it's 100% functional.
Feel free to ignore the destination section. There's a pressure plate and button at each destination to send you home, but they all share the same booster, which resulted in a fun but unnecessarily complicated pattern of boosters.
Nice. Although I appear to have a very high chance of making the minecart rotate by 90 degrees when I try to get out of it. (Which usually results in later accidentally knocking it into the booster track and having it merge into a frankencart.)
Yeah, that's a consequence of the cart sitting on a pressure plate. I think it'd probably be better to just omit the pressure plate and rely on the button.
by c0yote
I tried it with terrible results. I gave my wife my glasses for a second, a creeper showed up and now my wife is pregnant.
Stupid 3D..
Any help would be greatly appreciated,
Thanks in Advance!
If you can post the applicable part of your save game online somewhere, then we can look at it and check it out! I'm bad with MCEdit, too, but I'd be happy to look at a partially built system and try to diagnose it.
Nice, Sgt_Blinky. Thanks!