Inside the Loop or Under It: The Wipers

What you are building 3 min

The Wipers: a motor geared to an arm that sweeps across and back, across and back, exactly like the pair on a car’s windscreen.

It is a small build and a quick one. What makes it worth a whole lesson is that a wiper is the first machine you have met whose entire job is repetition — not one sweep, but the same sweep for as long as it is raining.

You have used repeat since the Stegosaurus in Lesson 7. Today you find out something about it that catches almost everybody: a block can be in your program, spelled perfectly, sitting in the right order — and never run at all.

In the real world 5 min

Where you have seen it

Every car has them, and in Malaysia they earn their keep. A tropical downpour can drop more water in ten minutes than some countries see in a month, and a windscreen goes from clear to useless in about two seconds.

Why it is built that way

A wiper arm does not spin. It sweeps out and back through an arc, because the glass has edges and the driver’s view is a fixed shape. Inside the mechanism a motor does spin, all the way round, and a linkage converts that turning into a back-and-forth sweep.

The gearing matters too. Look at your model: a small gear on the motor driving a big one on the arm. That is geared down — slower, but strong enough to drag a rubber blade across wet glass, which takes more force than you would think.

What would go wrong without it

Now the part that concerns the program. A wiper that sweeps once is useless. Rain does not stop after one wipe.

And a wiper that sweeps a hundred times but only clicks its motor once, at the very end, is a machine whose feedback has come adrift from what it is doing. Whatever the wiper does per sweep has to happen per sweep — not once when everything is over.

“Every time round” and “once at the end” are different behaviours, and in a block program the only thing that tells them apart is where the block sits.

The main concept — the loop’s mouth 6 min

A loop block is not a line. It is a C shape with a mouth, and blocks go either inside the mouth or underneath the whole thing. Those two places behave completely differently.

That last row is the one that costs people an afternoon. The block is there. It is correct. It will simply never run, and nothing on the Brick will tell you so — no error, no warning, no red mark. The program is doing exactly what you built.

Both programs in that demo end with the same block. Only one of the rings ever lights, and the difference between them is not a spelling mistake or a wrong number — it is two studs of indentation.

Before you blame a block, check whether it is inside the loop or under it. Under a forever loop is a place where blocks go to be ignored.

▶Repeating, and soundThe full reference for loops and for the sound blocks this lesson uses. Open either if it is not clear yet.Show meHide

ComponentControl5 min

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.Pass 1.Pass 2.Pass 3 — and repeat (3) has now done its three.The left program carries on to the block underneath and sets its light green. The right one has jumped back to the top of the loop, and it always will.The left program has finished. The right program has not, and will not.

▶ Play⏭ Step↺ Restartstarting

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:

1. Read the sensor.
2. Decide what that reading means.
3. Act on the motors.
4. 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
end

Read 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.The right-hand program has already finished. One if/else, checked once, and there were no more blocks after it — the program ended in a few milliseconds.Press the button. The looped program comes round, checks again, sees `pressed`, and starts the motor. The finished program cannot: it is not running.Release. The looped program comes round again and stops the motor. The other one has not looked at the sensor since the instant it started.Press again, and again. Every pass round the loop is another check — that constant read, decide, act is what a closed loop IS.Finished. The looped program answered the button every time. The other answered it once, before anybody had touched it.

▶ Play⏭ Step↺ Restartbutton released

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.

ComponentOutput5 min

Sound and beeps

The Brick has a small speaker. It can play one of the built-in sound files, or beep a note you choose. Sound is what makes a machine feel finished — and it is also a way for the robot to tell you something without you having to look at it.

Blocks reference

Block	What it does
play sound [Communication / Hello v] until done :: sound	Plays the sound and waits for it to finish before the next block runs.
start sound [Communication / Hello v] :: sound	Starts the sound and moves straight on to the next block, so the sound plays while the robot keeps working.
play beep (60) for (0.5) seconds :: sound	Plays a single note for a set time — useful for short alerts. The number is a note, not a volume: bigger means higher.
set volume to (100) % :: sound	Sets how loud everything after it will be. Worth putting at the top of a program — the Brick remembers the last volume it was given, even from somebody else’s program.
stop all sounds :: sound	Cuts off anything that is still playing, including a long sound started earlier.

Wait for it, or not

These two blocks play the very same file. The difference is what the rest of the program does while it plays — so it cannot be heard on its own, only seen. Here are both, each lifting a barrier.

play sound until done

when program starts

play sound Communication / Hello until done

A run clockwise for 1 rotations

start sound

start sound Communication / Hello

A run clockwise for 1 rotations

0.0suntil done0.0sstart sound

until done: warn first, then movestart sound: warn while moving

