13-floor detector-free elevator

[Harcion]

Now is finally the time to show my latest ridiculous project. I'll let everyone decide for him/her-self if it's ridiculously awesome or just plain ridiculous.

I never really built a Steve-elevator, just freight elevators, and I always thought it was weird that everyone used Detector blocks to stop at the right places. I figured that since you knew where you were going, you need not detect it, just time it right.

Well, turns out that "timing it right" is possible albeit tricky when you have multiple floors. See below for a video of my 13-floor detector-free elevator. Each floor is 5 metres high and you can go to any floor from any floor as well as call the elevator to any floor from any floor. (But no way am I building all of it in my legit world...)

Hopefully interesting and enlightening wall of text about the construction follows:

A pulley pulls or lowers rope at 1 m/s and if it has started moving one block it will not stop until that block is done. The idea is thus - to move the elevator j blocks you would release the brakes for just a little more than j - 1 seconds.

For this purpose I set up a basic circuit consisting of one n-counter attached to one n-pulser. When giving it a pulse, the pulse will move n times through the n-pulser, each time triggering the n-counter which outputs a pulse at the last one. By modifying the delay in the feedback loop of the n-pulser and the value of n you can get pretty much any delay you desire. There are some glitches with this approach that I have not managed to understand yet, (like having the output connected to a 2-repeater will not trigger the next unit, but a 1-, 3- or 4-repeater will...) but when it works it works all the time.

Then I put these units, let's call them m-timers, into series, so that a 1-timer was followed by a 2-timer, then a 4-timer and lastly an 8-timer. If the 1-timer delays long enough for 1 level, the 2-timer should delay enough for 2 level and so on. Adding some switches so that the signal can either go through a given m-timer or pass it by then results in a circuit that can delay anything between 1 and 15 levels. Some care has to be taken with the delays in the "pass-by" line, since this can mess things up. Took me quite a while to get it right. :)

My initial idea was then to hook up the buttons on each floor in different ways so that they triggered the right combination of switches. Say, on floor 4 the button to floor 7 would turn on the 1-timer and the 2-timer since I wanted to go 3 floors up.

This would work pretty well until I realised that if the elevator was at another floor than Steve I had no way of calling it there.

Enter the memory unit. I set up a fairly traditional piston ring, except I added another set of pistons so that it can move both clockwise and counterclockwise. The single conductive block remembers which level the elevator is at. It has the positions -12, -11, -10, ..., -1, 0, 1, ..., 10, 11, 12..

Let's say the elevator is at level n, and Steve wants it to go to level k. He pushes the k button which sends the binary representation for k up to a sequence of units similar to the m-timers except that they all have the same delay and are just used for counting. These subtract k from the memory unit leaving it at n-k. Now we know how far to go, namely |n-k|. If n-k is negative we go up and if it is positive we go down. This information is sent to the switches for the m-timers which move the elevator.

The information is also sent to yet another series of counter units which add or subtract |n-k| to the memory unit, leaving it at position 0. Then the first set of counter units add k, leaving the memory in the correct position. Then all latches controlling the input to the counter units and the m-timers are reset and the elevator is ready to move again.

After all the issues I had with this design, this time I really do *not* want to know if there is a better and much easier way of doing it. :) The wiring mess around the memory unit could probably have been lessened if I had read up on hexadecimal-binary converters first, and I should have placed stuff in different positions knowing what I know now - I had to run redstone lines from one side to the other several times.
Could also have covered up the elevator shaft better, but I had originally planned to have a enclosed 2x2x2-cabin only open in one direction. Unfortunately, there is still some issue with the platforms that caused it to keep sliding apart so I just turned it into this.

The number of floors, 13 and not 16, is not because of pistons this time, but timing issues. It seems as if lowering or raising things with the pulley is somewhat different. When I tried going 13 floors, I would keep overshooting by one block when going up but ending up fine when going down. Decreasing the delay by one tick meant that I did not reach the end by one block when going down, while going up was fine. I'm not going to file a bug report on this since I'd like FlowerChild to work on more important stuff and this is kind of an extremely minor issue. I'm surprised it works as well as it does. :)

I'll add some pictures if someone is interested in more than what can be seen in the video, but not until later this evening.

Movie:

[Damion Rayne]

Ok that's cool, but an awful lot of work and crap for multi-floor elevator, lol

[Harcion]

Ok that's cool, but an awful lot of work and crap for multi-floor elevator, lol

I hear you. :) It turned into something of a wiring nightmare after a while. I think I know now how the people in the punchcard era of computing felt about debugging. Just one misplaced redstone wire resulted in an extremely random and annoying problem that took forever to locate.

However, if you do not require the "call elevator here" functionality, you can cut away the whole memory unit thing and just keep the m-timers. This drastically reduces the complexity and size. (And likewise decreases the response time.)

[Thieme]

wow nothing but respect for you doing this in vanilla redstone i think i would go completely nuts like 5 times at least before i would be able to build that ^^

[BinoAl]

Suddenly, stairs seem like a great option :)

[walker_boh_65]

just absolutely amazing, brilliant!

[M!C]

Wow, that's an impressive sight! I think I'm going to steal that timer idea of yours ... if I'm not to lazy to do it. At least I got myself the Redpower mods so I don't need as much wiring ...

[Harcion]

Thanks for the praise people, makes me feel that it's a little less ridiculous. :) Agree fully on the stairs, I've climbed more ladders when building this than ever before since it's way more practical though less cool.

I think I'm going to steal that timer idea of yours

If you do, remember that the pulse travels m-1 times (and not m) through the feedback loop before the last BD sends the output pulse. Hence, with just one conductive block the pulse bypasses the feedback loop altogether.

Also, the delay from the pulse reaching a BD and exiting the block placed in front is 2 ticks. That might be obvious, but tested it to be sure.

Actually, before I forget I have to mention something I found while testing that:

Consider this circuit, seen from the top,

XRRRRRP
XRAAAAO
YRAAAAA
YRRRRRP

where R is redstone, A is air, P is a sticky piston and O is some pushable block. X and Y are just markers.

If you send a pulse from one of the X positions, the block O will end up at the "top" piston and if you send a pulse from a Y position it will end up
in front of the "bottom" piston. The pulse reaches one of the pistons before the other, even though they are connected to the same redstone line with no repeaters or other delays on it.
This indicates that there are actually sub-tick timings when working with redstone - it matters (somewhat) how long the lines are.

I've yet to think of a practical application for this discovery but I'm sure there is something.

Is this a widely known fact and I've just missed it?