IEC 61131-3 Language Choice: Ladder, ST, FBD and SFC

IEC 61131-3 language choice should start with the task, the target controller and the people who will maintain the program. Ladder Diagram, Structured Text and Function Block Diagram offer different ways to express logic. A readable representation helps review, but it does not automatically make the program correct, fast or portable.

This guide compares those choices through a small virtual lamp-memory example, an arithmetic example and a sequence specification. The examples describe learning contracts; they are not motor wiring designs or a claim that our simulator converts every IEC language into every other language. Use them to decide what to learn next and what evidence to request before commissioning a course or automation project.

What IEC 61131-3 currently describes

The current IEC 61131-3:2025 publication listing identifies Edition 4, published on 22 May 2025. Its language suite comprises Structured Text, Ladder Diagram and Function Block Diagram. It also defines Sequential Function Chart elements for structuring the internal organisation of programs and function blocks. Describing Edition 4 as an unpublished draft is therefore outdated.

You will still encounter older teaching material organised around “five PLC languages”, including Instruction List. Distinguish that historical teaching convention from the current edition and from what a particular editor supports. The standard's publication does not automatically upgrade an installed controller, compiler or engineering licence.

For example, the CODESYS Development System overview lists its editors and explains that IL is obsolete and no longer maintained, while it can be enabled when required. That product statement does not establish a universal retirement date for every vendor's legacy instruction language.

When reading a course outline, ask which standard edition, controller family and software version it uses. “IEC compliant” is too broad to establish whether you can create, edit, debug and deploy the particular exercise on your equipment.

Ladder logic, Structured Text and FBD: compare the work

Use this table as a starting point for a discussion, not a rule that forbids alternative implementations. A well-designed reusable block can be called from a different language, and the same Boolean requirement can often be expressed clearly in several forms.

Ladder makes contact conditions and branches visible in a familiar circuit-like layout. That can help a team trace why a logical output is true or false. It does not mean every electrician already understands the runtime's instruction semantics, nor that a rung is a physical wiring diagram. Study ladder-logic fundamentals before relying on visual familiarity alone.

Structured Text makes assignments, conditional branches and bounded loops explicit in text. It can be convenient for calculations and data handling, but concise code can still conceal invalid indexes, unclear units or state carried between calls. There is no meaningful universal limit such as “switch to ST after four arithmetic operators”. Use Structured Text examples and execution rules to examine the actual work.

Function Block Diagram can make a chain of transformations easier to follow when connections and intermediate values are well named. A large crossing web of wires is not automatically clearer than text. Equally, FBD is not limited to stateless calculations: function-block instances can carry state. The FBD learning guide explains why those instances and their calls matter.

02

Define one behaviour before comparing representations

Our first exercise controls only a virtual study lamp. It has three Boolean inputs: Permit, Clear and Request. It also has a Boolean memory value, Lamp, initialised false at the start of the exercise. There is one evaluation at a time and one writer of Lamp.

At each evaluation, copy the existing Lamp value to OldLamp. Read a consistent snapshot of the three inputs. Compute NextLamp from those four values, then assign it to Lamp once. No timer, physical contactor, fieldbus or asynchronous writer is part of this model.

The intended rule is:

NextLamp = Permit AND NOT Clear AND (Request OR OldLamp)

A false Permit or a true Clear makes the next value false, regardless of Request or the previous memory. Otherwise Request can set the memory, and a previously true value remains true after Request is released. This is a level-sensitive teaching latch, not a fresh-press or restart-prevention design.

The first two rows group several combinations. Together the table covers all sixteen combinations of Permit, Clear, Request and OldLamp. Grouping is useful only when the result really is independent of the grouped inputs. You can expand the table into sixteen rows before implementing it in an editor.

This contract gives the language comparison a concrete target. Counting lines or graphical elements before agreeing on the target can reward an implementation that quietly omits a required condition.

Express the lamp rule in Ladder, ST and FBD

In an ST-style fragment, with the Boolean variables already declared, the update is:

OldLamp := Lamp;
NextLamp := Permit AND NOT Clear AND (Request OR OldLamp);
Lamp := NextLamp;

This is an explanatory fragment. Use the declarations, task arrangement and syntax required by your target environment. The temporary OldLamp value makes the previous-evaluation dependency explicit, while NextLamp gives you a value to inspect before the single commit to Lamp.

