Structured Text Overview

Structured Text (ST) serves as a high-level text-based programming language within PLC environments, offering advantages over traditional Ladder Diagrams (LD) for complex algorithmic tasks. While LD mirrors relay logic which suits electrical backgrounds, ST aligns closer with software engineering practices.

ST vs. Ladder Logic

Although basic logic like turning an output on when an input is active looks similar to C or Pascal:

IF Start_Sensor = TRUE THEN
    Motor_Output := TRUE;
END_IF;

It is often more efficient to utilize built-in functions for specific operations rather than verbose conditional statements:

Latch(Motor_Output, Start_Sensor);
Release(Motor_Output, Stop_Sensor);

When projects expand, ST remains compact compared to LD, which can become visually cluttered. Furthermore, ST supports custom tag names directly in the code context, whereas LD typically relies on hard-coded addresses unless tags are mapped externally.

Development Workflow in GX Works2

GX Works2 accommodates multiple methodologies including Instruction List (IL), Sequential Function Chart (SFC), and Function Block Diagram (FBD) alongside ST.

Project Setup

1. Initialize Project: Define the target CPU model.
2. Tag Management: Assign meaningful names to IO addresses. Variables can be Global (accessible across resources) or Local (confined to a single POU).
3. Configuration: Map hardware parameters to the software environment.

Implementation Steps

1. Code Entry: Develop logic using supported syntax.
2. Compilation: Verify syntax errors against IEC 61131-3 standards.
3. Transfer: Write logic to the PLC. Note that reading back an ST-only project may default to Ladder representation depending on the read settings.
4. Simulation: Utilize soft-run features to validate logic with out physical hardware.

Optimization Notes

Consider these comparison approaches for boolean logic:

Approach A (Verbose)

IF Input_A = ON THEN
    Output_B := ON;
ELSE
    Output_B := OFF;
END_IF;

Approach B (Direct Assignment)

Output_B := Input_A AND NOT Fault_Condition;

Appproach A generates more complex instructions upon compilation. Approach B is generally preferred for simplicity and performance.

Language Specifications

The following section covers core elements based on the IEC 61131-3 standard.

Software Model Archietcture

The system comprises three layers:

1. Configuration: The top level defining the controller system, hardware resources, I/O channels, and application scope.
2. Resource: Executes the program logic, acting as an interface between the code and physical I/O.
3. Task: Manages execution schedules. Parameters include:
   • Signal: Event trigger.
   • Interval: Time-based frequency.
   • Priority: Execution order importance.

Program Organization Units (POUs) such as Programs, Functions, and Function Blocks reside within tasks.

Variable Declaration

Variables must match defined data types and can be declared at different levels (Global/Local). They allow modification of runtime values representing physical signals.

Data Literals

Numeric

Bases can be specified explicitly:

• Binary: 2#1010
• Hexadecimal: 16#FF
• Decimal: 10#255 (implicit)

Example: Int_Value := 16#A;

String

Strings use double quotes (") for ASCII and single quotes (') for Unicode.

• STRING# "Hello"
• WSTRING# '你好'

Date & Time

• Duration: T#1h30m (Time Duration)
• Time of Day: TOD#12:00:00
• Date: D#2023-10-27
• Datetime: DT#2023-10-27-14:30:00

Data Types

Basic types include BOOL, INT, DINT, REAL, etc. Generic types prefixed with ANY allow flexibility. Arrays and derived structures are supported via user-defined definitions.

Reserved Keywords

Standard identifiers include PROGRAM, FUNCTION, END_PROGRAM, END_FUNCTION. Whitespace is ignored except inside strings. Comments begin with (* and end with *).