Challenge 1
Prove the interlock. Press and release ten times in a row, quickly, and the blade must behave identically every time — starting only on the press and stopping on the release, with no lag you can see.
What you are building 3 min
The Saw Machine: a Large Motor driving a blade, and a Touch Sensor that has to be held down for the blade to turn. Let go and it stops.
Every other machine you have built this level starts when you press Play and runs until it decides to finish. This one is different, and the difference is the whole lesson.
The operator has to keep agreeing. Not once at the start — continuously, for as long as the blade is moving. The moment they stop agreeing, so does the machine.
In the real world 5 min
Where you have seen it
A sawmill blade is a metre across and turns fast enough that you cannot see the teeth. It will go through a tree trunk without slowing down, which tells you everything about what it would do to an arm.
Why it is built that way
Look at any dangerous machine — a hedge trimmer, a chainsaw, a paper guillotine, a lawnmower, an angle grinder — and you find the same arrangement. A control the operator must hold, which the machine reads as “a person is still here and still wants this”.
It is called a dead-man’s switch, and the name is exact. The engineering assumption is that if the operator lets go — because they slipped, or fainted, or panicked, or were pulled away — the safest thing the machine can do is stop. Letting go is not treated as an accident. It is treated as a command.
Trains have them too. A driver who stops holding the pedal gets the brakes applied for them.
What would go wrong without it
A blade with an on-switch and an off-switch keeps spinning through anything that happens to its operator. The whole point of a hold-to-run control is that doing nothing is the safe state — and doing nothing is exactly what an injured or frightened person does.
Design it so that the thing which happens when everything goes wrong is the safe thing.
The main concept — a loop that watches both edges 6 min
Two waits, facing opposite ways, inside a forever loop. That is the entire pattern, and it is worth learning by heart.
forever [1 v] wait until [pressed v] :: sensors [A v] start motor at (75) % speed :: motors [1 v] wait until [released v] :: sensors [A v] stop motor :: motors end
Walk one lap of it, slowly:
- The loop reaches wait until pressed and stops there. The blade is still. Nothing is happening, and nothing will, possibly for hours.
- You press. The wait releases and start motor runs — which, as Lesson 7 established, does not wait for anything. The blade is now turning and the stack has already moved on.
- The loop reaches wait until released and stops there. The blade keeps turning the whole time, because nothing has told it otherwise.
- You let go. The wait releases, stop motor runs, and the loop goes back to the top to wait for the next press.
Step 3 is the one people get wrong. It looks like the program is doing nothing while the blade spins — and it is. That is correct. The blade does not need the program’s attention to keep turning; it needs it only to stop.
Why this needs `start motor` and not `run for`
Try writing it with run for (5) rotations instead. The stack would sit on that block for five rotations and could not notice the release until they were finished. The operator lets go and the blade carries on. A hold-to-run control that ignores you for five rotations is not a safety feature.
And why the stop setting matters more here than anywhere
stop motor honours the setting you met in Lesson 2. On coast, a blade released at 75% will freewheel for a while after the operator has let go. On brake, it stops in a fraction of the time.
| Setting | What happens when you let go |
|---|---|
| coast | The blade keeps spinning down on its own. Gentle on the gears, and wrong for a saw. |
| brake | The blade stops quickly. This is what a real saw’s blade brake does, and it is why they are fitted. |
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
pressedBlocks 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.
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.
Hold-to-run is not “on and off”. It is a machine that needs permission continuously.
Loops that never endThe forever loop and how to get out of one. Open it if forever still feels risky.Show meHide
Repeating
Machines repeat. A wiper sweeps, a conveyor runs, a ride goes round — and none of that should mean copying the same blocks over and over. A loop says “do this again” once.
Blocks reference
| Block | What it does |
|---|---|
repeat (10) end | Runs the blocks inside a set number of times, then carries on below. |
forever end | Runs the blocks inside over and over, and never carries on below. |
repeat until <> end | Repeats until a condition becomes true — a loop with a sensor as its exit. |
Forever really does mean forever
Anything placed after a forever loop will never run. Not “runs late” — never. Both programs below end with the same block: set the status light green.
repeat (3)
repeat 3
A run clockwise for 0.25 rotations
set status light to green
forever
forever
A run clockwise for 0.25 rotations
set status light to green
↑ this block never runs
0passes · repeat (3)0passes · forever
repeat (3): still goingforever: light never set
Both loops begin. Each pass turns the motor a quarter turn.
Both programs contain the same green-light block. Let it run as long as you like — the right-hand ring will never turn green.
The repeat loop counts its three passes, stops, and moves on to the block underneath, so its light turns green. The forever loop reaches the bottom of its own blocks and jumps straight back to the top, so the block underneath is never reached — however long you leave it. If a program seems to stop half way through, look for a forever loop above the blocks that are not happening.
Why a sensor program needs a loop at all
A program is a list, and the Brick works down it once. Every block runs, in order, and when the last one is done the program is over. That is fine for a list of instructions — drive, turn, beep, stop — because each is a thing you do once.
A sensor is not a thing you do once. Asking is 1 pressed? gives you an answer about this instant, and an instant later it may be wrong. Checking a sensor once tells you what the world was like at the moment the program started — which is almost never what you wanted to know.
So a program that has to react must ask again, and again, for as long as it is running. That is the whole job of the loop: not to repeat an action, but to keep the question being asked.
Read, decide, act — and then do it again
Wrap a sensor check and the motor it controls in a forever loop and you have built a closed-loop control system — the pattern behind every line follower, thermostat and cruise control:
- Read the sensor.
- Decide what that reading means.
- Act on the motors.
- Go back to 1 — immediately, thousands of times a minute.
It is called closed because the output feeds back round to the input: the motors move the robot, moving the robot changes what the sensor sees, and what the sensor sees changes the motors. Break the circle at any point and the robot stops responding.
when program starts :: events hat
forever
if <[1 v] is pressed? :: sensors> then
[A v] start motor [clockwise v] :: motors
else
[A v] stop motor :: motors
end
endRead it as a sentence and it is almost too simple to need explaining: for ever, if the button is pressed run the motor, otherwise stop it. The motor now follows the button for as long as the program is running.
The same program without the loop
This is the mistake nearly everybody makes first, and it is a hard one to spot because nothing about it looks wrong:
when program starts :: events hat if <[1 v] is pressed? :: sensors> then [A v] start motor [clockwise v] :: motors else [A v] stop motor :: motors end
The logic is perfect. The ports are right. Nothing is misspelled. And the robot will ignore the button completely — because the Brick reaches that if/else a few milliseconds after you press Run, finds the button not pressed, takes the else branch, stops the motor, runs out of blocks and ends. By the time a finger arrives, there is no program left to notice it.
with forever — a closed loop
when program starts
forever
if 1 is pressed? then
A start motor clockwise
else
A stop motor
without it — the common mistake
when program starts
if 1 is pressed? then
A start motor clockwise
else
A stop motor
↑ running — for the only time
40checks · with forever1checks · no loop
Looped: motor off, matching the buttonNo loop: motor off for ever, whatever you press
Both programs start. The button is not pressed, so both take the else branch and leave the motor off. So far they agree exactly.
Both programs contain exactly the same if/else. The only difference is the forever block around one of them.
Both programs contain exactly the same if/else. The counter is what gives it away: one keeps checking for as long as it runs, the other is stuck on the single check it made before anybody touched anything. A student who has seen this once stops writing it.
The tell on a real robot is a program that ends the instant you start it — the Brick returns to its menu almost immediately. If a sensor program finishes rather than waits, the loop is what is missing.
Choosing the right loop
- Known number of times — repeat (n). A wiper that sweeps five times.
- Until something happens — repeat until. Drive until the wall is close.
- For as long as the machine is on — forever. A fan, a ride, a monitor.
Say this back before moving on: “Letting go is a command, not a mistake.”
What’s in this build 4 min
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Watches the button many times a second. Its speed of response is literally the safety of the machine. |
| Large Motor — the blade | Spins the saw. Large because cutting takes force, and because a blade that stalls in the cut is worse than a slow one. |
| Touch Sensor | The dead-man’s switch. Mount it where a hand naturally rests away from the blade — this is a design decision, not a wiring one. |
| The blade and guard (not electronic) | A guard is not decoration. If your model has one, it stays on. |
Where the button goes
- Hold the machine as an operator would, ready to feed material in. Where does your other hand naturally sit?
- Put the Touch Sensor there — and check that holding it puts that hand somewhere the blade cannot reach.
- Press and release it a few times. It should be comfortable to hold down for ten seconds and instant to release.
- A button you have to stretch for is a button somebody will jam down with a brick. If yours is awkward, move 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.
| Part | Port | Why this one |
|---|---|---|
| Blade motor (Large) | A | One job motor, driving one blade. |
| Touch Sensor | 1 | Touch is always port 1. Today it is also the only thing standing between the blade and whatever is in front of it. |
Check your own build now:
- Motor in A, Touch in 1.
- Route the sensor cable so it cannot be pulled out by the operator moving their hand. A cable that comes loose mid-cut leaves a blade spinning with no way to stop it except Play.
- Keep the blade clear of the table and of the cable.
- Agree who is operating before you switch anything on.
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.
Know where Stop is before you run this. Whichever way you connect, find the stop button in EV3 Classroom and the grey button on the Brick now. A forever loop does not end on its own, and this is the first model where you may genuinely want it to end early.
Confirm the connection 2 min
- Check the Brick icon: connected, or not.
- A Large Motor on A and a Touch on 1.
- Press and release the Touch Sensor several times and watch its tile. It must change every single time. A sensor that sticks is a blade that does not stop.
- Turn the blade by hand and check tile A counts.
- Do not run anything until the button has been proven. This is the one lesson where that check is not a formality.
Make it move 10 min
The interlock, with the screen saying which state the machine is in so a bystander can tell at a glance.
when program starts :: events hat [A v] set motor to [brake v] at stop :: motors clear display :: display forever write [BERHENTI] at line (1) :: display [1 v] wait until [pressed v] :: sensors write [POTONG ] at line (1) :: display [A v] start motor at (70) % speed :: motors [1 v] wait until [released v] :: sensors [A v] stop motor :: motors end
- brake at stop — set once, before the loop. It is what makes the release quick rather than gradual.
- write BERHENTI — “stopped”. Written at the top of every lap, so the screen is correct the moment the blade stops.
- wait until pressed — the machine sits here doing nothing, safely, for as long as nobody touches it.
- POTONG, then start motor — “cutting”, and the blade spins up. The screen changes before the motor starts, on purpose.
- wait until released, then stop — and round again.
What success looks like: the blade runs only while the button is held, every time, with no lag you can perceive. Press and release quickly ten times — it should behave identically on the tenth as on the first.
If the blade keeps running after you let go, the sensor is not being seen as released — most often because it is physically jammed down by the build. Fix the mounting, not the program.
Change it and test 8 min
Blade clear of everything for all of these, and one hand on the Brick’s stop button for the ones that break the interlock on purpose.
- Change brake to coast. Hold the button, let go, and count how long the blade takes to stop. Then put brake back and count again. Write down both numbers.
- Replace
start motor at (70) % speedwith[A v] run for (3) [rotations v] at (70) % speed. Hold the button, then let go immediately. The blade finishes its three rotations anyway — the interlock is now decorative. - Put it back. Then swap the two waits round — released first, pressed second. Predict what the machine does before you run it, then find out.
- Add a second, lower speed: run at 30% instead of 70. Does a slower blade feel safer, or does it just stall in the paper?
- Add
play beep (50) for (0.1) secondsimmediately after the press, before the motor starts. A warning tone before anything moves. Real machines do this, and now you know why.
Step 2 is the important one and it is worth being uncomfortable about. Nothing broke. No error appeared. The program still looks like a hold-to-run control, and it is not one any more — and the only way to find that out is to test the release, not the press.
Test the safety feature by trying to defeat it. A guard nobody has attacked is a guard nobody has checked.
