What Is Structured Text?

Back to Blog

How Structured Text Works

Structured text uses familiar programming constructs: assignment (:=), conditionals (IF/ELSIF/ELSE), loops (FOR, WHILE, REPEAT), CASE statements, and arithmetic and logical operators. Variables are declared with defined data types, and the code executes top to bottom each scan. To anyone who has written Pascal, C, or Python, it reads immediately - though it still runs inside the PLC's deterministic scan cycle like any other IEC 61131-3 language.

This textual form makes ST compact and expressive. A calculation that would need dozens of ladder rungs - iterating over an array, computing a totalized volume, or running a complex state machine - can be a few clear lines of structured text. It is also easy to comment, version, and review, which appeals to teams applying software-engineering discipline to control code.

When to Use Structured Text

ST is the right tool for math-intensive and algorithmic logic: flow calculations, unit conversions, data manipulation, recipe handling, and complex conditional logic. It is far more readable than ladder for anything involving loops or arrays. Many engineers use it selectively - writing the bulk of a program in ladder or FBD for readability, and dropping into ST for the parts that genuinely need it.

The trade-off is audience. Ladder was designed so electricians and technicians could read it at 2 a.m.; structured text assumes some programming fluency, which not every field team has. In oil and gas, ST often appears in flow computers and metering logic, where the calculations are inherently mathematical. As with any language, the PLC publishes its results as tags, and a SCADA platform like Merobix reads and trends those tags over the controller's native protocol regardless of how the logic was written.

A Worked Example: A Totalizer in Four Lines

Here is the kind of job ST makes trivial. To accumulate a volume from a flow rate, with the rate in units per hour and the scan interval in seconds:

IF Running THEN
  Total := Total + FlowRate * ScanSeconds / 3600.0;
END_IF;

Four lines, readable by anyone. The division by 3600.0 converts the hourly rate to a per-second contribution; multiplying by the scan interval integrates it over time. The same logic in rungs takes a multiply block, a divide block, an add block, and a move instruction, wired together and read in the wrong order forever after.

The example also carries a classic trap. Total is a REAL, and single-precision floating point loses resolution as the accumulated value grows - eventually each small addition rounds away entirely and the totalizer silently flatlines. The standard fixes are periodic rollover into a separate register, double-precision types where the platform offers them, or integer accumulation in the smallest meaningful unit. And when the total is for custody or fiscal purposes, this logic does not belong in the PLC at all: that is what a dedicated flow computer exists for.

ST Pitfalls That Surface at the Worst Time

Most ST bugs are ordinary programming bugs given industrial consequences. An unbounded WHILE loop does not hang a desktop app; it blows the PLC's watchdog and faults the processor. Integer division silently truncates - 3 / 2 is 1 - which corrupts scaling math until someone notices the units are wrong. Division by a process value faults the scan the first time that value is zero, which is usually during the abnormal condition the logic most needed to survive. The defensive habits are the same ones any language teaches: bound every loop, guard every divisor, and treat compiler warnings as errors.

Two more deserve respect. Edge detection: ST evaluates conditions every scan, so a naive 'when the button is pressed, increment the counter' increments every scan the button is held - rising-edge detection with R_TRIG or an explicit last-state variable is mandatory. And retentivity: variables declared retentive keep their value across a power cycle while others restart at initial values; a state machine that mixes the two can wake up in a state that never existed. Deciding what must survive a restart is design work, not a declaration detail.

Keeping ST Reviewable by the Whole Team

ST's power is also its risk: it lets one clever engineer write something nobody else on the team can maintain. A few habits keep it honest:

1. Name states and constants - a CASE statement over named values reads like a procedure; magic numbers read like a puzzle.
2. Comment intent, not mechanics: say why the deadband exists, not that the line compares two numbers.
3. Keep each routine short enough to read on one screen, with one job per routine.
4. Keep interlocks and permissives in ladder logic where technicians expect to find them, and use ST for the math and sequencing underneath.
5. Export, version, and peer-review the source like any other code, and test changes in simulation before they reach a running unit.

None of this is bureaucracy for its own sake. The ST that causes trouble is rarely wrong when first written; it is wrong two years later, after three undocumented edits by three different people. Process is what lets the fourth person edit it safely, and what lets an auditor or a new hire trust what they are reading.

Frequently Asked Questions