Only While You Hold It: The Lift

What you are building 3 min

The Lift: a tower with a car on a string, a Large Motor to wind it, and two Touch Sensors — one to send it up and one to bring it down.

There is a problem built into this machine, and it is worth seeing before you write anything. Nothing tells the robot where the top is. There is no sensor up there. If the motor keeps winding after the car reaches the roof, the string snaps or the tower comes apart.

Every model so far solved this by counting — so many rotations, so many degrees. Today you solve it a completely different way: the machine runs only while somebody is holding the button down, and the person watching becomes the part that knows when to stop.

In the real world 5 min

Where you have seen it

Every tall building in KL has lifts, and every one of them has a panel of buttons. You press a floor and let go, and the lift takes itself there.

Why it is built that way

A passenger lift can work like that because it knows where it is. There are sensors at every floor and switches at the very top and bottom of the shaft, so the lift can take a single press and be trusted to stop in the right place.

Now look at a construction hoist on a building site — or a drill press, or the platform lift on a lorry. Those often have a different kind of control: a button or lever that works only while it is held. Let go and the machine stops instantly.

Engineers call it a hold-to-run control, and they use it wherever the machine cannot be trusted to judge for itself.

What would go wrong without it

Your lift has no floor sensors and no limit switch. Give it a press-once-and-go button and the very first mistake is a broken model: the car reaches the top, the motor keeps winding, and something gives.

If a machine cannot tell when to stop, do not build it a button that lets it run unwatched.

The main concept — hold-to-run 6 min

A trigger and a hold-to-run control use the same sensor and look almost the same in a program. They are completely different machines.

[1 v] wait until [bumped v] :: sensors

[1 v] wait until [pressed v] :: sensors

[1 v] wait until [released v] :: sensors

The whole pattern is four blocks, and the order is the idea: wait for the press, start the motor, wait for the release, stop it. Notice that the motor block in the middle is start motor — the one with no ending built in, from Lesson 4 — because the ending is going to come from the person, not from a number.

That is the deep point. Every other model in this course has had its ending written into the program. This one has its ending held in somebody’s hand.

Bumped means “go and keep going”. Pressed-then-released means “go for exactly as long as I say”.

▶The Touch Sensor, and the Large MotorThe full reference for pressed, released and bumped, and for the motor doing the lifting. Open either if it is not clear yet.Show meHide

ComponentSensing5 min

The Touch Sensor

The Touch Sensor is the simplest input the EV3 has: a button that is either pressed or not. That sounds trivial, but it is how a robot knows it has hit a wall, reached the end of a track, or been told to start by a person.

released

pressed

Blocks reference

Block	What it does
wait until <[1 v] is pressed? :: sensors>	Holds the program here until somebody presses the sensor.
<[1 v] is pressed? :: sensors>	Reports true or false. Drop it into a condition to make a decision rather than a wait.
[1 v] when [bumped v] :: events hat	Starts a whole stack of its own. The dropdown chooses the moment: pressed, released or bumped.

Three different events

A button is not only “pressed”. One press is three things: the moment it goes down, the time it stays down, and the moment it comes back up. Watch what a single press does to three programs at once.

when program starts

forever

  if 1 is pressed? then

    change count by 1

versus two hat blocks

1 when pressed

1 when bumped

0is pressed? in a loop0when pressed0when bumped

In a loop: 0 answers from one pressBumped: exactly one

Nobody is touching the sensor. All three programs are watching it.A finger presses the button. Watch the red button go in — a couple of millimetres is the sensor's entire movement.The finger is still down. The loop checking «is pressed?» has already run hundreds of times, and every one of them counted.The finger lifts. Only now does «bumped» count, because bumped means pressed AND released.One press. Three completely different answers.Finished. The same press, counted three ways.

▶ Play⏭ Step↺ Restartreleased

The middle counter is the one that surprises people. Nothing is wrong with it — a loop really does check that fast, and every check really is a separate answer.

Nothing there is broken. A loop really does get round hundreds of times a second, and each time it asks is pressed? the honest answer is still yes — so if that loop plays a sound or counts something, it does it hundreds of times from one finger. The two hat blocks each fire once, and they fire at different moments: pressed the instant the button goes down, bumped only when it comes back up.

The three options, and what each is for:

• Pressed — the button is down right now. Good for “hold to run”.
• Released — it is up again. Good for acting when somebody lets go.
• Bumped — pressed and released. This is what you want for “click to start”, because it will not fire repeatedly while a finger stays down.

The classic bumper

when program starts :: events hat
set movement motors to [B v] and [C v] :: movement
start moving [straight: 0] :: movement
wait until <[1 v] is pressed? :: sensors>
stop moving :: movement

The robot drives until something presses the sensor. Note that the movement is started unmeasured on purpose — the sensor decides when to stop, not a distance.

Why it matters

