State across scans and assignment order in Structured Text

The Core Idea

Structured Text statements execute in order, and each statement reads the values available at that point. A variable can also hold an earlier value when the current scan does not assign it again.

What you will learn

Predict what a variable holds when a statement reads it, scan by scan.
See why reading a variable before the statement that writes it costs one scan.
See why an IF with no ELSE leaves a variable holding its old value.

Why it matters

Correct individual statements can still produce unexpected behavior when their order or retained values are overlooked. Trace the whole scan to understand the result.

The problem

This is the Request circuit from the Ladder lesson on execution order, written in Structured Text. A Request button sets an internal memory bit, and an indicator lamp follows the memory.

Signal	Type	Meaning
`REQUEST_PB`	`BOOL`	TRUE while the Request button is switched on.
`REQUEST_MEM`	`BOOL`	Internal bit that should copy the button.
`LAMP`	`BOOL`	TRUE turns the indicator lamp on. It should follow `REQUEST_MEM`.

The requirement: the lamp is on in every scan the button is on, and off in every scan it is off. The program writes the lamp statement first, and it sets the memory inside an IF.

The simulator scans every 100 ms, too fast to watch a single scan. After you lock in your prediction, the program starts running. Press Pause, switch REQUEST on, then press Step one scan once.

See it go wrong

Step once more and watch LAMP. Then switch REQUEST off and step a few more scans.

Fix it

Change the program so the lamp matches the button in every scan, on and off. The checks step the program 100 ms at a time, so a one-scan delay fails them. Editing pauses the program; press Run, or step, to watch your version.

Passing the checks records Structured Text progress on the shared execution-order concept.

What happened and why

A variable keeps its value until an assignment changes it, including from one scan to the next. Every statement reads whatever its variables hold at the moment it runs. Here are the first four scans of the original program:

Scan	`REQUEST_PB`	`LAMP := REQUEST_MEM` reads	`IF REQUEST_PB`	End of scan: `REQUEST_MEM`, `LAMP`
1	TRUE	FALSE, left from before	sets `REQUEST_MEM` TRUE	TRUE, FALSE
2	TRUE	TRUE, left from scan 1	sets `REQUEST_MEM` TRUE	TRUE, TRUE
3	FALSE	TRUE, left from scan 2	does nothing	TRUE, TRUE
4	FALSE	TRUE, left from scan 3	does nothing	TRUE, TRUE

Two things went wrong, and both come from that kept value:

Order: the lamp statement ran before the memory statement, so it read the value from the previous scan. Put the statement that writes a variable above the statements that read it.
The hold: an IF assigns only when its condition is TRUE. When it is FALSE, nothing writes REQUEST_MEM, so the old TRUE stays. REQUEST_MEM := REQUEST_PB; writes TRUE or FALSE on every scan.

Sometimes the hold is exactly what you want. A start/stop circuit keeps a motor running after Start is released by setting a variable in one place and clearing it in another. Hold on purpose, never by accident.

Common mistakes

Reading before writing: a statement above the one that writes a variable sees the previous scan's value. At 100 ms you will not see the delay while the program runs, so step through it, and test the scan in which an input changes.
Expecting IF to undo itself: IF REQUEST_PB THEN REQUEST_MEM := TRUE; END_IF; never sets the memory FALSE. Assign the result directly, add an ELSE, or clear the variable first.
Writing one variable in two places: the last assignment in the scan wins, so a leftover LAMP := FALSE; at the bottom keeps the lamp off. Give each output one place that decides it.

Finish the unit

This is the last lesson in Foundations. The unit capstone is a ST Studio problem. It asks for one IF / ELSIF / ELSE decision, checked at both threshold boundaries. The card shows Done once every check passes.

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