Runs Until You Stop It: The Ferris Wheel

What you are building 3 min

The Ferris Wheel: a tower standing on the Brick, a motor near the top, and a four-armed wheel carrying four coloured cars that stay upright as the wheel turns.

Every program you have written so far has had an ending built into it. Four rotations, then stop. Two seconds, then stop. A fairground ride does not work like that. It runs while the ride is open and it stops when somebody decides it should.

By the end you will have a ride that announces itself, turns slowly and steadily for as long as you choose, and stops on command — and you will know why deleting one block leaves it turning after the program has finished.

In the real world 5 min

Where you have seen it

The first Ferris wheel was built by George Ferris for the 1893 Chicago World’s Fair, as America’s answer to the Eiffel Tower. It carried more than two thousand people at a time. Every observation wheel since — including the ones you can ride in Kuala Lumpur — is a descendant of it.

Why it is built that way

Two things matter, and your model does both.

It turns slowly, with a lot of force. The motor spins quickly and weakly; the wheel must turn slowly and strongly, because it is lifting loaded cars the whole way up. Gears make that trade — you will find them on your own build in a moment.

The cars hang. They are not held level by clever engineering. They swing from a pivot, and gravity keeps them upright on its own, all the way round. Turn your wheel by hand and watch.

What would go wrong without it

Now the part that matters for the program. A real ride is not switched on for “six turns”. It runs while people are riding, and an operator ends it — early if somebody is unwell, later if the queue is short.

A machine whose stopping is decided by a counter cannot be stopped by a person. Some movements need an ending built in. Others need to run until something else says stop.

The main concept — two kinds of motor block 6 min

Until now every motor block you have used has been the same kind: you gave it an amount, it did that amount, and it finished. There is a second kind, and a fairground ride is what it is for.

[A v] run [clockwise v] for (4) [rotations v] :: motors

[A v] start motor [clockwise v] :: motors

start motor does not wait. The program runs straight on to the next block while the wheel is still turning — and the motor keeps going until a stop motor block says otherwise.

That is what lets a wait block set the length of the ride. Watch the rotation counter here: it climbs right through the wait, because the wait pauses the program, not the motor.

The ride also needs to be heard. Sound blocks come in the same two kinds, for the same reason — one holds the program until the sound has finished, one starts it and carries on.

▶One motor on and off, sound, and waitingThe full reference for all three — open it if start/stop, sound blocks or wait blocks are not clear yet.Show meHide

ComponentMotion4 min

One motor, on and off

Everything an EV3 does begins with a motor turning. Before worrying about how far or how fast, there are only two things to say to a motor: start and stop. The blocks are the same whichever motor you use — only the port letter changes.

Blocks reference

Block	What it does
[A v] start motor [clockwise v] :: motors	Starts the motor and immediately carries on to the next block. The motor keeps turning on its own.
[A v] stop motor :: motors	Stops the motor.
wait (2) seconds	Holds the program here, which is how you control how long a motor runs.

Start, wait, stop

Because start motor does not wait, a motor started on its own would run until the program ended. The pattern that gives a motor a length is three blocks:

when program starts :: events hat
[A v] start motor [clockwise v] :: motors
wait (2) seconds
[A v] stop motor :: motors

Read it aloud: start it, leave it two seconds, stop it. Change the wait and you change how far the motor gets.

Watch it run

The highlight below follows the block the Brick is running, and the shaft turns only while the program is between start motor and stop motor. Notice that the count keeps climbing all the way through the wait — the wait does not pause the motor, it pauses the program.

when program starts

A start motor clockwise

wait 2 seconds

A stop motor

0.00rotations so farnoshaft turning

The program begins. Both motors are still.The motor is told to start — and the program does not wait for it.The program is paused at the wait block. The motors are not: watch the count keep climbing.The motor is told to stop. The shafts stop wherever they had got to.Finished. The motor ran for about two seconds and stopped where it stopped.

▶ Play⏭ Step↺ Restartmotor stopped

The count does not pause when the program does. A wait holds up the blocks, and the motor carries on turning underneath it.

This is the whole idea behind start motor: it hands the motor its instruction and moves on, leaving the motor running behind it. Nothing stops the shaft until a block tells it to.

Which way is clockwise?

The direction dropdown says clockwise or counterclockwise — but clockwise seen from where? Always from the axle end: look straight at the shaft coming towards you, and clockwise is the way a clock’s hands go.

