EV3 Robotics›Level 1 · Beginner›Lesson 20
Level 1 · Lesson 20 · EV3-L01-2060 minutes · Ages 9–16 · Model: Stone Grinder
The Stone Grinder: a heavy round stone turning slowly on an axle, driven by a Large Motor — the same machine people have used to grind grain for thousands of years.
It is the heaviest thing you have asked a motor to turn. That is deliberate: a millstone is supposed to be heavy, because weight is what does the grinding.
And a grinder raises a question none of your models has raised before. Not what should it do, or how far — but how long. Grind for too short a time and the grain is gritty; too long and you are wasting the day. Today the robot gets a clock.
Two flat stones, one turning on the other, with grain fed in between. It is one of the oldest machines there is, and it has not gone away — a batu giling is still how many Malaysian kitchens grind spices for rempah, and the same idea at industrial scale still mills flour today.
The stone is heavy on purpose. Grinding needs pressure and it needs the stone to keep going when it meets a hard grain — and a heavy wheel, once turning, is very hard to stop. That stored motion is called momentum.
Which means the difficult moment is the start. Getting a heavy stone moving from standing still takes far more effort than keeping it going. Watch anyone use one by hand: the first push is a shove, and after that it is a rhythm.
Now think about running it. “Grind for two minutes” is a real instruction — a miller works to time, not to a number of turns, because what matters is how long the grain has spent under the stone.
And there is a second reason a machine needs a clock, which has nothing to do with grinding. If a machine is told to wait for something that never happens, it waits for ever. No error, no message, no clue. A clock is how it gives up.
A robot that cannot measure time can only be told what to do. One that can measure time can report, and can give up.
The Brick has a clock running the whole time. Two blocks let your program use it.
| Block | What it does |
|---|---|
reset timer | Sets the clock back to zero. Everything after this is measured from here. |
(timer) | Reports the seconds since the last reset. It is a number, so it fits anywhere a number fits — in a comparison, or in a write block. |
You have used wait (10) seconds since Lesson 4. It is simpler than the timer, and it is genuinely the right block most of the time. The difference is what each one can do:
| wait (10) seconds | the timer | |
|---|---|---|
| Pauses the program | Yes, that is all it does | No — it just keeps counting |
| Can you read the number? | No | Yes, any time you like |
| Can other things happen meanwhile? | No | Yes — the motor can be running |
That last row is why the grinder needs it. A wait would stop the program dead, and the program is the only thing that can turn the motor off at the end.
no way out
with a timeout
The sensor is not faulty and the program is not wrong. There is simply no wall, and only one of these two programs has a way of noticing that.
The demo shows the timer’s other job, and the more valuable one: escaping a wait that will never end. The left-hand robot is not broken. It is doing exactly what it was told, and it will be doing it tomorrow.
A wait tells the robot to do nothing for a while. The timer lets the robot know how long it has been doing something.
A wait pauses for a length of time. The timer is different: it runs in the background and can be read at any moment, so the robot can know how long something has taken while it is still happening.
| Block | What it does |
|---|---|
(timer) | Reports the seconds since the timer was last reset. |
reset timer | Sets it back to zero, so the next reading counts from here. |
The most valuable use of a timer is escaping a wait that might never end. A robot told to drive until it sees a wall will drive for ever if the wall is not there. Combined with a timer, it can give up:
Repeat until the wall is close or five seconds have passed. That one change turns a program that can hang into one that always finishes. Both robots below are looking for a wall that is not there.
no way out
with a timeout
The sensor is not faulty and the program is not wrong. There is simply no wall, and only one of these two programs has a way of noticing that.
The left-hand robot is not broken, and neither is its sensor. Its condition is simply one that will never come true, so the program sits on that block for ever — with nothing on the Brick to say so. The right-hand program asks the same question with an escape route bolted on, and finishes every time.
Real systems time themselves out constantly — a lift that cannot close its doors eventually gives up and beeps rather than trying for ever. A robot with no timeout simply stops responding, and there is nothing on screen to say why.
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| 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. |
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.
and on the Large Motor, only the port changes
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.
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.
The blocks are identical apart from the port letter, so swapping one motor for the other is a build change, not a programming change.
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: “Reset the timer to start counting, and read the timer to find out how long it has been.”
Two electronic parts — and this time the heaviest part of the model has no cable at all.
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Runs the program, keeps the clock, and shows the reading on its screen. |
| Large Motor | Turns the stone. The strong one — and this is the model that most obviously needs it. Check yours has the big red drum. |
| The stone (no cable) | The heavy wheel. Its weight is the whole point of the machine, and it is also what makes starting hard. |
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 |
|---|---|---|
| Large Motor (turns the stone) | A | A single working motor takes A, as it has all course. |
| The clock | none | The timer is not a part. It is inside the Brick, running already, and there is nothing to plug in or wire up. |
Check your own build now:
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.
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.
EV3 until somebody changes it.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.
Bluetooth suits this one. The stone throws whatever you feed it about a bit, and a cable trailing across the table is one more thing to catch.
There is no tile for the timer, and there does not need to be. It is already running — it has been since the Brick switched on. Your program does not start it, it only resets it.
Seven blocks. Start the clock, start the stone, let it run for fifteen seconds, stop, and report how long it actually took.
when program starts :: events hat reset timer [A v] set speed to (60) % :: motors [A v] start motor [clockwise v] :: motors wait until <(timer) > (15)> [A v] stop motor :: motors write (timer) at line (1) :: display
Walk it in the order the Brick runs it:
What success looks like: a stone that takes a moment to get going, turns steadily for about fifteen seconds, stops being driven, coasts to a halt, and leaves a number on the screen a shade above 15.
If the stone will not start at all, do not raise the speed — that does not help a stall. Check the stone spins freely by hand first, then check the tile really says Large Motor.
One change at a time, and predict before each run — and today, predict the number on the screen, not just the behaviour.
Step 5 is the honest limit of a timer, and worth saying plainly: it tells you how long you waited, not whether anything worked. A machine can report a perfect fifteen seconds of doing absolutely nothing.
Measuring time is not the same as measuring progress. The clock is honest about the clock and nothing else.
Work through the challenges in order — each is harder than the last. The mission comes after all three, and it is meant to make you plan before you build.
Grind to time and report honestly. Run the stone for exactly thirty seconds and show the measured time on the screen at the end. Then explain why your number is not exactly 30 — and say whether it is over or under, and why it could never be under.
Time the coast. Measure how long the stone keeps turning after the motor stops, using the timer rather than a phone. Do it three times at three different speeds and report all three. Then say what that tells you about the stone's momentum.
Build a timeout. Make a program that waits for something that will not happen — the centre button being pressed, say — but gives up after ten seconds and reports that it gave up, rather than hanging for ever. Show both outcomes: one where you press it in time, one where you do not.
Make a grinder that reports on its own work. Your machine must run a grinding cycle you designed, and afterwards tell somebody what happened: how long it ran, and whether it finished properly or was cut short. Nobody may touch it during the run, and nobody may use a stopwatch — the machine measures itself. Plan on paper before you build. Work out what your machine can genuinely know about its own run, and be careful here: the clock tells you how long you waited, not whether anything actually turned. Two questions when you demonstrate it. Could your machine report a perfect run while the stone was jammed and motionless — and if so, what would you need to fix that? And why is reset timer the first block rather than the second?
Build the model before you read any further. Everything after this is about making it do something, and none of it will make much sense with nothing on the table in front of you.
Use the viewer's own controls to zoom and turn pages. Fullscreen makes it big enough to build from.
Check the finished build against the picture before you switch anything on. A motor mounted the wrong way round is far easier to spot now than it is to debug later, when it looks like a program fault.