Touch sensors are everywhere in machines you cannot see into: a lift knows the doors are shut, a printer knows the lid is closed, a washing machine will not spin until it is latched. They are safety devices as much as inputs.

ComponentMotion4 min

The Large Motor

The Large Motor is the bigger of the two EV3 motors. It turns more slowly than the Medium Motor but pushes far harder, which is why it drives wheels and lifts loads. If a mechanism struggles or stalls with a Medium Motor, this is usually the answer.

Large Motor

Medium Motor

Blocks reference

Block	What it does
[B v] run [clockwise v] for (3) [rotations v] :: motors	Turns the motor a measured amount, then stops.
[B v] run [clockwise v] for (2) [seconds v] :: motors	Turns it for a length of time rather than a distance, then stops — however far the shaft actually got.
[B v] set speed to (40) % :: motors	Sets how fast the next movement will be.
[B v] start motor [clockwise v] :: motors	Starts it turning and carries straight on.

Watch them race, then watch them lift

Give both motors the same program and the same arm. With nothing on the arm the Medium Motor wins easily — which is why it is tempting to treat it as simply the better motor. Then the demo hangs a weight on both arms and runs it again.

when program starts

A run clockwise for 1 rotations

and on the Large Motor, only the port changes

B run clockwise for 1 rotations

0%medium lifted0%large liftednoneload

