Repeating

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

repeat (10)
end

forever
end

repeat until <>
end

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.

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.

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.