A repeat-until process needs a reachable stop condition

Mark the goal and state when the test is checked. Stop on the square and stop after passing it can produce different behaviour, while an unreachable condition may leave the process repeating indefinitely.

Check whether the stopping test happens before or after an action. That convention can change how many steps the process executes.

Can this starting state reach the stopping state?

State the stop test. Execute one step at a time. Check after each step.

Stop on the marked square differs from stop after passing it.

An unreachable condition may never end the process. Can this setup reach the stop state?

Use a short bounded route.

Put the test at a known point in the cycle

Use a fictional inspection token on a straight row of six squares. Mark the fourth square as the station and start on the first. Define one action as moving forward exactly one square. Write the process as check whether the token is on the station; if yes, stop; otherwise move forward and return to the check.

Place a small check card before the movement card. Run the process slowly, recording the square whenever the check is reached. The first three checks fail; the fourth succeeds while the token is on the station. No additional movement should occur after that successful test.

Ask a learner to predict the final square before execution, then explain which check ends the process. This is different from simply counting three movements because the written stopping rule refers to the current position, not to a fixed total.

What if the process starts at the station?

Reset the token directly on the marked square. Under the stated check-first convention, it stops without moving. Contrast this with a process that moves first and checks afterwards. That version would leave the station before its initial check. The order of testing and acting changes the behaviour even though the words station and forward remain the same.

Also try an unreachable station beyond a blocked square. State that entering a blocked square is not permitted. The original process cannot safely continue as written, so add a defined response such as stop and report blocked. Do not suggest that every loop naturally reaches its stopping condition.

Learners can place a yes or no card at the check, move the token, or keep a record of observed squares. A partner can read the process aloud while the learner chooses the branch. Use a large distinct station marker with a label so colour is not its only identifying feature.

Finish by asking where a new reader should look before deciding whether to act again. They should find both the stopping condition and its position in the cycle. Together these specify when repetition ends; a goal picture alone does not tell an interpreter when the instruction is tested.

Resources

• Human Robot Commands – Coding Without Screens Printable Game — Check the command conventions before using the sequence or debugging task.

Further reading

• CS Unplugged — Kidbots and algorithm activities
• Australian Curriculum Version 9 — Technologies overview

Read next

• Name a command block so it can be reused consistently
• Grid coordinates work when everyone reads them in the same order
• A program test case names the starting state and expected result

Explore Coding and computational thinking. Browse all teaching articles.