Structured Text (ST): PLC Syntax, Example & Pitfalls
Quick answer
Structured Text (ST) is the textual PLC programming language in IEC 61131-3. It uses assignments, expressions and control structures such as IF, CASE and loops. An ST routine still runs within the controller task model, so scan order, retained state, data types and vendor-specific instructions must be verified.
Key Takeaways
- Structured Text (ST) is the textual PLC programming language in IEC 61131-3. It uses assignments, expressions and contro...
- Intermediate-level topic in Programming Languages
- Commonly used in: State machines and sequence selection with CASE, Analog scaling, calculations and data conversion
- Related to: IEC 61131-3, Function Block, Ladder Logic
Detailed Definition
Structured Text (ST) is the textual programming language in the IEC 61131-3 suite. The valid 2025 Edition 4 standard specifies ST alongside Ladder Diagram and Function Block Diagram, with Sequential Function Chart elements for organizing programs and function blocks. ST is useful when a requirement is clearer as assignments, calculations, CASE branches, array processing or bounded loops than as a large graphical network.
A typical assignment uses the form Destination := Expression; and a statement ends with a semicolon. IF…THEN…ELSIF…ELSE, CASE, FOR and WHILE provide control flow, while functions and function blocks encapsulate reusable behavior. These familiar constructs do not turn a PLC into a general-purpose script runtime: the program organization unit is invoked by a configured task or caller, and its execution time contributes to that task scan.
IEC syntax is a shared foundation, not a guarantee of project portability. Siemens commonly labels the language SCL inside STEP 7, Rockwell documents Structured Text for Logix controllers, and CODESYS offers ST plus vendor-specific Extended Structured Text features. Libraries, function-block interfaces, numeric conversions, supported language subsets, initialization, task scheduling and online-change behavior vary. Rebuild and test the behavior in the destination platform rather than pasting source and assuming equivalence.
Use ST where it reduces accidental complexity, then make execution observable. Bound loops, define default output states, separate command logic from safety functions, expose sequence and fault state, and test startup, overflow, edge detection and abnormal inputs. A concise ST routine with a written test table is maintainable; a dense routine with hidden side effects is not.
Evidence and scope
The language scope was checked against IEC 61131-3:2025 Edition 4 and current Siemens STEP 7 V21, Rockwell Studio 5000 V38 and CODESYS documentation. The example uses portable IEC-style Boolean syntax, but task execution, libraries, instructions, data conversion, initialization and project files remain platform-specific.
Technical review:
Critical behavior
- ST executes when its routine, program organization unit or action is called by the configured controller task; it does not run independently of scheduling.
- An assignment writes its destination whenever execution reaches that statement. A skipped branch does not automatically clear a value written on an earlier scan.
- FOR, WHILE and REPEAT-style loops execute within a scan. An unbounded loop or unexpectedly large iteration count can overrun the task or trigger a watchdog.
- Stateful timers, counters, edge detectors and custom function blocks need persistent instances. Recreating or conditionally skipping an instance changes behavior.
- Implicit conversion, integer overflow, REAL precision, array bounds and evaluation order must be tested in the selected compiler and controller.
- IEC language similarity does not make native Siemens, Rockwell, CODESYS or other vendor projects interchangeable.
Verification checklist
- 1Declare every variable with an intentional type, scope, initialization and retention policy.
- 2List every destination write and confirm the value produced on each branch and skipped path.
- 3Bound loops and measure worst-case execution time against the configured task and watchdog.
- 4Test minimum, maximum, overflow, division-by-zero and invalid-index cases for calculations.
- 5Test cold start, warm restart, program-to-run transition and recovery from every sequence state.
- 6Compile and run the example in the exact target IDE, controller family and firmware release.
- 7Keep safety functions in the approved safety architecture and validation lifecycle.
IEC and vendor terminology
Similar-looking instructions do not always have identical execution, initialization or storage behavior.
| Platform | Common term | What to verify |
|---|---|---|
| IEC 61131-3:2025 | Structured Text (ST) | Edition 4 specifies ST syntax and semantics; target implementations may support documented extensions or restrictions. |
| Siemens STEP 7 V21 | SCL | Siemens uses SCL for its structured-text environment. Confirm CPU family, optimized access, instruction support and block interface behavior. |
| Rockwell Studio 5000 V38 | Structured Text | Assignments, constructs and instructions follow Logix syntax and execution rules. Some instructions need explicit conditioning for one-scan behavior. |
| CODESYS | ST / ExST | ST implements the IEC language; Extended Structured Text adds CODESYS-specific features that may reduce portability. |
The same motor command in Ladder and ST
LD |--[/ StopHealthy ]------------------------------------( MotorCommand OFF )--|
|--[ StopHealthy ]--[ OverloadHealthy ]--+--[ StartRequest ]--( MotorCommand )--|
+--[ MotorCommand ]--+
ST MotorCommand := StopHealthy AND OverloadHealthy
AND (StartRequest OR MotorCommand);Structured Text vs Ladder: choose by review task
Both languages can be correct. Prefer the representation that makes the requirement easiest to inspect, test and maintain on the target platform.
| State / phase | Structured Text | Ladder Diagram | Verification focus |
|---|---|---|---|
| Boolean interlocks | Compact expression, but parentheses and write order matter | Condition path is visually traceable online | Test every permissive false and simultaneous-command case |
| Calculations and scaling | Readable formulas, conversions and reusable functions | Can become wide or instruction-heavy | Test units, limits, division by zero, overflow and precision |
| Sequences | CASE gives explicit named or enumerated states | Step bits can be visible but duplicate transitions are easy to create | Test abort, hold, restart, timeout and recovery from every state |
| Repeated data | Bounded loops and arrays reduce duplication | Repeated rungs are verbose but individually visible | Measure worst-case iterations and task execution time |
Working LD and ST example
Runnable start/stop command with an explicit fault state
Implement the same normal motor command in LD and ST, then verify it with a scan-by-scan input table.
Ladder Diagram
|--[ StopHealthy ]--[ OverloadHealthy ]--+--[ StartRequest ]--( MotorCommand )--|
| +--[ MotorCommand ]--+
|--[/ OverloadHealthy ]----------------------------------------( Faulted )--|Structured Text
MotorCommand := StopHealthy
AND OverloadHealthy
AND (StartRequest OR MotorCommand);
Faulted := NOT OverloadHealthy;Expected result: StartRequest seals in MotorCommand while StopHealthy and OverloadHealthy remain true. A stop or overload clears the command on the next execution. This is ordinary process control, not a validated safety function.
Failure modes and diagnostic checks
| Symptom | Likely cause | Check next |
|---|---|---|
| An output stays true after a branch is no longer entered | No default assignment or false write executes on that path | Trace every write to the tag and define its value on every required state path. |
| The controller watchdog trips or task time spikes | A WHILE loop cannot terminate or an array loop has an excessive bound | Use bounded iteration, validate limits and measure worst-case task execution time. |
| A timer or edge detector resets unexpectedly | Its function-block instance is temporary, recreated or skipped by conditional execution | Inspect instance storage and call it consistently before using its outputs. |
| The same code produces different values on another PLC | Data widths, conversion, overflow, operator or library behavior differs | Use explicit types and conversions, then rerun boundary tests in the target compiler. |
| A sequence advances more than one state in one scan | Independent IF statements modify and re-evaluate the state during the same execution | Use an exclusive CASE or next-state pattern and log the transition. |
| A rising-edge action repeats every scan | A level condition was used where a retained edge detector was required | Use the platform-approved edge block or explicit prior-state logic and test task-call frequency. |
Current primary and technical sources
These sources support the behavior summarized on this page. The project's controller, firmware and IDE help remain authoritative for implementation.
- IEC 61131-3:2025 Edition 4
International Electrotechnical Commission — Current language suite, syntax and semantics scope
- Structured Text syntax, Studio 5000 V38
Rockwell Automation — Assignments, expressions, instructions and constructs
- Structured Text instruction execution
Rockwell Automation — Scan and conditioning differences from Ladder instructions
- SCL control structures, STEP 7 V21
Siemens — Current IF, CASE, FOR and WHILE editing support
- Structured Text and Extended Structured Text
CODESYS Development — IEC ST scope and CODESYS-specific extension boundary
Continue with the practical guide
Common Questions
What is Structured Text?
Structured Text (ST) is the textual PLC programming language in IEC 61131-3. It uses assignments, expressions and control structures such as IF, CASE and loops. An ST routine still runs within the controller task model, so scan order, retained state, data types and vendor-specific instructions must be verified.
When should I use Structured Text?
Structured Text is particularly useful in scenarios such as State machines and sequence selection with CASE and Analog scaling, calculations and data conversion. Consider implementing it when you need reliable, efficient solutions for these types of applications.
What should I verify before using Structured Text?
Declare every variable with an intentional type, scope, initialization and retention policy. List every destination write and confirm the value produced on each branch and skipped path. Bound loops and measure worst-case execution time against the configured task and watchdog. Test minimum, maximum, overflow, division-by-zero and invalid-index cases for calculations. Test cold start, warm restart, program-to-run transition and recovery from every sequence state. Compile and run the example in the exact target IDE, controller family and firmware release. Keep safety functions in the approved safety architecture and validation lifecycle.
What are related concepts I should learn?
To fully understand Structured Text, you should also familiarize yourself with IEC 61131-3, Function Block, and Ladder Logic. These concepts work together in industrial automation systems.
Also Known As
You may also see Structured Text referred to as:
Continue Learning
Ready to deepen your understanding of Structured Text? Here are some recommended resources:
Was this helpful?
Let us know if this glossary term helped you understand Structured Text better.
Your feedback helps us improve our glossary and create better content for the PLC programming community.
Quick Info
- Category
- Programming Languages
- Difficulty
- Intermediate
- Tier
- Essential
About Programming Languages
IEC 61131-3 standard programming languages and syntax