Start/stop memory, permissives, and reset priority in Structured Text

The Core Idea

Start/stop control remembers a run request while checking whether operation is permitted. When Start, Stop, or Reset conditions coincide, the program must implement the priority required by the specification.

What you will learn

Build start/stop memory from one IF that sets a variable and one that clears it.
Put a condition where it only prevents a start, or where it also stops a running machine.
Order the two IFs so Stop, a lost interlock, and a fault win over Start.
Latch a fault so it needs a deliberate reset, and make sure Reset never starts anything.

Why it matters

Requests and faults can change in the same scan. Deliberate memory and priority rules make the resulting machine command predictable.

The problem

A conveyor carries parts to a packing station. The lesson simulator runs the conveyor beside your program: CONVEYOR_RUN drives the belt, and the parts move while it runs.

Signal	Type	Meaning
`START_PB`	`BOOL`	TRUE while Start is pressed (momentary).
`STOP_PB`	`BOOL`	TRUE while Stop is not pressed. The button is normally closed, so pressing it, or a broken wire, makes it FALSE.
`GUARD_CLOSED`	`BOOL`	TRUE while the conveyor guard is closed.
`OVERLOAD_TRIP`	`BOOL`	TRUE while the motor overload relay is tripped. The conveyor writes it.
`RESET_PB`	`BOOL`	TRUE while the fault Reset button is pressed (momentary).
`FAULT`	`BOOL`	Latched fault lamp.
`RUN_MEM`	`BOOL`	Internal run memory.
`CONVEYOR_RUN`	`BOOL`	TRUE runs the conveyor motor.

The specification:

Start runs the conveyor, and it keeps running after Start is released. Stop stops it.
Opening the guard stops the conveyor, and closing it must not restart it: the guard is an interlock.
A motor overload trip stops the conveyor and turns FAULT on. FAULT stays on until the overload relay has been reset and someone presses Reset. Reset never starts the conveyor.
When Start is TRUE in the same scan as Stop, an open guard, or FAULT, the conveyor stays off.

The program latches the fault correctly. It clears RUN_MEM with Stop and the fault, and it checks the guard on the output line. A guard switch like this one is a control interlock; protecting people is the job of a separate safety system, such as a safety relay or a safety-rated controller.

The simulator scans every 100 ms, so hold START for a moment when you click it. GUARD CLOSED is a switch; lit means closed. Under the program, the conveyor view shows the belt, and its Field faults button trips the motor overload. After you lock in your prediction, click START, then switch GUARD CLOSED off and back on.

See it go wrong

Do it again and watch RUN_MEM in the Tags list. Then try the overload: trip it, reset the relay, and press RESET.

Fix it

Change the program so an open guard stops the conveyor and leaves it waiting for a new Start. The visible checks cover the four requirements, with the overload tripped and reset by the checks themselves. Hidden checks also hold Start down while Stop is pressed, while the guard is open, and while FAULT is on. Editing pauses the program, so press Run to try your version.

Passing the checks records Structured Text progress on the shared interlocks-and-permissives concept.

What happened and why

RUN_MEM holds its value on purpose. Start sets it, and nothing changes it until a clearing condition runs. The guard check sat on the output line, so it switched the motor off without clearing the memory. When the guard closed, the output followed a memory that had been TRUE all along.

Where you write a condition decides what it does:

Write the condition in...	It	Use it for
The Start `IF`	Only prevents a start	A permissive: a condition checked only when starting
The clearing `IF`, written last	Stops a running machine, clears its memory, and refuses a start	Stop, interlocks such as the guard, and faults
Only the output line	Holds the output off but keeps the memory	Nothing in a start/stop circuit

The order of the two IFs is the priority. When Start and a clearing condition are both TRUE in one scan, both IFs run, and the last assignment wins. With the clearing IF last, the conveyor is reset-dominant: Stop, a broken Stop wire, an open guard, or a fault beats a held or stuck Start.

The fault is a second piece of memory with its own contract. A trip sets FAULT, and nothing but Reset clears it. Testing OVERLOAD_TRIP first means Reset cannot clear a fault that is still present. Reset changes only FAULT, so after a reset the conveyor still waits for Start.

STOP_PB is TRUE while Stop is not pressed, so the program clears the memory on NOT STOP_PB. A broken wire also reads FALSE, so it stops the conveyor instead of hiding the Stop button.

Common mistakes

Checking an interlock only on the output line: the output drops, but the memory stays set, and the machine restarts when the condition returns. Clear the memory.
Writing the Start IF last: in a scan where Start and Stop are both TRUE, Start wins. A stuck Start button would then defeat Stop, the guard, and the fault.
Letting Reset clear a fault that is still present: test the trip before Reset, so a fault clears only once its cause is gone.
Letting Reset start the machine: Reset acknowledges a fault. Starting is a separate, deliberate action.
Reading the normally closed Stop the wrong way round: IF STOP_PB THEN clears the memory whenever Stop is not pressed, so the conveyor never runs.

Platform notes

IEC 61131-3 (the international standard for programmable controller languages) defines bistable blocks for this pattern: RS is reset-dominant and SR is set-dominant. This simulator does not include them, so the lesson writes the two IFs that such a block contains.

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