Two programs. Same sound, same movement — only the sound block is different.The sound is playing on both. On the left the program is waiting for it, so the barrier has not moved. On the right the barrier is already lifting.The sound has finished. Only now does the left barrier lift — the right one finished a moment ago, sound and movement together.Both played the warning and both lifted the barrier. One took twice as long to do it.Finished. Neither program is wrong — they are answers to two different questions.

▶ Play⏭ Step↺ Restartstopped

Watch the barriers, not the clock. On the left the warning finishes before anything moves; on the right it sounds while the barrier lifts.

The bars underneath are when the speaker was on and when the motor was turning. On the left they never overlap: the program is stuck at the sound block until the file has finished, and only then does the barrier lift. On the right they overlap almost completely, and the whole job is done in half the time.

• play sound until done — everything stops and waits. Use it for a warning that must be heard before something moves.
• start sound — the sound and the movement happen together. Use it when the noise belongs to the movement, like a motor whirring as an arm lifts.

Why it matters

Real machines warn before they move, not after: a lift chimes before the doors close, a reversing lorry beeps while it rolls back, a level crossing sounds before the barrier drops. Getting the order right is the difference between a warning and an apology.

Say this back before moving on: “Inside the mouth means every time round. Under the loop means afterwards — and after a forever loop there is no afterwards.”

What’s in this build 4 min

Two electronic parts, and a gear pair doing quiet work.

Find the sweep, by hand

Brick off. You need to know the arc before you can program it.

1. Move the wiper arm gently by hand to one end of its travel. Stop at the first resistance.
2. Move it to the other end. That arc is your sweep.
3. Now turn the motor drum instead and watch the arm. Because the pair is geared down, the drum turns much further than the arm does — so the number in your program will be bigger than the arc you just measured.
4. Roughly how many turns of the drum for one full sweep? Write it down.

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 cable in port A — a letter, not a number.
2. Park the arm in the middle of its sweep before you start, so the first movement has room in both directions.
3. Turn the drum a full turn. Smooth all the way round? A tight spot means the gears are jammed together too hard.
4. Volume up on the Brick — this lesson has a sound in it.

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.

Today USB is genuinely handy. This lesson involves a forever loop on purpose, and a program that never ends is one you will want to stop from the computer.

Confirm the connection 2 min

1. Check the Brick icon: connected, or not.
2. Check the port tiles. A Medium Motor on A, nothing on the numbered ports.
3. Sweep the arm from one end to the other by hand and read degrees counted. That is the motor’s travel for one sweep — a much bigger number than the arm’s own arc, because of the gearing.
4. Take a little off it, so the arm stops just short of its stops rather than banging into them ten times in a row.

Make it move 10 min

Six blocks, and three of them are inside the loop’s mouth. Use your own measured number in place of the 90.

when program starts :: events hat
[A v] set speed to (40) % :: motors
repeat (10)
  [A v] run [clockwise v] for (90) [degrees v] :: motors
  [A v] run [counterclockwise v] for (90) [degrees v] :: motors
  play sound [Information / Blip 1 v] until done :: sound
end

Walk it in the order the Brick runs it:

1. set speed to 40 % — outside the loop, above it, so it happens once. It does not need repeating: the speed stays set.
2. repeat (10) — everything held in the mouth below runs ten times.
3. run clockwise for 90 degrees — the sweep out.
4. run counterclockwise for 90 degrees — the sweep back, equal and opposite, so the arm does not creep.
5. play sound until done — the click at the end of each sweep. Inside the mouth, so it happens ten times.

Look at step 1 next to step 5. Both are single blocks; one is above the loop and one is inside it, and that is the only difference between “once” and “ten times”.

What success looks like: ten even sweeps with a click at the end of each, the arm finishing where it started, and no banging at either end of the arc.

Change it and test 8 min

Most of today’s changes move a block rather than change a number. Predict before each run — say out loud how many times you expect to hear the sound.

1. Drag the sound block out of the mouth and drop it underneath the loop. Predict the number of clicks. It is one, at the very end, and the wiper now sweeps in silence.
2. Put it back inside, and now drag the set speed block into the mouth. Predict whether anything changes. It should not — the same value is being set ten times, which is harmless and pointless.
3. Now change that in-loop speed block so it reads set speed to (100) % and put it between the two motor blocks. The wiper now sweeps out slowly and snaps back fast, which is not far off how a real wiper feels.
4. Tidy up, then swap repeat (10) for forever. Add a play sound block underneath the loop. Predict when you will hear it.
5. Run step 4 and wait. It never plays. Stop the program from the computer — that is the only way this one ends.

Step 5 is the one to carry with you for the rest of the course. Nothing is broken and nothing is misspelled. There is simply no after for that block to happen in.

A block that never seems to run is nearly always this. Check the loop before you check anything else — it is faster than re-reading the block you are sure about.