Medium: not enough forceLarge: slower, but it lifts

) : clock.step === 1 ? (

With nothing to lift, the Medium Motor is quicker

The same program, the same arm, one on each motor. Nothing to lift yet.No load: the Medium Motor is clearly the quicker of the two.Now hang a heavy weight on both arms and run exactly the same program.The Medium Motor stalls a third of the way up. The Large Motor keeps lifting.Same program, same weight — the motor was the difference.Finished — it will run again in a moment.

▶ Play⏭ Step↺ Restartat rest

Turning the speed up would not rescue the Medium Motor here — a stalled motor needs more force, which means gearing it down or using the Large Motor.

That is the whole difference. The Medium Motor is quicker; the Large Motor is stronger. A motor that cannot produce enough force does not move slowly — it stops altogether and strains, which is the buzzing, going-nowhere failure almost every LEGO builder meets sooner or later.

A stalled Large Motor hangs the program too

Being stronger buys the Large Motor a bigger load, not an infinite one. Every winch runs out of cable and every lift reaches the top of its rails, and when a motor arrives at a limit it stalls: the shaft stops turning and the motor sits there straining.

That is a problem for the program, not just the mechanism. run for (3) rotations does not finish when three rotations’ worth of time has gone by — it finishes when the shaft has actually turned three times. A winch that reaches the top after two and a half will never report three, so the block waits, and every block after it is unreachable. Nothing crashes. The motor keeps pushing and the rest of the program simply never happens.

The third setting in that dropdown is the way out. for () seconds drives the motor for a duration and then stops regardless, so it always finishes and the program always moves on. Drive into a limit slowly, for a comfortably long time, and then call that position zero:

when program starts :: events hat
[B v] set speed to (30) % :: motors
[B v] run [counterclockwise v] for (3) [seconds v] :: motors
[B v] reset degrees counted :: motors

The lift ends up against its own stop, the encoder is zeroed there, and every measured move afterwards starts from a place you know. The rule is the same for both motors: if the movement ends against something solid, run for seconds; if it ends somewhere in the middle, measure it. The Medium Motor module has the animation for it — see The Medium Motor, which is where this bites hardest, because a Medium Motor is usually the one doing the lifting.

Which motor for which job

• Large Motor — wheels, winches, anything lifting weight. Strong, slower. Normally ports B and C.
• Medium Motor — arms, gates, jaws, pointers. Quick, lighter. Normally ports A and D.

The blocks are identical apart from the port letter, so swapping one motor for the other is a build change, not a programming change.

Why it matters

Real machines match the motor to the load. A lift uses a powerful, slow motor; the button panel beside it uses tiny ones. Choosing the wrong size is the most common reason a LEGO mechanism whines but does not move.

Say this back before moving on: “It runs while the button is down and stops when I let go.”

What’s in this build 4 min

Find the top and the bottom by hand

Brick off. You are finding the limits that the machine has no way of knowing.

1. Wind the car all the way up by hand until it is just below the top pulley. Stop there. That is the highest it may ever go.
2. Lower it all the way down to the base. That is the bottom, and note that the string should still have a turn or two on the axle — never let it unwind completely.
3. Check the string winds neatly onto the axle rather than piling up on itself.
4. Label the two sensor cables 1 and 2 with tape before you plug them in, exactly as you did on the Machine Gun.

Nothing in the program knows about either limit. You found them, you remember them, and today your finger is what respects them.

Ports — and the rule 4 min

Sensors go in ports 1, 2, 3, 4. Motors go in ports A, B, C, D. They are not interchangeable, and nothing will tell you politely if you swap them.

Check your own build now:

1. Motor in A; the sensor you labelled 1 in port 1 and 2 in port 2.
2. Mount the buttons where you can see the lift car while you press them. This is not a convenience today — the whole safety of the machine is that the person pressing can see when to stop.
3. Start with the car at the bottom before every run.
4. Nothing on the table under the car.

Connect the Brick 4 min

Two routes, and either is fine. USB is the reliable one and the one to fall back on when a room’s Bluetooth is busy; Bluetooth leaves the robot free to move, which some models need.

▶How to connect the BrickUSB and Bluetooth, step by step, with a photograph of every screen. Open it if you have not done this before — or if pairing is not working.Show meHide

USB — the reliable one

1. Switch the Brick on with the dark grey centre button.
2. Cable into the Brick’s PC port — the small square socket beside the numbered ports, not one of the numbered ones.
3. Other end into the computer.

Bluetooth — name it first

Do these in order. Naming the Brick after you go looking for it in the list is how groups end up driving each other’s robots.

1. Name your Brick. On the Brick: Settings (the spanner) → Brick Name. Type something nobody else will pick, then press the tick. Every Brick is called EV3 until somebody changes it.
2. Turn Bluetooth on. Settings → Bluetooth. Tick Bluetooth and Visibility. Leave iPhone/iPad/iPod unticked.
3. Connect from EV3 Classroom. Click the Brick icon at the top of the programming area, find your Brick by name, and click Connect.
4. Say yes on the Brick. It asks “Connect?” with the computer’s name — choose the tick, then accept the passkey, which is already 1234.

⤢ Tap to enlarge

⤢ Tap to enlarge

⤢ Tap to enlarge

⤢ Tap to enlarge

⤢ Tap to enlarge

The two failures, every class, every time. The Brick has gone to sleep while you were building — press the centre button to wake it. Or you have paired with the group at the next table, which is why the name matters.

The long version, including Port View and how to read the port tiles, is in the Brick & Bluetooth guide.

Keep every cable clear of the string and the car. A cable that catches the car mid-lift will stop it, and the motor will keep winding — which is exactly the failure this lesson exists to prevent.

Confirm the connection 2 min

1. Check the Brick icon: connected, or not.
2. A Large Motor on A, and a Touch Sensor on both 1 and 2.
3. Press the UP button and check tile 1 changes. Then DOWN, and tile 2. Swapped cables here means up sends it down.
4. Turn the motor by hand and check the car really does go up when the drum turns clockwise. If it goes down, your program’s directions need swapping — or rewind the string the other way round the axle.

Make it move 10 min

Seven blocks, and the whole hold-to-run pattern is the four inside the loop. This program only does up — down is yours to add in the next section.

when program starts :: events hat
[A v] set speed to (30) % :: motors
forever
  [1 v] wait until [pressed v] :: sensors
  [A v] start motor [clockwise v] :: motors
  [1 v] wait until [released v] :: sensors
  [A v] stop motor :: motors
end

Walk it in the order the Brick runs it:

1. set speed to 30 % — a setting. Slow, because you need time to react when the car nears the top.
2. forever — a lift is never finished.
3. wait until pressed — nothing happens at all until a finger goes down.
4. start motor clockwise — the car rises. No ending is built in, so it will keep going.
5. wait until released — the program sits here while the car climbs. This block is the whole safety system.
6. stop motor — the instant the finger lifts.

What success looks like: the car goes up smoothly while you hold, stops immediately when you let go, and stays where it is. Try stopping it exactly halfway. Then exactly two-thirds of the way. You can put it anywhere, which no measured program has let you do all course.

Do not test what happens at the top. Let go well before the car reaches the pulley. You already know what would happen, and knowing is enough.

Change it and test 8 min

One change at a time, and predict before each run. Always keep a finger ready to let go.

1. Add the down button. Inside the same loop, after the four blocks you have, add the same four again for port 2 with counterclockwise. Now the lift goes both ways.
2. Try pressing both buttons at once. Predict first. The program is only ever waiting for one of them, so the other is simply ignored until its turn comes round — which is a real limitation and worth seeing.
3. Set the speed to 80 %. Try to stop the car exactly halfway now. Much harder — a fast machine gives a person less time to be the safety system.
4. Back to 30 %. Now replace wait until released with wait (2) seconds. Predict what changes. The lift now runs for two seconds whatever you do, and letting go does nothing at all — you have just turned a hold-to-run control back into a trigger.
5. Put it back and say out loud which of the two versions you would trust on a machine with no sensor at the top.

Step 4 is the comparison the whole lesson is for. Both programs use the same sensor and the same motor. One stops when the person says so; the other stops when a number says so — and only one of those two knows where the top of the tower is.

When the machine cannot know, keep the person in the loop. That is a design decision, not a shortcut.