Challenge 1
Show all four faces in one performance, ending on the face you started with. Every change must be completely hidden — judged from the audience seat, not from above. If anybody watching can see a card turn, it does not count.
What you are building 3 min
The Speed Face Change: four painted faces on a turntable, and a white screen that drops in front of them. The screen comes down, the faces turn, the screen goes up — and the audience sees a completely different face with no idea how.
It is a magic trick built out of two motors, and it only works if they take turns.
The last several models all needed their two motors moving in perfect step: the Frog, the Toddle Bot, the Push-up Robot, the cars. This one is the opposite. If both motors move at once here, the audience watches the face rotate and the trick is over.
In the real world 5 min
Where you have seen it
Bian lian — face-changing — is a three-hundred-year-old Sichuan opera art. A performer sweeps a fan or a sleeve across their face and the painted mask changes colour instantly, again and again, faster than the eye can follow.
Why it is built that way
The secret is layered silk masks with threads the performer pulls. But the method is what matters to you today, and it is this: the change is always hidden behind something. A fan, a sleeve, a turn of the head. Never in the open.
The skill is not in changing the mask quickly. It is in making absolutely certain that the cover is in place before the change starts, and stays there until it has finished. Real performers guard the method so closely that in China it is officially a protected national secret.
What would go wrong without it
Get the timing even slightly wrong and there is no trick. The audience simply watches you change a mask, which is not magic — it is somebody fiddling with their face.
And the failure is total rather than partial. A trick performed 90 % in secret is a trick that has been given away.
Cover first. Change second. Uncover third. Every order except that one is a spoiled trick.
The main concept — two motors, taking turns 6 min
Two motors doing two different jobs, and the order between them is the machine.
You already know how to make a program do one thing after another — blocks run down the page, top to bottom. What is new is that this is now the point rather than an accident. Lessons 24 to 29 fought hard to get two motors moving at the same instant. Here you want the opposite, and the plain stack of blocks gives it to you for free.
| Kind of job | How to write it |
|---|---|
| Two motors doing one job (legs, wheels, arms) | A move block on a pair. Both at once, in step. |
| Two motors doing two jobs (screen, turntable) | Separate run blocks, one after the other. Each waits for the last to finish. |
And notice why the ordinary stack works here. A run for (90) degrees block waits until it has finished — the same property that made the Push-up Robot hang in Lesson 27. Here it is exactly what you want: the screen is guaranteed to be all the way down before the next block starts turning the faces.
Blocks in a stack take turns automatically. When two motors must not overlap, that is not a limitation — it is the tool.
The Medium Motor and the Large MotorThe full reference for both motors. Open it if the difference between them is not clear yet.Show meHide
The Medium Motor
The Medium Motor is the smaller of the two EV3 motors. It is quick and light rather than strong, which makes it the right choice for anything that has to move a part of the robot rather than the whole robot — a gate arm, a pair of jaws, a winch, a pointer.
side
from aboveBlocks reference
| Block | What it does |
|---|---|
[A v] run [clockwise v] for (1) [rotations v] :: motors | Turns the motor a measured amount, then stops. One rotation is one full turn of the motor shaft. |
[A v] run [clockwise v] for (90) [degrees v] :: motors | The same idea, but in degrees — useful when a quarter or a half turn is what the mechanism needs. 360 degrees is one rotation. |
[A v] run [clockwise v] for (2) [seconds v] :: motors | Turns the motor for a length of time and then stops, whatever the shaft managed to do in it. The one measurement that always finishes. |
[A v] set speed to (50) % :: motors | Sets how fast the motor will run from now on. It does not start the motor by itself. |
[A v] start motor [clockwise v] :: motors | Starts the motor turning and moves straight on to the next block. It keeps going until something stops it. |
[A v] stop motor :: motors | Stops the motor. |
Measured, or not measured
These two look similar and behave completely differently, and almost every early EV3 bug comes from picking the wrong one. Watch both run the same job, over and over.
when program starts
A run clockwise for 1 rotations
versus
A start motor clockwise
wait 1 seconds
A stop motor
0°measured0°timed1run
Measured: on the mark, againTimed: 48° off the mark
Both programs begin. Both shafts are on the black target mark.
Let it loop a few times. The left dial keeps landing on the same mark; the right one leaves a new mark almost every run — that scatter is what “not repeatable” means.
The black mark is where the shaft should finish. The measured motor hits it every single run, because the program waits at that block until the motor has turned exactly that far. The timed motor is only running for a second — and a second covers a different amount depending on the battery, the friction and whatever the mechanism is carrying. Each orange dash is a run that finished somewhere it was not asked to.
- run for () rotations is measured. Run it twice and you get the same movement twice.
- start motor is not measured. It hands the motor its instruction and moves straight on, so how far the motor gets depends on how long it happens to be left running.
If a mechanism has to end up in a particular place — a gate that must finish upright, a jaw that must close fully — use the measured block.
The third one: run for () seconds
The dropdown at the end of the run block has a third setting, and it is the one that saves lifting mechanisms. for () seconds switches the block off a distance and onto a duration: it drives the motor for that long and then stops, whatever the shaft managed to do in the time.
That sounds strictly worse than a measured turn, and for most jobs it is. It matters because of what the measured block actually waits for. run for (90) degrees does not finish when 90 degrees’ worth of time has passed. It finishes when the shaft has turned 90 degrees — and if the mechanism runs out of travel first, the shaft never will.
Stalling, and the program that never moves on
Every arm, jaw and lift has a physical limit: a point where the mechanism reaches the top of its travel, or something in the build gets in the way. Push a motor into that limit and it stalls — the shaft stops turning and the motor sits there straining. The motor is fine and the program is spelled correctly. But the encoder has stopped counting, so a measured block that was told a bigger number is still waiting, and it will wait until the Brick is switched off.
Nothing after that block ever runs. Not the next motor block, not the sound, not the display, not the rest of the program. That is the whole failure, and it looks like a crash even though nothing has crashed.
when program starts :: events hat [A v] set speed to (30) % :: motors [A v] run [clockwise v] for (90) [degrees v] :: motors [A v] reset degrees counted :: motors write [HOME SET] at line (1) :: display
0°degrees counted90°what the block asked for0.0swaiting at that block
60° reached, 90° asked — waits for everrest of the program never runs
Same arm, same end stop at 60°. One number is different: this program asks for 90.
Watch the Brick screen, not the arm. HOME SET is the block after the motor block, so a blank screen means the program never got past it.
Compare the first two. The only difference between them is 45 and 90, the mechanism is identical, and one of them is a working program while the other locks up on the third block. Nothing in the listing distinguishes them — the end stop is a fact about the build, and the program has never heard of it.
This is the mistake almost every student makes the first time a Medium Motor lifts something. A lifting arm has a lowest position and a highest one; ask it to turn past either and the program hangs. It is worse than an ordinary bug, because the robot looks alive — the motor is still being driven, still buzzing, still hot — and the next block never comes.
Finding a home position by stalling on purpose
The fix turns the problem into the technique. You often do not know how many degrees it is to the top of an arm’s travel — it depends on the build, and it changes the moment somebody rebuilds it. So do not measure it. Drive the arm gently into its own end stop for a couple of seconds, and then declare that position to be zero:
when program starts :: events hat [A v] set speed to (30) % :: motors [A v] run [counterclockwise v] for (2) [seconds v] :: motors [A v] reset degrees counted :: motors write [HOME SET] at line (1) :: display
Three things make that work, and all three are deliberate:
- Slowly. 20–30% is enough to reach the stop and gentle enough not to strain the gears or shake the build apart while it sits there.
- Long enough. Pick a time comfortably longer than the arm needs — one to three seconds for most mechanisms. It stalls partway through and spends the remainder pressed against the stop, which is exactly what you want.
- Then reset. reset degrees counted makes this position 0, so every measured move afterwards is measured from a place you know. Now run for (120) degrees is safe, because you know where it is starting from.
After that, use measured blocks for everything inside the travel and timed blocks whenever you are driving to a limit. The rule of thumb: if the movement ends against something solid, run for seconds.
Ports
A Medium Motor is normally plugged into port A or D, which leaves B and C free for the Large Motors that drive wheels. The letter in the block must match the port the cable is actually in — this is the single most common reason a program appears to do nothing at all.
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 MotorMedium MotorBlocks 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.
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: “A measured motor block finishes before the next one starts. That is how they take turns.”
What’s in this build 4 min
Three parts with cables — and this is the first model in the course with one of each motor.
Large — the turntableMedium — the screen| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Runs the program and holds the whole apparatus up. |
| Medium Motor, port A | Raises and lowers the white screen. Light and quick — a screen that drops slowly gives the game away. |
| Large Motor, port D | Turns the card holder a quarter turn at a time. Strong, because it is swinging four cards on an arm. |
You have to make the props
This model does not work out of the box. The manual asks you to make the paper parts yourself, and without them there is nothing to reveal.
- Cut and draw four face cards, roughly 70 × 100 mm. Make them boldly different from each other — different main colours, not four similar faces. From two metres away, subtlety is invisible.
- Punch a hole in each and clip it onto the holder with the red connector, so all four face outwards around the turntable.
- Cut one white blocking card, roughly 120 × 120 mm, and fix it to the screen arm. It must be big enough to hide a face completely, with margin.
- Hold the screen down by hand and look at the model from where an audience would sit. Can you see any part of a face card? If you can, the card is too small or the arm too short — fix it now.
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.
There is a second rule underneath that one, and today is the lesson that shows why it exists. B and C are for a pair. Two motors doing one job together go there — the Frog’s legs, the Tricycle’s wheels, the Push-up Robot’s arms. Two motors doing separate jobs take A and D instead.
| Part | Port | Why this one |
|---|---|---|
| Medium Motor (the screen) | A | A single motor with a job of its own takes A — as it has in nearly every lesson up to 24. |
| Large Motor (the turntable) | D | The other job goes to D, deliberately skipping B and C so nobody is tempted to drive these two as a pair. |
| Sensors | none | The machine cannot check that the screen is really down. It trusts the order of the blocks. |
Check your own build now:
- Medium Motor in A, Large Motor in D. Two letters, and not next to each other.
- Set the screen up and the turntable showing your first face before every run. The program assumes that starting point and cannot check it.
- Turn the turntable by hand through all four faces. Does each one land squarely facing forward?
- Sit where the audience will sit. Everything from here on is judged from that seat, not from above.
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
- Switch the Brick on with the dark grey centre button.
- Cable into the Brick’s PC port — the small square socket beside the numbered ports, not one of the numbered ones.
- 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.
- 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
EV3until somebody changes it. - Turn Bluetooth on. Settings → Bluetooth. Tick Bluetooth and Visibility. Leave iPhone/iPad/iPod unticked.
- Connect from EV3 Classroom. Click the Brick icon at the top of the programming area, find your Brick by name, and click Connect.
- Say yes on the Brick. It asks “Connect?” with the computer’s name — choose the tick, then accept the passkey, which is already 1234.
EV3.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 the cables behind the model. This one is performed to an audience, and a cable draped across the front is the visual equivalent of showing them how the trick works.
Confirm the connection 2 min
- Check the Brick icon: connected, or not.
- Port A shows a Medium Motor and port D shows a Large Motor. Nothing on B or C.
- If those two are the wrong way round, the screen motor will be turning the cards. Swap the cables rather than the program.
- Move the screen by hand and watch tile A count. Note how many degrees it takes to go from fully up to fully down — that is the number your program needs.
- Do the same for the turntable on D: how many degrees from one face to the next? With four faces it should be about a quarter turn at the card holder, but gearing may make the motor’s number much bigger.
Make it move 10 min
Seven blocks. Two settings, then a loop of three moves that take turns. Use your own measured numbers in place of the 90s.
when program starts :: events hat [A v] set speed to (40) % :: motors [D v] set speed to (30) % :: motors repeat (3) [A v] run [clockwise v] for (90) [degrees v] :: motors [D v] run [clockwise v] for (90) [degrees v] :: motors [A v] run [counterclockwise v] for (90) [degrees v] :: motors end
Walk it in the order the Brick runs it:
- [A] set speed to 40 % — a setting. The screen wants to be brisk; a slow screen is a screen the audience watches.
- [D] set speed to 30 % — the turntable, slower and steadier, because it is swinging four cards.
- repeat (3) — three changes.
- [A] run clockwise 90° — the screen drops. The block waits until it has finished, which is the guarantee the whole trick rests on.
- [D] run clockwise 90° — and only now do the faces turn, safely hidden.
- [A] run counterclockwise 90° — the screen lifts, and the new face is there.
What success looks like: from the audience seat, four different faces appear one after another, and at no point can you see a card moving. If you can see the turn, the trick has failed even if every block ran perfectly.
If the screen does not cover the face fully, that is a build problem and no number will fix it. Go back to section 5: a bigger card, or a longer arm.
Change it and test 8 min
One change at a time, and predict before each run — and judge every single one from the audience seat, not from above.
- Swap the order of the first two motor blocks, so D turns before A drops the screen. Predict what the audience sees. The trick is gone — they watch the face rotate in full view.
- Put it back and set the screen speed to 10 %. Slow enough that the audience watches the screen come down and knows exactly when something is being hidden. A trick that announces itself is not a trick.
- Now 100 % on the screen. Predict whether faster is always better. Very fast often means the screen bounces on the way down and lifts for a moment — watch closely.
- Add a wait (2) seconds after the screen lifts, inside the loop. Now each face gets a moment to be admired. Does that make it a better performance?
- Add a play beep (72) for (0.2) seconds — from Lesson 30 — at the moment the screen lifts. A sound on the reveal is what a stage magician would do.
Step 1 is the lesson. Nothing was misspelled, nothing was the wrong block, nothing broke — and the machine failed completely, because two correct actions happened in the wrong order.
When two parts must not overlap, the order of the blocks is not a detail of the program. It is the machine.
