WHILE and REPEAT loops in Structured Text: making loops end

The Core Idea

WHILE and REPEAT repeat statements according to a condition. WHILE checks before a pass, while REPEAT checks afterward; either loop needs a path that reaches its stopping condition.

What you will learn

• Use WHILE when a loop may need to run zero times, and REPEAT when it runs at least once.

• Give every loop a way out that is certain, such as a limit on how many items it checks.

• Tell repeating work within a scan from waiting across scans: a loop cannot wait for something to happen.

Why it matters

Repeated work happens within the scan. A search must finish even when it cannot find what it is looking for, so stopping and boundary cases are part of the design.

The problem

A storage rack has 8 slots. STORE puts a part in the first free slot, and CLEAR empties the rack. The program finds the first free slot on every scan, so STORE knows where the next part goes.

The search uses WHILE condition DO ... END_WHILE;, which checks its condition before every pass and stops when it is FALSE. It moves on slot after slot while the slot is occupied, wrapping from 8 back to 1. The simulator scans every 100 ms, and it stops any scan that runs more than 10 000 statements, as a controller's watchdog would.

After you lock in your prediction, press STORE to put a part in slot 4, the last free slot.

See it go wrong

Read the message under the program. Tags still shows slot 4 free: a scan that never finishes writes nothing, not even the part STORE put away. Press Reset to start before you go on.

Fix it

Change the search so it always ends: on the first free slot, or after checking slot 8. A full rack should show free slot 0 with RACK FULL on, and the program should keep running. The checks fill and clear the rack; hidden checks start from an empty rack, a rack with only slot 8 free, and a full rack. Editing pauses the program, so press Run to try your version.

Passing the checks records Structured Text progress on WHILE and REPEAT loops.

What happened and why

A loop ends only when its condition says so. The original condition depended only on the slots, and on a full rack nothing inside the loop could change them. The fix adds a limit, I <= 8, that the loop moves toward on every pass, so it is certain to end after at most 8 passes.

The rack could never empty itself while the loop was waiting. The whole loop runs inside one scan: nothing outside it changes until the scan ends, the outputs are written, and the inputs are read again. A loop repeats work within a scan; it cannot wait for something to happen. To wait for an input or for time to pass, keep state across scans, as a step sequence or a timer does.

WHILE or REPEAT

The rack search must check slot 1 on every scan, so a REPEAT loop fits too:

FREE_SLOT := 0;
I := 0;
REPEAT
    I := I + 1;
    IF NOT OCCUPIED[I] THEN
        FREE_SLOT := I;
    END_IF;
UNTIL FREE_SLOT > 0 OR I >= 8
END_REPEAT;
RACK_FULL := FREE_SLOT = 0;

WHILE is the safer default when the loop might have nothing to do, such as an empty list: zero passes is then the right answer.

Common mistakes

• Looping until the thing you want turns up: if it never does, the loop never ends. Give every loop a limit it is certain to reach.

• Forgetting to move to the next slot: without I := I + 1, the loop checks slot 1 forever.

• Checking one slot past the end: I <= 9 reads OCCUPIED[9] on a full rack, and the program stops.

• Reading the slot before checking the index: WHILE OCCUPIED[I] AND I <= 8 reads OCCUPIED[9] before the limit can stop it. Check the index first, or end the loop with a separate result, as the fix does.

• Not starting the result fresh: with FREE_SLOT left at the last scan's value, WHILE FREE_SLOT = 0 runs zero times, and the program keeps reporting a slot that is now taken.

Platform notes

• Real controllers watch the scan time and stop the program, or the whole controller, with a watchdog fault when a scan takes too long. An endless loop on a running machine is a stopped machine. This simulator counts statements instead, and names the problem.

• Some platforms evaluate both sides of AND even when the left side is FALSE. Do not rely on AND to protect an array index; end the loop on the index first.

Finish the unit

This is the last lesson in Working with collections. The unit capstone is a ST Studio problem. It asks for a FOR loop that adds up a fresh total on every scan. The card shows Done once every check passes.

Enable JavaScript to run the embedded simulator and complete the interactive exercises.