A conceptual Ladder network places Permit and the negated Clear condition in series with the entire parallel pair containing Request and OldLamp:

--[ Permit ]--[/ Clear ]--+--[ Request ]--+--( NextLamp )
                         |               |
                         +--[ OldLamp ]--+

Read that sketch by the stated connectivity, not as an importable vendor rung: both Request and OldLamp branches are downstream of the shared Permit and negated Clear conditions and join before NextLamp. Capture OldLamp before evaluating this network and commit NextLamp to Lamp afterwards. A negated software condition here tests a Boolean value; it does not specify a normally closed physical pushbutton.

For FBD, use an acyclic network of three operations. First calculate NotClear = NOT Clear. Separately calculate Demand = Request OR OldLamp. Then calculate NextLamp = Permit AND NotClear AND Demand. The same explicit snapshot and final Lamp assignment apply. This avoids relying on an unexplained graphical feedback loop to determine which value is read.

These three descriptions can satisfy the same Boolean truth table. That does not establish equivalence between arbitrary real programs containing timers, multiple calls, output aliases or different execution schedules. Those behaviours need additional tests and the editor's documented semantics.

03

Catch a branch-placement mistake with a counterexample

Consider a different expression:

WrongNext = Permit AND ((NOT Clear AND Request) OR OldLamp)

The memory branch now bypasses Clear. With Permit true, Clear true, Request false and OldLamp true, WrongNext remains true. The intended rule produces false. A program using that expression has a behavioural defect even if its diagram looks neat and its editor reports no syntax errors.

This counterexample is why “the same program in three languages” requires a shared test set. A successful normal start does not exercise the condition that distinguishes the two expressions. Test simultaneous requests, cancellation, loss of permission and previously active memory.

Follow this sequence from an initially false Lamp:

Evaluations five and seven deliberately show the limitation of a level-sensitive Request: releasing Clear or restoring Permit while Request remains true sets the lamp again. All equivalent implementations must reproduce that behaviour. If the intended application requires a new press, change the specification and test it; changing the programming language alone will not add that requirement.

For a deeper treatment of priority, memory and restart assumptions, use the latching logic guide. Keep this exercise on its declared virtual indicator rather than treating it as a machine start circuit.

Compare an arithmetic task without inventing speed claims

For a separate example, assume four validated integer samples, each between 0 and 10,000 inclusive. Compute their total in a sufficiently wide integer type, then convert the total to a real value before dividing by 4.0. The maximum total is 40,000, so a signed 16-bit accumulator is unsuitable; choose a type such as DINT in a target that provides the expected range.

An ST implementation might use a bounded loop over indexes 1 through 4. Reset Total to zero on each evaluation and widen the sample before arithmetic where required by the target's expression rules. An unreset accumulator would produce 42 on the second evaluation of the middle row, which is a different algorithm.

A graphical implementation could use a clearly named addition chain and an explicit conversion before division. For only four fixed samples that may be perfectly readable. For a variable-length data structure, text may be easier for your team to inspect. The decision depends on the resulting program, not an unsupported claim that every ST routine runs faster or costs less to maintain.

This example assumes samples are already validated. A real block contract must say what happens when a value is missing, invalid or outside its declared range. It must also define whether the four values belong to one coherent observation or were collected at different times. Language selection does not supply those missing requirements.

04

Choose SFC or a state machine by the review problem

Suppose a virtual workflow has three states: Idle, Collect and Review. Define a level-sensitive Start input for Idle, a Done input for Collect and an Accept input for Review. Reset takes priority and returns the state to Idle. With Reset false, an invalid state returns to Idle and reports an invalid-state diagnostic for that evaluation.

Only the branch corresponding to the state at the start of an evaluation may advance. Idle with Start true becomes Collect. Collect with Done true becomes Review. Review with Accept true becomes Idle. Without the relevant input, a valid state holds. No physical outputs are controlled by this example.

If Start, Done and Accept are all held true with Reset false, successive evaluations from Idle produce Collect, Review, Idle, Collect. They do not jump through all states in one evaluation. That trace also shows the level-sensitive restart behaviour; it is part of this worksheet, not a universal process requirement.

An ST representation can use a CASE on the old state and assign a next state. The CODESYS CASE reference describes selecting a matching section and an optional ELSE section. Several independent IF statements that immediately read a state changed by an earlier statement can produce a different trace.

