Challenge 1
Count the presses. Set the timer to 2:45 and count how many button presses it took. Then remove the fine buttons and count again. Report both numbers. That difference is what coarse-and-fine steps are worth.
What you are building 3 min
The Microwave: a door that opens and closes, a turntable that spins, a switch that knows whether the door is shut, and a screen you set the time on.
Lesson 20’s menu chose between four things somebody had written down. A microwave cannot work that way — nobody can list every number of seconds a person might want, and a menu of them would be thousands long.
By the end of the lesson a user will be able to enter any time from ten seconds to five minutes, quickly, with four buttons — and the machine will not start until it is told to.
In the real world 5 min
Where you have seen it
Look at a microwave’s controls. There is almost always a +30 seconds button, because most of what people do is “a bit more”. There is usually a dial or a set of digits for a specific time. And there is always a separate Start.
That separation matters. Typing a time does nothing on its own — you can change your mind, correct a mistake, and see what the machine thinks before anything happens. The oven only runs when you say so.
Why it is built that way
Because entering a number with a few buttons is slow, and designers work hard to make it fast. A single +1 button would need ninety presses for a minute and a half — so real machines give you coarse steps as well as fine ones, and often a shortcut for the common case.
The other half is bounds. A microwave will not accept ninety minutes for a bowl of soup, and a machine that lets a user enter something absurd has failed to help them.
What would go wrong without it
A machine that acts on each keystroke gives no chance to correct a mistake — press the wrong thing and it is already happening. That is why the door switch and the Start button are separate, and why neither of them is the number pad.
Let them enter it, let them see it, let them change it — and only then act.
The main concept — entering a value 6 min
Picking an option and entering a number are different problems. A menu has a fixed list; a number has a range, and the interface has to make crossing that range quick.
| Menu (Lesson 20) | Value entry (today) | |
|---|---|---|
| Choices | A list somebody wrote. | Any number in a range. |
| Getting there | Scroll a few items. | Could be hundreds of presses — so it needs coarse steps. |
| Wrong entry | Impossible — every option is valid. | Very possible. Needs bounds. |
| Acting | Often on selection. | Never until confirmed. |
Coarse and fine
if <brick [up v] button pressed? :: sensors> then change [seconds v] by (10) :: variables wait (0.2) seconds :: control end if <brick [right v] button pressed? :: sensors> then change [seconds v] by (1) :: variables wait (0.2) seconds :: control end
Bounds, clamped not wrapped
if <(seconds) > (300)> then set [seconds v] to (300) :: variables end if <(seconds) < (0)> then set [seconds v] to (0) :: variables end
This is the opposite of Lesson 21’s cycling, on purpose. A list of modes wraps because every option is equally reachable either way. A number does not, because 300 and 0 are not neighbours — they are opposite ends, and landing on the wrong one is a real mistake.
Enter, then confirm
The number being edited is not yet the number being used. Nothing happens while the user is adjusting it — the machine shows the value and waits for a separate, deliberate press.
And the confirm can refuse. A microwave with the door open does not start, and it says why rather than doing nothing — Lesson 19’s guard clause, now guarding a user action rather than a program start.
Showing a number usefully
Ninety seconds is easier to read as 1:30 than as 90. Minutes are seconds ÷ 60 rounded down, and the remainder is seconds mod 60 — which is Lesson 31’s derived value doing interface work.
The Brick buttons
The Brick has five buttons of its own — up, down, left, right and centre. They need no sensor, no cable and no port, which makes them the easiest way to let a person tell the robot to do something.
Blocks reference
| Block | What it does |
|---|---|
when [center v] button [pressed v] :: events hat | Starts a whole stack when that button is pressed. |
wait until <is [center v] button pressed? :: sensors> | Holds an existing program until the button is pressed. |
Press to begin
A program sitting on a wait block looks exactly like a program that has crashed. Watch one wait — including through two presses of the wrong button.
when program starts
wait until is center button pressed?
A run clockwise for 1 rotations
the other way to do it
when center button pressed
A run clockwise for 1 rotations
The program has reached the wait block. It is not stuck — it is waiting, and nothing below it will run until the centre button goes down.
A program parked on a wait block looks identical to a crashed one. This is why the status light or a line on the screen is worth setting before you wait.
The wait is watching one button. Up and right change the (button) reading, and the program does not care. That reading is a number rather than a name: 0 for nothing, then 1 left, 2 centre, 3 right, 4 up, 5 down.
A hat, or a wait?
- A hat gives the button its own separate stack, which can run at any time. Good for a control the user may press whenever they like.
- A wait puts the button in the middle of a sequence. Good for “press to begin”, where nothing should happen before it.
Why it matters
Nearly every machine has a start button that is deliberately separate from switching the power on. A robot that begins moving the instant it is powered up is hard to set down and hard to test — one that waits for a press can be positioned first.
Variables
Why anybody needs one
Long before there were computers, people had exactly this problem. A shepherd counting sheep through a gate, a trader counting sacks of grain, a builder counting days — none of them can hold the number in their head while they get on with the work. So they scratched a mark on a wall, cut a notch in a stick, or wrote a number on a piece of paper. The number lived outside the person, in a place they had agreed on, and they could go back to it, read it, and change it.
Better still, once the number is written down somebody else can use it. Watch these two: one of them counts and writes, the other never sees a single animal and simply reads the wall.
Abby never remembers the numberBen never sees a henThe wall holds it for both
Abby has a gate and a wall. Before a single hen comes through she chalks 0 on the wall — that is where the number is going to live.
Notice what never happens: Ben never asks Abby. He does not need to — the number is not in her head, it is on the wall, and the wall is there for anyone who needs it.
Neither Abby nor Ben is holding the number — the wall is. And notice what never happens: Ben does not ask Abby. He does not need to, because the count is not in her head. It is in a place they both agreed on, which is what makes it useful to more than one of them.
That is all a variable is. The robot cannot hold a number in its head either, so you give it a wall of its own, write a name at the top so everyone knows which wall is which — score, count, degree_turn — and the program can read what is on it and write something new. One part of the program writes; another part reads. Exactly Abby and Ben.
The paper, and the two things you can do to it
Say we are counting rotations of a motor. Before we start we write 0 on the paper. Every time the motor completes a turn we cross out what is there and write one more: 0 becomes 1, then 2, then 3. That is change — it has to read the old number to work out the new one.
set is the other thing you can do, and it is completely different: rub the whole paper out and write the number you want. It does not care what was there. Press the buttons and watch what happens to the crossings-out.
score
0
The paper starts blank, so we write 0 on it. That is what a variable is: a place to keep a number while the robot works.
- change leaves a trail — every value follows from the one before it. This is what counting is.
- set wipes the sheet. Use it to start a count, never to continue one.
- Press set score to 0 after counting up a few times and watch the whole history vanish. That is what happens to a count when a set block ends up in the wrong place — and it is the commonest variable bug there is.
Blocks reference
| Block | What it does |
|---|---|
set [count v] to (0) | Puts a value in, replacing whatever was there. |
change [count v] by (1) | Adds to what is already there. |
(count) | Reports the current value, for use in a comparison or on the display. |
Set, or change?
set replaces; change adds. Counting things needs change. Starting a count needs set. Both programs below have both blocks — the only difference is whether the set block is inside the loop or above it.
set before the loop
when program starts
set count to 0
repeat 4
A run clockwise for 1 rotations
change count by 1
set inside it
repeat 4
set count to 0
A run clockwise for 1 rotations
change count by 1
Before the loop: counted 0Inside the loop: stuck at 0
Both programs count the turns of a motor. The left sets the count to zero before the loop; the right sets it inside.
Both programs contain both blocks. Only the position of set [count] to 0 is different.
The count on the right is not broken; it is being told to start again on every pass. Each time round the loop it is wiped back to zero and then changed by one, so the honest answer is always 1 — while the motor cheerfully turns four times. A counter stuck at 1 almost always means a set block that has slipped inside the loop.
Anything oval is a number you can pick up
EV3 Classroom tells you what a block does by its shape, and once you have noticed that, a whole set of questions answers itself:
- Oval — reports a number. The blue degrees counted, the timer, a distance, your own variable.
- Pointed — reports true or false. These go in an if or a wait until, not in a variable.
- Block-shaped — does something. These stack up; they do not fit inside anything.
So when a slot is oval, any oval fits it — and it does not matter in the least where that number came from. You can take the motor’s own A degrees counted and keep it in a variable you named degree_turn, then compare that with a number later. Pick an oval below and watch the same one drop into all three kinds of slot.
pick an oval
the same oval fits all three
set degree_turn to A degrees countedkeep it in a variable of your own
A degrees counted + 10do arithmetic with it
A degrees counted > 50compare it with a number
Every one of those slots is oval-shaped, and A degrees counted is an oval — so it drops in. Nothing about where the number came from matters.
This is what makes a variable more than a counter. A sensor reading is true only at the instant you read it; copying it into a variable freezes it, so the robot can compare where it is now against where it was when something happened:
when program starts :: events hat [A v] reset degrees counted :: motors set [degree_turn v] to ([A v] degrees counted :: sensors) start moving [right: 30] :: movement wait until <(([A v] degrees counted :: sensors) - (degree_turn)) > (400)> stop moving :: movement
Read the condition aloud: how far the motor has gone now, minus where it was when we started, is more than 400. Both are ovals, so both can go into a subtraction, and the subtraction is an oval too — which is why it can go into a comparison. Ovals nest inside ovals as deep as you need.
Reset at the start, every time
A variable keeps its value after the program ends. Run the program again without setting it back and the second run begins where the first left off — the count starts at 14, the robot thinks it has already done the job. Every variable a program changes must be set to its starting value at the top.
Why it matters
A variable is the difference between a machine that repeats a fixed routine and one that responds to how things have gone — counting parts, tracking a score, remembering where it started.
The Brick display
The Brick’s screen is a small black-and-white whiteboard. You can wipe it, draw one of the built-in pictures on it, or write your own words at a spot you choose. It is how the robot tells a person what it is doing.
Blocks reference
| Block | What it does |
|---|---|
clear display :: display | Wipes the screen blank, ready for something new. |
display [Eyes / Neutral v] :: display | Draws a built-in picture chosen from a list — eyes, faces, arrows, symbols. |
display [Eyes / Neutral v] for (2) seconds :: display | Draws the picture, holds the program for that long, and then carries on. Handy when a face should be seen before anything else happens. |
write [Hello] at line (1) :: display | Writes your own text on one of the screen’s eight lines. |
write [Hello] at x: (10) y: (40) with font [normal black v] :: display | Writes text at an exact spot instead of a line, and lets you choose the size. Use it when a message has to line up with something else on the screen. |
Clear it, or write on top of what is there
The screen has no memory of whose writing is whose. It keeps every mark until something wipes it — including the marks left by the last run. Watch the same program with and without its clear display block.
with clear display
when program starts
clear display
display Eyes / Neutral
write GATE OPEN at line 7
without it
display Eyes / Neutral
write GATE OPEN at line 7
1lines · cleared1lines · not cleared1run
Cleared: one message, readableNot cleared: 1 messages on line 7
Both Bricks still show whatever was left on the screen when the last run ended.
Let it loop two or three times. The left screen still reads cleanly; the right one is the same program with one block missing.
Both Bricks are told exactly the same thing. The left one wipes the screen first, so line 7 holds one message and reads correctly. The right one never wipes, so each new message is drawn over the last and the words turn into a smudge. This is why a program that seems to display nonsense is usually displaying the truth — several times over.
Where the writing goes
There are two blocks for writing text, and they describe where in two completely different ways. Watch one message move around the screen under both of them.
clear display
write READY at line 1
write READY at x: – y: – with font normal black
the screen is 178 pixels across and 128 down
0x · across0y · down1line
write [READY] at line (1). Line 1 is the top of the screen, hard against the left edge.
The arrows are the two numbers. The one along the top is x; the one down the side is y, and it counts downwards from the top edge.
Writing on a line
write [EV3] at line (1) is the simple one. You give it a line number and it puts the text there, starting hard against the left edge — you do not choose how far across, only how far down.
- Line 1 is the top. The numbers count downwards, so line 2 is below line 1, not above it.
- There are eight of them, each about ten pixels lower than the last. That means all eight sit in the upper part of the screen and the line block cannot reach the bottom at all.
- One message per line. Two messages sent to the same line land on top of each other and turn into a smudge — put them on different lines, or clear the screen in between.
For most robots this is all you need: a status word on line 1, a reading on line 3, a warning on line 5. Pick your lines at the start and keep each one for one job, the way you would keep one colour of status light for one meaning.
Writing at x and y
write [EV3] at x: () y: () with font [] treats the screen as a grid of pixels — 178 across and 128 down — and lets you put the text anywhere on it.
- x is how far across, from the left edge. x: 0 is the far left; x: 177 is the far right. Bigger x moves right, which is what everybody expects.
- y is how far down, from the top edge. y: 0 is the very top; y: 127 is the bottom. Bigger y means lower — this is the one that catches people out, because on a graph at school a bigger y means higher.
- The corner is 0, 0. x: 0 y: 0 is the top-left, and it puts the text in exactly the same place as at line 1 — the two blocks are describing the same screen.
- The pair of numbers is the top-left corner of the text, not its middle. The letters go down and to the right from the point you name.
The block ends with a font dropdown, and normal black is the usual choice. A larger font makes the writing easier to read from across the room but takes more room across the screen, so fewer characters fit before the text runs off the edge.
Which one to use
- Use lines for ordinary status messages — quick to write, impossible to get wrong, and eight of them is plenty for one robot.
- Use x and y when the position itself matters: putting a label and its number side by side, lining a heading up over a reading, filling the lower part of the screen, or moving something across the screen as a value changes.
Putting a number on the screen
The text slot of either block will take a reporter, so a sensor value can be shown directly: drop (4 distance in cm) into the slot and the screen shows the reading. That is the EV3’s version of a print statement, and it is the fastest way to find out what a robot actually thinks it is seeing.
A bare number on its own is hard to read, though. To show DIST: 23 rather than 23, use the operator block join [DIST: ] () to glue the label to the value, and put the join into the write block’s text slot.
when program starts :: events hat clear display :: display forever write (join [DIST: ] ([4 v] distance in [cm v] :: sensors)) at line (1) :: display end
Note the forever: a value written once is a value from the start of the program. To watch a reading change, the write block has to be inside a loop.
Advanced — a dashboard, not a number
Once one value is on the screen the rest follows, and the useful trick throughout is join: it glues two pieces of text together and hands the result to the write block. Anything that reports a value can go in either slot — a variable, a sensor, or another join.
A variable with a label on it
Counting is the classic case. A variable counts how many times the Touch Sensor has been pressed, and a bare 5 on the screen tells nobody anything — PRESSED: 5 tells them everything:
when program starts :: events hat clear display :: display set [count v] to (0) :: variables forever wait until <[1 v] is pressed? :: sensors> change [count v] by (1) :: variables write (join [PRESSED: ] (count)) at line (1) :: display wait until <not <[1 v] is pressed? :: sensors>> end
The two wait until blocks are what make it count presses rather than counting as fast as the loop runs while your finger is down. That is the Touch Sensor’s own lesson, but it shows up here because a counter on the screen is where you first notice it going wrong.
Several sensors, one line each
Give every reading its own line and keep it. A line that changes meaning halfway through a program is unreadable at a glance, which is the only speed a screen on a moving robot gets read at.
when program starts :: events hat clear display :: display forever write (join [DIST: ] ([4 v] distance in [cm v] :: sensors)) at line (2) :: display write (join [DEG: ] ([A v] degrees counted :: sensors)) at line (5) :: display end
degrees counted is worth putting on the screen the first time you use it — it is the fastest way to find out whether a motor is turning as far as you think it is, and it is the block behind every “why did it stop early” question.
Turning a number into a word
Sensors report numbers, and people read words. The Colour Sensor reports 5; the person watching wants RED. A chain of if … then … else blocks does the translation, and it is worth doing once into a variable rather than in every write block:
if <([3 v] color :: sensors) = (5)> then
set [name v] to [RED] :: variables
else
if <([3 v] color :: sensors) = (4)> then
set [name v] to [YELLOW] :: variables
else
set [name v] to [OTHER] :: variables
end
end
write (join [COLOR: ] (name)) at line (4) :: displayThe same shape turns a distance into a warning. Here the screen carries the number and what the number means, which is what lets somebody across the room tell whether the robot is about to hit something:
if <([4 v] distance in [cm v] :: sensors) < (10)> then
set [status v] to [TOO CLOSE!] :: variables
else
if <([4 v] distance in [cm v] :: sensors) < (30)> then
set [status v] to [OBSTACLE FOUND] :: variables
else
set [status v] to [NOTHING FOUND] :: variables
end
end
write (status) at line (3) :: displayDrive all four of those at once below. The screen is the real thing — five write blocks, five lines, and every one of them a join.
Drive the sensors and read the screen. Every line is one write block with a join in its text slot.
24 cm
180°
Colour Sensor5 → RED
Touch Sensor3 presses
| Line | What goes in the write block | On the screen now |
|---|---|---|
| 1 | join "PRESSED: " (count) | PRESSED: 3 |
| 2 | join "DIST: " (4 distance in cm) | DIST: 24 |
| 3 | (status) — set by the if chain | OBSTACLE FOUND |
| 4 | join "COLOR: " (name) | COLOR: RED |
| 5 | join "DEG: " (A degrees counted) | DEG: 180 |
Line 4 says COLOR: RED, but the sensor only ever said 5. The if chain in between is what turns a number into a word.
Advanced — stopping the screen from flickering
The moment a reading goes inside a loop, one of two things goes wrong, and which one depends on where the clear display block went.
Almost everybody tries clear inside the loop first. It gives the right text — and a screen that blinks several times a second, because between the clear and the write there is genuinely nothing on the screen and the loop goes round faster than your eye.
So the clear gets moved to the start of the program, the blinking stops, and the words go wrong. Writing text paints only the characters it has and leaves everything past them exactly where it was. Write RED over YELLOW and the LOW is still there: the screen says REDLOW. Go the other way — yellow first, then red — and it looks fine, which is why this bug takes so long to pin down.
when program starts :: events hat clear display :: display forever write (name) at line (3) :: display end
YELLOWwhat the sensor says—what the screen says0characters left behind
never blankleftovers survive
The Colour Sensor reads a colour and the name goes on line 3, over and over, inside a forever loop.
Watch the bottom three rows rather than the Brick. They are what the screen is actually doing: old characters, new characters, and whatever survives.
The fix is to make the new text at least as long as the old one, and join already does that: pad it with spaces. RED plus three spaces is six characters — exactly enough to paint over YELLOW. Nothing is left behind, and nothing is ever blank.
write (join (name) [ ]) at line (3) :: display
Pad to the length of the longest thing that line can ever show. Six characters covers RED, BLUE and GREEN but not NOTHING FOUND — count the longest message, and add spaces to match. The same applies to numbers: DIST: 5 after DIST: 40 leaves a stray 0 on the end, so a line that shows a two-digit reading needs a trailing space.
Use clear-inside-the-loop when the whole screen changes at once and a flicker does not matter; use the padding trick whenever a value is being watched.
Advanced — a whole list on the screen
Once several values need showing, the line number becomes a counter and the values come out of a list: write item 1 at line 1, item 2 at line 2, and so on inside a repeat. That needs the list blocks rather than the display blocks, so it lives with them — Lists covers building one and reading it back item by item, and the loop that walks it is the same loop that fills the screen.
Why it matters
Machines in the real world tell you what they are doing: a microwave counts down, a lift shows its floor, a car dashboard warns you. A robot that shows WAITING and then OPEN is far easier to understand — and far easier to debug — than one that moves silently.
Coarse and fine steps, clamped at both ends, shown clearly, and used only when confirmed.
The Brick buttonsFrom Lesson 20 — four directions and a centre, and why every press needs a debounce.Show meHide
The Brick buttons
The Brick has five buttons of its own — up, down, left, right and centre. They need no sensor, no cable and no port, which makes them the easiest way to let a person tell the robot to do something.
Blocks reference
| Block | What it does |
|---|---|
when [center v] button [pressed v] :: events hat | Starts a whole stack when that button is pressed. |
wait until <is [center v] button pressed? :: sensors> | Holds an existing program until the button is pressed. |
Press to begin
A program sitting on a wait block looks exactly like a program that has crashed. Watch one wait — including through two presses of the wrong button.
when program starts
wait until is center button pressed?
A run clockwise for 1 rotations
the other way to do it
when center button pressed
A run clockwise for 1 rotations
The program has reached the wait block. It is not stuck — it is waiting, and nothing below it will run until the centre button goes down.
A program parked on a wait block looks identical to a crashed one. This is why the status light or a line on the screen is worth setting before you wait.
The wait is watching one button. Up and right change the (button) reading, and the program does not care. That reading is a number rather than a name: 0 for nothing, then 1 left, 2 centre, 3 right, 4 up, 5 down.
A hat, or a wait?
- A hat gives the button its own separate stack, which can run at any time. Good for a control the user may press whenever they like.
- A wait puts the button in the middle of a sequence. Good for “press to begin”, where nothing should happen before it.
Why it matters
Nearly every machine has a start button that is deliberately separate from switching the power on. A robot that begins moving the instant it is powered up is hard to set down and hard to test — one that waits for a press can be positioned first.
Say this back before moving on: “Set it, check it, then start it.”
What’s in this build 4 min
Open and close the door and watch the switch. Does it read “shut” only when the door is genuinely shut? Everything about safety here depends on that one answer.
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | The control panel. Its screen and buttons are the entire interface, and this is the most demanding one in the course — a number, a countdown and a state, all readable at a glance. |
| Medium Motor — the turntable | Turns while cooking. It is the visible sign that the machine is running, so it must not turn at any other time. |
| Large Motor — the door | Opens and closes the door. Large because a door has to move decisively and stay where it is put. |
| Touch Sensor — the door switch | Reports whether the door is actually shut. Note this is separate from the door motor: knowing you commanded the door shut is not the same as knowing it is shut. |
| Touch Sensor — start / stop | The confirm. Deliberately not one of the Brick buttons, so setting the time and starting the machine cannot be confused. |
The door switch must read open when the door is even slightly ajar. A switch that says shut for a door that is nearly shut is exactly the failure a real microwave’s interlock exists to prevent — and it is worth testing by hand before writing anything.
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 |
|---|---|---|
| Turntable (Medium) | A | The running indicator. |
| Door (Large) | B | The second motor. |
| Door switch (Touch) | 1 | Touch stays on 1 across the course. |
| Start (Touch) | 2 | The confirm, on its own port and its own physical button. |
Check your own build now:
- Turntable in A, door in B, door switch in 1, start in 2.
- Close the door and confirm the switch reads pressed. Then open it a centimetre and confirm it does not.
- Check the turntable spins freely and is visible with the door shut — it is how a user knows the machine is running.
- Mount the start button where it cannot be hit by accident while somebody is setting the time.
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.
Download and unplug, then use it. This is the most appliance-like model in the course, and the last challenge asks somebody else to operate it with no instructions.
Confirm the connection 2 min
- Check the Brick icon: connected, or not.
- Two motor tiles — A and B.
- Two sensor tiles — 1 and 2.
- Press each Brick button in turn and confirm you can tell them apart by feel. A user setting a time is looking at the screen, not at their thumb — and Up meaning +10 while Right means +1 only works if they can be found blind.
Stuck? The long version, with a photograph of every screen, is in the Brick & Bluetooth guide.
Make it move 10 min
Build the entry first and get it feeling right before anything cooks. An interface you cannot use quickly is worth fixing before the machine behind it exists.
Step 1 — setting a time
when program starts :: events hat
set [seconds v] to (30) :: variables
clear display :: display
forever
if <brick [up v] button pressed? :: sensors> then
change [seconds v] by (10) :: variables
wait (0.2) seconds :: control
end
if <brick [down v] button pressed? :: sensors> then
change [seconds v] by (-10) :: variables
wait (0.2) seconds :: control
end
if <brick [right v] button pressed? :: sensors> then
change [seconds v] by (1) :: variables
wait (0.2) seconds :: control
end
if <brick [left v] button pressed? :: sensors> then
change [seconds v] by (-1) :: variables
wait (0.2) seconds :: control
end
if <(seconds) > (300)> then
set [seconds v] to (300) :: variables
end
if <(seconds) < (0)> then
set [seconds v] to (0) :: variables
end
write [SET TIME] at line (1) :: display
write ([floor v] of ((seconds) / (60))) at line (3) :: display
write ((seconds) mod (60)) at line (4) :: display
endStep 2 — the whole appliance
when program starts :: events hat
set [seconds v] to (30) :: variables
set [running v] to (0) :: variables
clear display :: display
// ---- setting: only allowed when not running ----
when program starts :: events hat
forever
if <(running) = (0)> then
if <brick [up v] button pressed? :: sensors> then
change [seconds v] by (10) :: variables
wait (0.2) seconds :: control
end
if <brick [down v] button pressed? :: sensors> then
change [seconds v] by (-10) :: variables
wait (0.2) seconds :: control
end
if <brick [right v] button pressed? :: sensors> then
change [seconds v] by (1) :: variables
wait (0.2) seconds :: control
end
if <(seconds) > (300)> then
set [seconds v] to (300) :: variables
end
if <(seconds) < (0)> then
set [seconds v] to (0) :: variables
end
end
end
// ---- the confirm, which is allowed to refuse ----
when program starts :: events hat
forever
wait until <[2 v] is pressed? :: sensors>
wait until <not <[2 v] is pressed? :: sensors>> :: control
if <(running) = (1)> then
set [running v] to (0) :: variables
else
if <not <[1 v] is pressed? :: sensors>> then
write [CLOSE THE DOOR] at line (1) :: display
play sound [Mechanical / Error v] :: sound
wait (1.5) seconds :: control
else
if <(seconds) = (0)> then
write [SET A TIME FIRST] at line (1) :: display
play sound [Mechanical / Error v] :: sound
wait (1.5) seconds :: control
else
set [running v] to (1) :: variables
reset timer :: control
set [started with v] to (seconds) :: variables
end
end
end
end
// ---- cooking ----
when program starts :: events hat
forever
if <(running) = (1)> then
set [left v] to ((started with) - (timer)) :: variables
write [COOKING] at line (1) :: display
write ([floor v] of ((left) / (60))) at line (3) :: display
write ((left) mod (60)) at line (4) :: display
set status light to [orange v] :: display
[A v] start motor at (30) % speed :: motors
if <not <[1 v] is pressed? :: sensors>> then
set [running v] to (0) :: variables
end
if <(left) < (0)> then
set [running v] to (0) :: variables
set [seconds v] to (0) :: variables
play sound [Communication / Goodbye v] until done :: sound
end
else
[A v] stop motor :: motors
set status light to [green v] :: display
write [SET TIME] at line (1) :: display
write ([floor v] of ((seconds) / (60))) at line (3) :: display
write ((seconds) mod (60)) at line (4) :: display
end
end- The buttons do nothing while it is running. A time changed mid-cook would be a time nobody confirmed.
- The confirm refuses, out loud, with a reason. Door open and time zero are different messages, because they need different fixes — Lesson 19.
- The door is checked continuously. Checking only at start would let somebody open it mid-cook with the turntable still turning.
- The remaining time is derived from the start value and the timer — never counted down in a variable, so it cannot drift. Lesson 31.
What success looks like: set 1:30 in a handful of presses, press start with the door open and be told to close it, close it, start, watch it count down and the turntable turn — and open the door mid-cook to stop it dead.
If one press adds twenty seconds, the debounce is too short. If the countdown jumps about, you are recomputing the start value inside the loop instead of capturing it once when Start was pressed.
Change it and test 8 min
One change at a time. Predict, then run, then look.
- Count the presses to reach 2:45. Then remove the fine buttons and count again. That difference is what coarse-and-fine is worth, measured.
- Make the value wrap instead of clamp so 300 rolls to 0. Hold Up and watch a user overshoot from five minutes to nothing. Then put the clamp back and say why a menu wraps and a number does not.
- Remove the door check from the cooking loop, leaving it only at start. Open the door mid-cook. The turntable keeps turning — an interlock checked once is not an interlock.
- Add a +30 seconds shortcut on the centre button that also starts it, exactly as a real microwave does. One press, common case handled.
- Count down in a variable instead of deriving it — subtract 1 each pass through the loop. Compare against a stopwatch for two minutes and see how far it drifts.
Count the presses for a realistic task. If it is more than about ten, the interface is the thing to fix.
Where this goes 3 min
Your microwave stops when the door opens — and everything it was doing is lost. Shut the door and it does not carry on; the time is back to what it was and you start again.
For a microwave that is arguably fine. For a machine part-way through winding two hundred turns of wire, it is not — stopping to fix something should not mean starting the whole job again.
A job that can be paused and resumed has to keep its progress somewhere the pause does not touch — and deciding what counts as progress is harder than it sounds. That is the next lesson.
Today the machine took an instruction. Next it remembers how far it got.