Continuous Processing: Forever Loops
Learning Objective
Understand infinite loops. Use the Forever mode to build repeating patterns, learn how a running rule locks the output it controls, and discover what happens when two rules fight over the same component.
Theory: The Loop That Never Ends
What Is a Forever Loop?
Last week you built a No Loop rule — a one-shot that runs its steps once and stops. This week we remove the brakes.
A Forever rule repeats itself endlessly. It works through its steps from top to bottom, and the instant the last step's delay finishes, it jumps straight back to step 1 and starts again. There is no pause and no gap. In computer programming this is called an infinite loop, and it is one of the most fundamental structures in all of software.
Select Forever when the complete step sequence must restart immediately after it finishes.
Your own body runs plenty of infinite loops. Your heart beats, pauses, beats, pauses — and never asks permission to continue. Your lungs do the same. A Forever rule is the MakerBuddy's heartbeat.
Forever vs. No Loop vs. Timer
Three of the four modes now make a neat family. The difference is entirely about what happens after the last step:
| Mode | After the last step it… | Result |
|---|---|---|
| ⏹️ No Loop | …stops. | Runs once. |
| ♾️ Forever | …restarts immediately. | Runs non-stop, no gap. |
| ⏱️ Timer | …waits for your interval, then restarts. | Runs on a schedule (Week 25). |
Making Patterns, Not Just States
Here is the clever part. Because a Forever rule loops over all its steps, you can build a repeating pattern instead of just holding one output on. A two-step rule that switches the LED on and off becomes a blinker. A three-step rule cycling RGB colours becomes an animation.
Remember the golden rule from last week: the delay belongs to the step above it. The 500 ms on step 1 is how long the light stays on.
The Locked Output
A Forever rule never finishes — which means it is always in charge of the component it is driving. While it runs, it locks that output. If you go back to the dashboard and try to switch the LED off by hand, the rule will simply set it again on its next pass, and your change vanishes within milliseconds.
This is not a bug. It is exactly what you want from a safety siren: nobody should be able to casually switch it off from a web page. But it does mean there is only one way to take back manual control — Stop, Disable, or Delete the rule from its card in the Rule Engine.
Halts the rule now. It stays saved and you can Start it again later.
Switches the rule off, including at the next power-on. Still saved.
Removes it from the board completely and frees one of your 10 rule slots.
Only the Component in Use Is Locked
A rule locks only the component its current step is touching — not everything on the board. A Forever rule blinking the LED does not stop you from moving the servo by hand, or from running a second rule on the buzzer. This is what makes it possible to run several rules side by side without them getting in each other's way, as long as each one owns different components.
Where Forever Sits in the Priority Order
Recall the priority order from Week 21:
Forever sits third. So a Forever rule will happily override a No Loop rule — but a Condition or Timer rule will take a component away from Forever whenever it needs it. Understanding this ordering now will save you a lot of confusion in Term 4, when your projects start running four or five rules at once.
For Teachers
The "locked state" is the memorable moment of this lesson — let students discover it by frustration rather than telling them first. Have them build the Persistent Beacon, then challenge them to switch the light off from the dashboard. After a minute of failed clicking, ask: "Is this a bug or a feature? Name a real machine where you would want exactly this behaviour." Emergency stops, fire alarms and aircraft warning lights all work this way.
Real-World Applications
Forever loops are everywhere once you start looking for them:
A siren that must blast non-stop until an operator physically resets it.
Aircraft warning lights and lighthouses flash the same pattern all night long.
Shop-window colour cycles and status LEDs that breathe in and out.
Activity: The Persistent Beacon
Let's build a light that refuses to turn off, then upgrade it into a flashing beacon.
Part A — The Light That Won't Die
- Open the Rule Engine and add a new rule named PersistentLight.
- Loop Mode: choose ♾️ Forever.
- Step 1: Action → LED On, Value → 255, Delay → 100.
- Save the rule. The LED turns on.
- The test: go back to the Dashboard tab and try to switch the LED off with the manual toggle. What happens? 👀
What happened? The light snaps back on almost instantly, because the Forever rule reaches step 1 again and re-applies it. The output is locked. Press Stop on the rule card to take back control.
Part B — Turn It Into a Beacon
- Edit your PersistentLight rule (or create a new one called Beacon).
- Step 1: Action → LED On, Value → 255, Delay → 500.
- Add Step 2: Action → LED Off, Delay → 500.
- Save and watch. The LED now blinks once per second and will keep doing so indefinitely.
- Experiment: change both delays to 100. What happens to the blink speed? Now try 2000.
Remember: the smallest delay the dashboard accepts is 100 ms. If Save refuses to work and a box turns red, that is why.
Challenge: The Dual Rule Clash
What Happens When Rules Fight?
You now know a Forever rule owns its output. But what if two Forever rules both try to control the same component, and give it opposite instructions? Neither one outranks the other — they are the same priority. Let's find out.
- Create a Forever rule named BuzzOn: Action → Buzzer On, Delay → 100. Save it.
- Create a second Forever rule named BuzzOff: Action → Buzzer Off, Delay → 100. Save it.
- Listen carefully. Write down exactly what you hear.
Observation: does the buzzer stay on, stay off, or make a strange stuttering noise? Does it sound the same every time you try it?
Think about it: priority only settles arguments between different modes. Two rules at the same priority simply take turns, so the output flickers and the behaviour is not reliable. This is called a race condition, and professional engineers work hard to avoid it.
The lesson: one component should be owned by one rule. If you need two behaviours, put them in the same rule as two steps — not in two competing rules.
Key Takeaways
✓ Forever = infinite loop
After the last step it restarts immediately, with no gap at all.
✓ Multiple steps make patterns
On/off steps with delays become blinkers, chirps and colour animations.
✓ A running rule locks its output
Manual dashboard control returns only after you Stop, Disable or Delete the rule.
✓ One component, one rule
Two same-priority rules on one output create an unreliable race condition.
Coming Up Next Week:
Week 24: Term 3 Assessment — The Component Mixer — put everything from this term together and prove what you can build.