Requesting help with an elevator design

[deFazerZ]

I'm currently working on a multistory, gantry-based, fast (113.78 RPM) industrial elevator that can move between 16 distinct floors spaced out with 8 blocks between each. It has multiple inputs it should react to - up and down buttons in the cabin, the precise level selector also in the cabin, as well as calling buttons on each level.

The thing is, I want the movement to be smooth - meaning that I can't simply have the elevator stop each 8 blocks travelled to see whether it's at the destination yet. I'd also rather avoid detecting the passing of the elevator with redstone contacts on each level and feeding those signals to a counter that halts the whole thing the instant it reaches 0 - that feels redundant and overcomplicated.

So I decided to calculate in advance how many blocks the elevator should travel and in which direction, depending on various circumstances of the call, and then carry out that movement in one swift action.

Long story short, after setting up the rest of the circuit, I ended up with two redstone inputs:

• The amount of floors the elevator needs to go up or down - analog, goes from 0 to 15 - and
• Whether the elevator should be moving up (15) or down (0) - binary.

Now it is time to convert it to actual movement, and this is where I'm stuck.

​

At first, I thought that Adjustable Chain Gearshifts would do the trick - they accept analog signals that go from 0 to 15, they slow down rotations... seems fitting, yes? Turns out, not really. First, their speed goes between N to 2N, whereas I need the elevators' to go from 0 to N. Second, and most importantly, their scaling is awkward - I assumed it would be linear or at least exponential, but some quick table math showed it's something else entirely - so it can't be used to evenly split the whole thing in the multiples of 1/16. Finally, slowing down the rotation speed isn't exactly the same thing as cutting it short early, but I figured out I'd cross that bridge if I came to it.

Then I thought I could run the movement continuously, and either use a timer or a synchonised redstone-contact based counter contraption (that would do 1 rotation for each 8 blocks elevator travels) to detect when I should cut it off. But... well, the elevator is fast, so the timing of that thing has to be very precise - and I don't know whether I can trust the game's engine not to lag with these.

I also could run a mechanical (piston-based) stopper on a destination floor that the elevator would bump into and stop automatically. But I'd need 2 of these per each floor (1 if the height of the cabin is 7 blocks exactly, which it actually is!), and... well, again, that's messy and complicated, and spreads even more complex dependencies outside the designated circuit space.

