EV3 Robotics›Level 3 · Advanced›Lesson 3
Level 3 · Lesson 3 · EV3-L03-0360 minutes · Ages 9–16 · Model: Water Conveyor
The Water Conveyor: a chain of scoops that lifts water — or in your case, small parts — from a low tank to a high one, driven by two Large Motors that must turn as one.
It is the first model in Level 3 with more than one thing happening at once. The belt runs. A trip switch watches the hopper. A distance sensor watches the tank filling. None of those three should have to wait for the others.
By the end of the lesson one part of your program will announce that something happened, and two other parts will react to it — without any of them checking the sensor themselves.
A bucket-chain conveyor is one of the oldest machines still in daily use. The Egyptians moved irrigation water with one; a modern grain elevator, a cement works and a flood-defence pumping station all use the same idea — a loop of scoops on a belt, picking up at the bottom, tipping out at the top.
What has changed is what surrounds it. A modern installation has a level probe in the upper tank, a trip on the hopper, an overload sensor on the drive and an alarm in a control room. The belt does not know about any of them. It is simply told to start, and told to stop.
Because a plant is not one machine — it is a lot of machines that need to agree about when things happen. In an industrial control system the level probe does not reach into the motor and switch it off. It raises a signal — “tank full” — and everything that cares about a full tank does its own thing: the belt stops, the alarm sounds, the log records it.
The signal has a name, and the name is the interface. The probe does not know who is listening, and it does not need to. You can add a fourth thing that reacts to a full tank without touching the probe at all.
If every part had to watch the probe itself, you would have four copies of the same watching, drifting apart over the years — and the day the probe moved to a different terminal, four separate things would need fixing, and someone would miss one.
Announce the moment once. Let everyone who cares listen for it.
A broadcast is a message with a name. One stack sends it; every stack with a matching when I receive hat starts running. The sender does not know who is listening, and does not wait.
when program starts :: events hat forever wait until <[1 v] is pressed? :: sensors> [A v] start motor at (40) % speed :: motors end when program starts :: events hat forever wait until <[1 v] is pressed? :: sensors> play sound [Boing v] :: sound end
The duplication is in the detecting, not the doing. The day the trip becomes an Ultrasonic Sensor instead of a switch, you edit both stacks. Miss one and half the machine reacts to the old sensor.
when program starts :: events hat forever wait until <[1 v] is pressed? :: sensors> broadcast [load arrived v] :: events wait until <not <[1 v] is pressed? :: sensors>> :: control end when I receive [load arrived v] :: events hat [A v] start motor at (40) % speed :: motors when I receive [load arrived v] :: events hat play sound [Boing v] :: sound
| My Block (Lesson 1) | Broadcast (today) | |
|---|---|---|
| Names a… | routine — a thing to do | moment — a thing that happened |
| How many can respond? | One definition | Any number of listeners, including none |
| Does the caller wait? | Yes — the program continues after the block has finished. | No. It shouts and carries straight on. |
| Use it when… | the same job is needed in several places | one event should set several unrelated things going |
Notice the second wait until in the watcher. Without it, a switch held down for half a second broadcasts dozens of times. Waiting for the release means one press makes one announcement — this is Level 2’s edge detection (Lesson 38), earning its keep.
A broadcast lets one stack tell another to start. The sender does not need to know who is listening — it announces, and any stack waiting for that message runs.
| Block | What it does |
|---|---|
broadcast [message1 v] :: events | Sends the message and carries straight on. |
broadcast [message1 v] and wait :: events | Sends the message and holds until every stack that received it has finished. |
when I receive [message1 v] :: events hat | Starts this stack whenever that message is sent. |
Both send the same message to the same stack. The difference is what the sender does next — which is invisible in a listing, because the two blocks sit in exactly the same place. Use the switch to try each one.
the sensor stack
the motor stack
The sender never names the receiver — it announces, and whoever is listening runs. That is what lets the motors keep exactly one owner.
Plain broadcast is the right choice when the two jobs are genuinely independent: announce it and get on with your own work. broadcast and wait is the right choice when what comes next depends on the receiver having finished — do not start reversing until the stack that stops the motors has actually stopped them.
Broadcasting splits a program into parts that each do one job. A stack that watches the sensors can announce obstacle; the stack that owns the motors reacts. Neither needs to contain the other’s code, and the motors still have exactly one owner.
Here is a driving base doing exactly that. Three stacks are running: one sets the wheels going, one does nothing but read the Ultrasonic Sensor, and one owns every movement from then on. Follow the distance rather than the wheels — and notice what it is still doing while the message is crossing.
the driving stack — sets it going, then it is done
the watching stack — no motor block in it at all
the motor stack — owns every movement after the start
Watch the distance at the moment the message is sent. It keeps falling, because a broadcast starts another stack — it does not stop this one.
The watching stack contains no motor block anywhere, and the motor stack never reads the sensor. That is the whole trick: each stack is short enough to hold in your head, and the message is the only join between them. Splitting it this way also means the base can be made to dodge left instead of right by editing four blocks in one place, without going anywhere near the sensor.
Watch the gap in the middle of the run. broadcast does not mean stop — the wheels keep turning right through it, and the base creeps another 3 cm closer before the receiving stack gets as far as its stop moving block. If a robot must halt on the spot, that gap is why it will not.
Any number of stacks can listen to the same message, so one announcement can set several things going at once — stop the motors, sound an alarm and turn the light red. And nothing in the sending block says which of those will happen. Press one and find out.
Press a broadcast block. Nothing in it says what will happen — the stack that receives it decides.
Nothing has been sent yet. Press one of the three yellow blocks above.
Three messages, three receivers, one Brick. The blocks you press are identical apart from the name in the dropdown — so whatever happens next was decided entirely by the when I receive stack at the other end. Press all three quickly: nothing queues, because three separate stacks run at the same time. Press the same one twice while it is still going and its stack starts again from the top.
A message called message1 tells a reader nothing. One called obstacle-found explains the whole design at a glance. Names matter more here than almost anywhere else, because the sender and the receiver may be far apart on screen.
A program does not have to be one long column of blocks. Several stacks can run at the same time, each doing its own job — one driving, one watching a sensor, one keeping the display up to date.
Give each stack its own hat block. Every stack beginning with when program starts starts at the same instant — not one after another — and from then on they run alongside each other.
Nor is it limited to two. Below, three stacks run together: a Medium Motor turning an attachment, the status light flashing, and the drive base rolling. Watch the arrows at the top — they all begin at once, and no stack waits for any other.
when program starts :: events hat [A v] start motor [clockwise v] :: motors when program starts :: events hat forever set status light to [green v] :: display wait (0.5) seconds set status light to [red v] :: display wait (0.5) seconds end when program starts :: events hat start moving [straight: 0] :: movement
Written down they have to go one under another, because a page is a column — but that is an accident of paper. On the Brick they sit side by side, and nothing in the first stack happens before anything in the third.
Parallel stacks go wrong when two of them try to control the same thing. Use the switch below to take the wheels away from the third stack and point it at motor A, which the first stack is already driving.
the program starts — all of these begin here
stack 1 · Medium Motor
stack 2 · status light
stack 3 · drive base
Every stack is highlighted at the same moment on purpose — that is what running in parallel looks like. The switch above changes only what the third stack controls.
With one owner each, all three stacks are highlighted at the same instant and all three jobs get done. With two owners, motor A is handed contradictory orders hundreds of times a second and shivers instead of turning — and notice the second cost, which is easy to miss: the wheels now have nobody driving them. A stack that goes to fight over someone else’s motor has abandoned its own job. Nothing reports an error either way; as far as the Brick is concerned every stack is working perfectly. The same happens to a display line or a variable that two stacks both write to.
The discipline is simple: give each stack sole ownership of what it controls. One stack owns the motors, another owns the screen, another watches the sensors and tells the others what it found — which is what broadcasting is for.
A broadcast separates deciding that something happened from reacting to it — and lets you change either one alone.
A program does not have to be one long column of blocks. Several stacks can run at the same time, each doing its own job — one driving, one watching a sensor, one keeping the display up to date.
Give each stack its own hat block. Every stack beginning with when program starts starts at the same instant — not one after another — and from then on they run alongside each other.
Nor is it limited to two. Below, three stacks run together: a Medium Motor turning an attachment, the status light flashing, and the drive base rolling. Watch the arrows at the top — they all begin at once, and no stack waits for any other.
when program starts :: events hat [A v] start motor [clockwise v] :: motors when program starts :: events hat forever set status light to [green v] :: display wait (0.5) seconds set status light to [red v] :: display wait (0.5) seconds end when program starts :: events hat start moving [straight: 0] :: movement
Written down they have to go one under another, because a page is a column — but that is an accident of paper. On the Brick they sit side by side, and nothing in the first stack happens before anything in the third.
Parallel stacks go wrong when two of them try to control the same thing. Use the switch below to take the wheels away from the third stack and point it at motor A, which the first stack is already driving.
the program starts — all of these begin here
stack 1 · Medium Motor
stack 2 · status light
stack 3 · drive base
Every stack is highlighted at the same moment on purpose — that is what running in parallel looks like. The switch above changes only what the third stack controls.
With one owner each, all three stacks are highlighted at the same instant and all three jobs get done. With two owners, motor A is handed contradictory orders hundreds of times a second and shivers instead of turning — and notice the second cost, which is easy to miss: the wheels now have nobody driving them. A stack that goes to fight over someone else’s motor has abandoned its own job. Nothing reports an error either way; as far as the Brick is concerned every stack is working perfectly. The same happens to a display line or a variable that two stacks both write to.
The discipline is simple: give each stack sole ownership of what it controls. One stack owns the motors, another owns the screen, another watches the sensors and tells the others what it found — which is what broadcasting is for.
Say this back before moving on: “One shouts. Anyone who cares listens.”
Find the four electronic parts, and work out which two are watching rather than doing.
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | The control room. It runs three stacks at once today. |
| Large Motor ×2 — the belt | A synchronised pair, as in Level 2 Lesson 6. A conveyor driven from both ends at slightly different speeds will fight itself and shed the belt. |
| Touch Sensor — the hopper trip | Says a load has arrived at the bottom. It decides — it does not drive anything directly. |
| Ultrasonic Sensor — the level check | Watches how full the top tank is by measuring the distance down to what is in it. Closer means fuller. |
| The scoop chain (not electronic) | Run it round by hand a full lap. A scoop that catches on the frame will stall a motor mid-broadcast, which looks like a program fault and is not one. |
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 |
|---|---|---|
| Belt drive (Large) | A and D | The outer motor ports, because the two ends of the conveyor are far apart and the cables have to reach. |
| Hopper trip (Touch) | 1 | Touch stays on 1 across the whole course. |
| Level check (Ultrasonic) | 4 | Ultrasonic stays on 4, as it did in Level 2 — so a distance program moves between models unedited. |
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.
USB is the sensible choice here. The conveyor stays put on the table, and today you will download many small changes in quick succession — three stacks means three things to get wrong, and a cable downloads faster than a pairing.
Stuck? The long version, with a photograph of every screen, is in the Brick & Bluetooth guide.
Three stacks. One watches the hopper and announces; one runs the belt; one keeps the screen honest.
when program starts :: events hat clear display :: display write [READY] at line (1) :: display forever wait until <[1 v] is pressed? :: sensors> broadcast [load arrived v] :: events wait until <not <[1 v] is pressed? :: sensors>> :: control end when I receive [load arrived v] :: events hat write [LIFTING] at line (1) :: display [A v] start motor at (40) % speed :: motors [D v] start motor at (40) % speed :: motors wait until <([4 v] distance in cm) < (10)> :: control [A v] stop motor :: motors [D v] stop motor :: motors write [TANK FULL] at line (1) :: display when I receive [load arrived v] :: events hat play sound [Communication / Hello v] :: sound set status light to [orange v] :: display
wait until distance < 10 is the level probe. Use the two numbers you noted a moment ago and pick something between them.What success looks like: press the trip once — a sound plays, the light goes orange, the belt runs, and it stops by itself when the top tank fills.
If the belt restarts by itself, your watcher is broadcasting continuously because you left out the wait-for-release. One press should make exactly one announcement.
One change at a time. Predict, then run, then look.
when I receive [load arrived] hat that writes the time on line 5. Notice what you did not have to edit to add it.load arrived in the watcher to banana. Nothing happens, and nothing errors. This is worth seeing once: a misspelled broadcast fails silently.Adding a reaction should cost one hat block. If it costs you a copy of the detecting, the announcement is in the wrong place.
There is something a broadcast deliberately does not do: it does not wait.
Your watcher shouts load arrived and immediately goes back round its loop to watch for the next press — even though the belt is still running. Most of the time that is exactly right. Sometimes it is precisely wrong: if the next step must not begin until the belt has finished, a shout that carries on regardless will start it too early.
There is a second block, broadcast … and wait, that holds the sender until every listener has finished. Choosing between them is the whole of the next lesson, and choosing wrongly is one of the harder bugs to see.
Lesson 1 named a routine. Lesson 2 gave the name a slot. Today named a moment. Tomorrow: does the announcer wait?
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.
Add a third listener. Write a new stack with a "when I receive load arrived" hat that shows the word LOADING on line 3 and turns the status light orange. Count how many existing stacks you had to edit to add it. The answer should be zero.
Add a second announcement. When the top tank fills, broadcast "tank full" instead of just stopping the belt. Then write two listeners for it: one stops the belt, one plays an alarm and writes TANK FULL. Now the belt stack no longer decides anything — it only reacts. Every decision in your program lives in exactly one place.
Two different trips, one announcement. Add a second way for a load to arrive: as well as the Touch Sensor, the Ultrasonic Sensor seeing something within 8 cm should also count. Both must broadcast the SAME message, and everything downstream must be untouched. This is the test of whether your announcement is in the right place.
Run the conveyor as a plant, not a machine. Build a program with these separate concerns, each in its own stack, and no stack allowed to check a sensor that is not its own business: - a watcher for the hopper trip - a watcher for the tank level - the belt, which only reacts to messages - a display that always shows what the plant is doing - an alarm that reacts to anything abnormal Then prove it: swap the hopper trip from the Touch Sensor to the Ultrasonic Sensor by editing exactly ONE stack. If you have to edit two, the design is wrong and it is worth finding out why before you rebuild it.
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.