SFC can make phases and transitions visible, particularly when reviewers need to discuss the process structure. However, action qualifiers, parallel branches, initialisation and execution order must be understood. The CODESYS SFC processing documentation describes its branch and action behaviour. A few boxes labelled Idle, Collect and Review are not enough to claim a tested equivalent implementation.

There is no universal rule that SFC becomes compulsory after three states. Compare how your actual team diagnoses the active phase, explains cancellation and reviews exceptional paths. For a more detailed sequence contract, continue with sequencer logic patterns.

Check platform, licence and routine boundaries

Verify the particular CPU, engineering environment and project configuration before choosing an editor. Siemens lists LAD, FBD and SCL in the cited S7-1200 language documentation. That list should not be replaced with a blanket claim that every Siemens target provides the same language options.

Rockwell's Logix Designer project-component reference describes routines as using a specific language and identifies examples including Ladder, FBD, SFC and ST. Check the actual software entitlement and supported target, rather than assuming a language named in documentation is editable under every licence.

Mixed-language projects can be sensible when the boundaries are clear. For example, a graphical supervisory routine may call a calculation block with a documented input/output contract. Review who owns the outputs, when each block runs and which state it retains. Avoid a blanket instruction to split every block solely because more than one representation is involved; follow the platform's structure and the team's maintenance needs.

For existing IL or other vendor-specific legacy code, migration is an engineering change. Preserve the original behaviour and toolchain information, identify dependencies, and establish regression tests before rewriting. A significant edit does not automatically make an immediate language conversion the lowest-risk option.

05

Assess maintainability with a practical handover exercise

Ask another learner or maintainer to explain a small routine without help from its author. Can they identify the condition preventing the lamp from turning on? Can they predict the Clear-and-Request case? Can they find the single writer and explain the initial value? Those observations provide evidence about this team's understanding of this program.

For the arithmetic block, ask the reviewer to find the maximum total, the conversion point and the behaviour on a second evaluation. For the sequence, ask what happens when all transition inputs are true, when Reset arrives and when the state value is invalid. These questions expose requirements that a line-count comparison misses.

Keep review findings specific. “The reviewer missed the memory branch bypassing Clear” is actionable. “Electricians cannot read ST” generalises about people without measuring the relevant skill. South African maintenance teams vary in their training, equipment and responsibilities; plan learning from those actual needs.

Document the chosen language, alternatives considered and the reason for the decision. Include compiler version, block interfaces, naming conventions, test cases and any unsupported constructs. If execution time matters, measure the resulting code on the intended runtime under representative conditions instead of ranking languages by reputation.

Practise language concepts without overstating simulator support

Use the Structured Text learning resources for the available text-based exercises and editor. The reviewed product includes ST learning material and an editor component. That evidence does not establish native LD, FBD, SFC and IL conversion with identical runtime behaviour across all five representations.

Use PLC program tests with expected outcomes to practise the habit of stating and checking a contract. If a chosen environment does not support a language or construct, compare its diagram on paper and use an appropriate vendor environment for implementation. Keep those forms of evidence distinct in your portfolio.

06

Questions South African PLC course buyers should ask

Should I learn Ladder or Structured Text first?

Choose the starting point that fits your immediate task and available equipment. A learner reading existing permission logic may start with Ladder; someone building bounded calculations may benefit from ST. Build shared foundations in Boolean logic, state, timing and types, then compare a second representation against the same expected results.

Is SCL the same thing as Structured Text?

SCL is Siemens' structured text programming terminology in the relevant STEP 7 environment. Treat language familiarity as a useful foundation, while checking target-specific declarations, libraries, conversions and system calls. Do not assume an entire project transfers between vendors because several statements look familiar.

How do I compare a Johannesburg course with an online course?

Request the exact controller and software access, exercise files, assessment method and instructor feedback. Ask whether you will debug a priority error, validate an array calculation and explain a sequence trace yourself. A location or a list of language names does not establish that depth. Use the South African PLC training guide to compare the wider course requirements.

Does learning several IEC languages prove commissioning competence?

It demonstrates part of programming knowledge when supported by assessed work. Commissioning also depends on the equipment, system design, authorised procedures and practical experience. Keep your portfolio precise: identify which programs you wrote, which runtime executed them, which cases passed and which physical tasks were outside the exercise.