On the Medium Motor

Here the Medium Motor faces you, so its output axle points straight out of the page. This is the view to picture when you are choosing a direction.

when program starts :: events hat
[A v] start motor [clockwise v] :: motors
wait (2) seconds
[A v] stop motor :: motors

A Medium Motor normally lives in port A or D.

On the Large Motor

The Large Motor is shown from the side, which is the face its axle comes out of — so once again you are looking straight down the shaft.

when program starts :: events hat
[B v] start motor [clockwise v] :: motors
wait (2) seconds
[B v] stop motor :: motors

A Large Motor normally lives in port B or C. Compare the two programs: they are the same three blocks, and only A has become B.

Same blocks, different motor

Medium · port A

Large · port B

Why it matters

A fan, a conveyor belt or a spinning ride does not need to stop at an exact position — it just needs to run while something is happening. For those, timing the motor is simpler and perfectly good enough.

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.

ComponentControl4 min

Waiting

Waiting is how a program gives the physical world time to catch up. There are two kinds, and choosing between them is one of the first real design decisions in robotics.

Blocks reference

Block	What it does
wait (1) seconds	Holds the program for a fixed length of time, whatever else is happening.
wait until <>	Holds the program until a condition becomes true — usually a sensor reading.

One wait for every sensor

Most sensors bring their own ready-made wait block, already coloured to match the sensor and with its comparison built in. They are all the same idea — hold here until this is true — and they live in the sensor’s own palette rather than in Control.

Sensor	Block	Waits until
Touch	[1 v] wait until [pressed v] :: sensors	the button is pressed. The dropdown also offers released and bumped.
Colour	[3 v] wait until color is [red v] :: sensors	the surface underneath is that one of the eight colours.
Ultrasonic	[4 v] wait until distance [< v] (15) [cm v] :: sensors	something is nearer than 15 cm. Flip the dropdown to > to wait for something to move away.
Gyro	[2 v] wait until angle [< v] (45) :: sensors	the robot has turned past that angle.
Brick buttons	wait until [center v] button is [pressed v] :: sensors	somebody presses that button on the Brick. No port — it is built in.

When there is no ready-made block

Some readings have no wait block of their own — reflected light, ambient light, the timer, and a motor’s degrees counted. For those, drop the matching boolean into the plain wait until from Control. It does exactly the same job:

wait until <[3 v] is reflected light intensity [< v] (30) %? :: sensors>
wait until <[3 v] is ambient light intensity [> v] (50) %? :: sensors>
wait until <(timer) > (5)>
wait until <([A v] degrees counted :: sensors) > (720)>

This is also the way to wait for two things at once, which no ready-made block can do — the sensor blocks each take one condition, but a boolean can be combined:

wait until <<[1 v] is pressed? :: sensors> or <(timer) > (5)>>

That one says “stop waiting when the button is pressed, or after five seconds, whichever comes first” — which is how you stop a wait hanging for ever when the thing you are waiting for never happens.

Guessing, or knowing

Two robots, the same job: drive up to the wall and stop. One waits two seconds; the other waits for the wall. Let it run several times — the interesting part is what happens on the second and third run.

wait for a length of time

start moving straight: 0

wait 2 seconds

stop moving

wait for a condition

start moving straight: 0

4 wait until distance < 15 cm

stop moving

60cm left · timed60cm left · sensed1run

Timed: 60 cm — a different answer againSensed: 15 cm, as asked

Both robots start driving towards the wall.The left one is counting two seconds. The right one is watching the wall come closer.Both have stopped. Only one of them stopped somewhere it chose.Watch where the timed robot ends up on the next run, and the one after that.Finished — and it will bet again in a moment.

▶ Play⏭ Step↺ Restartboth stopped

Each orange dash is where a previous timed run finished. The sensing robot has never left a second mark, because it has never stopped anywhere else.

The timed robot is not being careless. Two seconds is a perfectly good guess, and on the first run it may look exactly right. But a second covers a different distance on a fresh battery, on a dusty floor, or with a heavier load, so the robot finishes somewhere new every run — sometimes short, sometimes into the wall. The sensing robot has never had to guess.

