Applied review: a small machine controller in Structured Text

The Core Idea

A machine controller combines decisions, memory, timing, and fault handling into one program that meets a written specification. The parts have to work together across scans, not just pass isolated examples.

What you will learn

Turn a written specification into a working controller: start-up, sequence, timing, counting, alarms, and recovery.
Combine the patterns from earlier lessons in one program, each in a section you can check on its own.
Test a controller the way it will be accepted: normal operation first, then injected faults.

Why it matters

A complete controller must handle ordinary operation and the transitions into and out of faults. Building from a specification gives you a way to check that whole behavior.

The specification

A conveyor carries parts past a photo-eye into a box. Write its controller in Structured Text. The lesson simulator runs the conveyor beside your program, with parts, the photo-eye, and two faults you can inject from the conveyor view: a jammed belt and a tripped motor overload.

I/O list

Tag	Type	Direction	Meaning
`START_PB`	`BOOL`	Input	TRUE while Start is pressed (momentary, normally open).
`STOP_PB`	`BOOL`	Input	TRUE while Stop is not pressed (momentary, normally closed).
`RESET_PB`	`BOOL`	Input	TRUE while the alarm Reset is pressed.
`PHOTO_EYE`	`BOOL`	Input, from the conveyor	TRUE while a part blocks the eye.
`JAM_SENSOR`	`BOOL`	Input, from the conveyor	TRUE while the belt is jammed.
`OVERLOAD_TRIP`	`BOOL`	Input, from the conveyor	TRUE while the motor overload relay is tripped.
`CONVEYOR_RUN`	`BOOL`	Output	Runs the conveyor motor.
`START_WARNING`	`BOOL`	Output	Start-up warning horn and beacon.
`PART_COUNT`	`INT`	Output	Parts in the current batch.
`BATCH_DONE`	`BOOL`	Output	The batch is complete.
`JAM_ALARM`, `OVERLOAD_ALARM`	`BOOL`	Output	Latched alarms.

Sequence of operation

Start-up warning. START, with no alarm on, sounds START_WARNING for 2 s with the belt stopped. Then the warning stops and the belt runs.
Counting. While the belt runs, each part that passes the photo-eye adds 1 to PART_COUNT, once per part however long it blocks the eye.
Batch done. The 3rd part stops the belt and turns BATCH_DONE on. The next START clears the count and BATCH_DONE, and starts again from step 1.
Stop. Stop stops the belt, or cancels the warning, at any time. The count is kept, and START resumes from step 1.

Alarm table

Alarm	Cause	Action	Clears when
`JAM_ALARM`	`JAM_SENSOR`	Latches; stops the belt; blocks START	RESET is pressed and `JAM_SENSOR` is FALSE
`OVERLOAD_ALARM`	`OVERLOAD_TRIP`	Latches; stops the belt; blocks START	RESET is pressed and `OVERLOAD_TRIP` is FALSE

RESET only clears alarms. It never starts the belt.

Acceptance tests

The visible tests are a start-up, a full batch with a restart, and a jam with its recovery. Hidden tests stop and resume mid-batch, trip the overload and try to start during it, and press Stop during the warning. Each time in a test has one scan of tolerance either side.

Build it

The skeleton declares a step number, the warning timer, and an edge detector, and marks five sections. Fill them in one at a time, pressing Run after each, and operate the human-machine interface (HMI) as you go. When normal operation works, use Field faults under the program to jam the belt and trip the overload, and check every row of the alarm table. Then press Run checks. The simulator scans every 100 ms.

Passing every acceptance test records Structured Text progress on the applied review.

How the parts fit

Each requirement maps to a pattern you have already written:

Requirement	Pattern	From
Alarms latch, clear on RESET only once the cause is gone	Fault latch: set on the cause, `ELSIF` reset	Start/stop memory, Hysteresis and alarm memory
One count per part	Rising edge, `R_TRIG`	Edges and event counting
2 s warning	`TON` called on every scan, with `IN := STATE = 10`	Timers and elapsed time
Idle, warning, running, batch done	`CASE` that only changes the step; outputs from the step	CASE and machine sequencing
Stop and alarms win	The clearing `IF` after the sequence	Start/stop memory

Keeping each requirement in its own section is what makes a controller reviewable: someone checking the alarm table reads section 1, not the whole program.

Common mistakes

Counting every scan the eye is blocked: one part adds 3 or 4. Count the rising edge.
Letting Reset clear an alarm whose cause is still there: the alarm drops while the belt is still jammed. Test the cause before RESET, in one IF/ELSIF.
Checking Stop and the alarms before the sequence: the CASE runs after them and can start the warning while an alarm is on. Put them after the CASE.
Calling the warning timer inside its step: the timer never resets, so the next start's warning lasts one scan.

Platform notes

A real start-up warning is set by the site's safety assessment: its length, and whether it must sound before every start. Treat the 2 s here as an example value.
Many sites write a specification like this one as a functional design specification (FDS), and run its tests as a factory or site acceptance test (FAT or SAT) with the customer present.

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