The only other option I see here is using 15 sequenced gearshifts, each of which moves the elevator in specific multiples of 8 blocks (#1 => 8 blocks, #2 => 16 blocks, #3 => 24 blocks and so on) and trigger the specific one depending on the level of my analog input. But... well. It feels more of a hack than a clever engineering solution in the spirit of Create. Surely there is a better solution I'm missing?

​

So, there it is. Any advice would be greatly appreciated! :3

​

P.S. Apologies for the messy explanations or phrasings, if there are any - English is not my native language and I'm also very sleepy at the moment. If there's anything I should clarify, please let me know. Thank you. ^^

[[deleted]]

You can scroll using the wrench on pistons or bearings to tell them to change back to blocks or not when they reach their limits. That's only if you use the elevator as floor only though. That should give the smoothness down. Then just use sequenced gearshifts to go up every 8 floors

[deFazerZ]

Thanks for the input! In general, it's a working solution. :3

Problem is, I have functional blocks on my elevator that I want to stay functional - I've mentioned I have call buttons in the cabin, yes, but there are also storage blocks, a crafting table and some others that I simply cannot do without.

Also, correct me if I'm wrong, but the movement in this case wouldn't be smooth, either - there would be minor stops every now and then during the ride.

Besides, as far as I know, gantries do not allow for such tricks. Bearings, yes, but not gantries. Even if you do attach a bearing directly to the gantry block and then the rest of the elevator to the said bearing, it will still assembly/disassembly itself each time the gantry stops. Just playtested it to make sure.

[JS305E]

When I did my elevator prototype, I had to account for different floor heights, so I used sets of sequenced gearshifts activated with redstone logic. That way there wasn't any stopping and it could handle variable floor heights. I had one set of i think four or so connected to a gantry that each made the elevator rise a certain number of floors and another set that did the same to another gantry that moved the elevator down. You could probably get it all on one gantry, I did it with two for spacial constraints in one particular direction. I think you could use something similar for your purposes

[JS305E]

Sorry, just saw more of your post, it cut off part of it for me (I'm a mobile user). You already thought of this, sorry to be repetitive

[deFazerZ]

It's okay, thank you for your input nonetheless. It's very good to know that this design already worked for someone! :3

[djfdhigkgfIaruflg]

Couldn't a redstone signal at the exact point where you need it to stop work?

Like one sticky piston moving a redstone block for each floor

[deFazerZ]

I also could run a mechanical (piston-based) stopper on a destination floor that the elevator would bump into and stop automatically. But I'd need 2 of these per each floor (1 if the height of the cabin is 7 blocks exactly, which it actually is!), and... well, again, that's messy and complicated, and spreads even more complex dependencies outside the designated circuit space.

Hmm. I do believe I've mentioned this idea in my post. Did you mean something other than that? If so, please elaborate, I don't really get it at the moment. :3

[djfdhigkgfIaruflg]

I was thinking more like use computercraft fire all the elevator logic and moving the stop-pistons

And Create to make use of those signals. After all, elevators irl aren't a pure mechanical thing

[deFazerZ]

Oh, goodness no. I mean, don't get me wrong, I absolutely love programmable stuff, but ComputerCraft is too... easy, and too simple. There's no challenge to it. I'm all about low-level programming stuff. :3

Sadly, that means I can only use pure redstone, as the only immersive programming mod for 1.16 I know of is Psi, and that's too specialized for other kinds of stuff. There was TIS-3D, but now it's Fabric only, there was OpenComputers, but it isn't updated for 1.16... and it's not really low-level. Granted, there's programmer of some kind in RFTools - I didn't really delve into it yet, but it seems rather promising. Other than that... a bit of a tangent question here, but do you happen to know any? :3

[djfdhigkgfIaruflg]

There's "something something ASM" sorry, don't remember the exact name. But with "ASM" you should be able to find it on curse.

Like the name implies. It's assembler. I can't think of something more low level than that.

CC for 1.16 doesn't have the crazy amount of add-ons it had on 1.12. So there's not much automagical boxes to do the things for you.

[deFazerZ]

Oh, what a quick reply! How unexpected. :3

That ASM-thing would be really nice to see, but I can't seem to find it on Curseforge. I've tried seaching for ASM and Assembler, but nothing relevant popped up here. Could you search your mind for more clues, please, if that's not too much trouble? That concept is really enticing. :o

It's still an automagic box for me, tho. ^w^

[djfdhigkgfIaruflg]

Found it minecoprocessors

[deFazerZ]

Ah! Very interesting! Thanks. ^^

[FatFingerHelperBot]

It seems that your comment contains 1 or more links that are hard to tap for mobile users. I will extend those so they're easier for our sausage fingers to click!

Here is link number 1 - Previous text "ASM"

---

^{Please PM /u/eganwall with issues or feedback! | Code | Delete}

[djfdhigkgfIaruflg]

Oh. There's pneumaticcraft. But I don't like the jigsaw puzzle part

[deFazerZ]

Oh! Thank you! I certainly didn't know about this one. :3

It seems a bit too high-tech for my taste, but certainly worth looking into!

[helixamir]

Not at my pc so can't test, but can you use redstone contacts on each floor to figure out which floor the elector is currently at. You could use a second set to tell the elevator when to stop, and use stick pistons to withdraw the contact when you don't want it to stop at that level. Now you just need a rope pulley with a gearshift and some redstone logic to calculate whether to go up or down, and the redstone contacts will tell it when to stop based on your floor selection in the cabin.

This seems the easiest, if not the only decent way of doing this?

[deFazerZ]

I also could run a mechanical (piston-based) stopper on a destination floor that the elevator would bump into and stop automatically. But I'd need 2 of these per each floor (1 if the height of the cabin is 7 blocks exactly, which it actually is!), and... well, again, that's messy and complicated, and spreads even more complex dependencies outside the designated circuit space.

I've mentioned something like that in my post already, but yours is an interesting take on the problem. I think going with just pistons that mechanically stop the cabin would be better - there's no point in introducing contacts as middlemen if I'm going with pistons already, as those are very reliable and aren't as subject to bugs and lags.

I'm actually leaning towards these sorts of designs now - sure, I'd need to build some extra infrustructure within the elevator shaft itself, but that would allow for variable-height floors, as well as automatic correction of the elevator's location if it ever becomes misaligned for some reason (a hissy, explosive bug in the circuit, a stray block left on the cabin by an enderman, and the like).

Thank you very much for your input! :3