• wait () seconds is a guess. You are betting that two seconds is long enough. On a fresh battery, on a smooth floor, it might be — and then it is not.
• wait until is knowing. The robot carries on the moment the thing has actually happened, however long that takes.

Prefer waiting for a condition wherever a sensor can tell you. Keep timed waits for things with no sensor to check — letting a sound finish, or pausing so a person can watch.

Why it matters

A lift that waits three seconds for its doors is guessing; one that waits for the door sensor knows. The first eventually closes on somebody.

Say this back before moving on: “run for has its ending inside it. start motor has no ending, so I have to give it one.”

What’s in this build 4 min

Look at your model and find the parts with cables. Two again — a Brick and one motor doing all the work.

EV3 Brick × 1

Large Motor × 1

Count the gears — this is the interesting part

The motor does not turn the wheel directly. A small gear on the motor’s axle drives a 40-tooth gear on the wheel. Count the teeth on the small one yourself — it is a real number on your own model, and the whole behaviour of the ride follows from it.

If the small gear has 8 teeth, the motor turns five times for every single turn of the wheel. In exchange, the wheel gets roughly five times the turning force. That is the trade the ride needs: slow, smooth, and strong enough to carry four loaded cars up one side.

Try it by hand before switching on. Turn the small gear one full turn and watch how little the wheel moves. Then try to stop the wheel by holding a car — you will find it surprisingly hard to stop, and that is the extra force, not the motor.

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.

The motor sits high on the tower, so its cable has further to travel than in any build so far. Route it down the outside of a beam rather than through the wheel — a cable caught in a turning wheel will stop the ride and look exactly like a program fault.

Check your own build now:

1. Motor cable in port A — a letter, not a number.
2. Turn the wheel a full circle by hand. Does anything catch, rub or snag?
3. Do all four cars swing freely and hang level at every position?

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.

The Brick is the base of the tower now, so it is carrying the whole model. Give the cable enough slack that a tug on the laptop does not pull the ride over.

Confirm the connection 2 min

1. Check the Brick icon: connected, or not.
2. Check the port tiles. A motor on A, and nothing anywhere else.
3. Turn the wheel by hand and watch the tile’s degrees counted number move.

If the number does not move when the wheel does, stop here. The cable is in the wrong port or not pushed fully home.

Notice how much you have to turn the wheel to make that number move a long way. You are watching the gear reduction from the other end — the counter measures the motor, not the wheel.

Make it move 10 min

A full ride cycle in seven blocks: call the passengers, run the wheel gently for ten seconds, stop it, and sound the end.

when program starts :: events hat
play sound [Communication / Hello v] until done :: sound
[A v] set speed to (25) % :: motors
[A v] start motor [clockwise v] :: motors
wait (10) seconds
[A v] stop motor :: motors
play beep (60) for (0.5) seconds :: sound

Walk it in the order the Brick runs it:

1. play sound until done — the greeting finishes before anything turns, because this is the kind that waits.
2. set speed to 25 % — nothing moves. A ride is slow, and this is a ride.
3. start motor — the wheel begins turning, and the program moves straight on to the next block without waiting.
4. wait 10 seconds — this is the length of the ride. The wheel turns throughout; the program is simply standing still.
5. stop motor — the only thing in the program that ends the ride.
6. beep — so riders know it is over.

What success looks like: a greeting, then ten seconds of slow smooth turning with the cars hanging level, then a clean stop and a beep. If the wheel jerks or stalls on the way up, the speed is too low for the load, not too high.

Change it and test 8 min

One change at a time, and predict before each run.

1. Change the wait to 3 seconds, then 20. Predict how far the wheel goes each time. Notice what you are actually editing: the ride length lives in the wait block, not in any motor block.
2. Raise the speed to 60 %. Predict what happens to the hanging cars before you run it. Fairground rides are slow for a reason.
3. Now delete the stop motor block and run it. Predict first. The program finishes — and the wheel keeps turning, because nothing ever told it to stop.
4. Put it back, then swap start motor for run for 2 rotations. Predict what the wait does now. The wheel stops on its own, and the program then stands around for ten seconds doing nothing at all.

Steps 3 and 4 are the lesson, from both sides. A block with no ending needs one supplied; a block with an ending built in ignores the one you supply.

If the wheel refuses to start turning, try a higher speed before you suspect the program. A geared-down wheel carrying four cars needs a real push to get going, and 10 % may not be enough to move it at all.