CODESYS Language Choice: Ladder, ST, FBD and SFC

Choose a CODESYS implementation language from the behaviour you need to express, the people who must review it and the tools available in the target environment. Ladder Diagram can make a small Boolean condition easy to follow. Structured Text can make a bounded calculation or data transformation concise. Function Block Diagram and Sequential Function Chart can make different kinds of structure visible. None makes an unclear requirement correct automatically.

This guide explains a practical language-selection method for South African learners, instructors and maintenance teams. It includes a fictional Boolean equivalence exercise and a stateful follow-up that exposes an incomplete translation. The examples are educational models, not a claim of native CODESYS execution or instructions for controlling a real machine.

Start with the environment and the standard edition

The IEC catalogue lists IEC 61131-3:2025 as edition 4. Do not use an undated “five languages” slogan as a complete description of either the current standard or a particular installed development environment. Record the standard edition relevant to your project and the actual editor and runtime capabilities you have.

CODESYS projects also depend on installed components and the target manufacturer's environment. Check which editors are available in the intended installation before designing a course around them. A language shown in a screenshot from a different installation is not sufficient evidence that your learners can use it in theirs.

The CODESYS platform guide explains the distinction between the development system, runtime and target equipment. Keep that distinction in the training brief. Learning an expression in one environment does not prove that an entire application, library or device configuration transfers unchanged to another target.

Define the behaviour before selecting its notation

Write the inputs, outputs, initial state and rules in plain language. State what happens for missing or invalid data. If the task has memory, describe how state changes and resets. If it has timing, define what is being measured and under which task assumptions.

Only then compare representations. A short ladder network may be clearer than a long expression for one task, while a loop may be clearer than repeated blocks for another. The useful question is whether a reviewer can connect each part of the implementation to the stated requirement and test it.

Ladder Diagram for visible Boolean relationships

Ladder Diagram is often a useful starting point when the key question is whether a combination of Boolean conditions produces an output. Series and parallel paths can make AND and OR relationships visible. Use descriptive names so the reader can explain the condition without guessing the meaning of an abbreviated tag.

For a small educational permissive, the reviewer should be able to identify every required condition and the alternatives that satisfy a branch. A diagram that spreads one condition across many networks may lose that advantage. Keep related logic together when doing so makes ownership and behaviour easier to understand.

Do not assume every electrician already reads every PLC convention fluently. Ask the actual maintenance team to interpret a sample. Familiarity with electrical drawings is helpful, but a PLC contact represents an evaluated Boolean condition, and its meaning depends on the programme's data and naming conventions.

Ladder can also call blocks and perform calculations. “Never use ladder for maths” is too broad. The practical concern is readability and review effort for the specific expression. A small comparison may fit naturally in a network; a large table transformation may be easier to maintain elsewhere.

For foundational practice, use the contacts and coils reference. Focus on translating a written condition into a representation and then choosing cases that could reveal a wrong branch or inverted condition.

02

Structured Text for explicit calculations and data handling

Structured Text is useful when expressions, conditional branches and bounded repetition express the requirement directly. A recipe lookup, a calculation over a small array or a clearly defined state update can be easier to read as text than as a large collection of connected boxes.

Choose meaningful variable names and keep intermediate values when they help explain the calculation. Compact code is not automatically clear code. A long expression that mixes unit conversion, validation and output selection can be difficult to inspect even if it fits on one line.

The Structured Text learning guide and syntax reference provide a starting point. When moving to a particular target, check supported types, libraries, conversions and execution behaviour. Familiar keywords do not eliminate platform-specific details.

Bound loops and define their purpose

CODESYS documents the FOR statement as repeated execution over a counter range. Its guidance warns about using the counter type's upper limit as the ending value. Choose a counter type and bounds that allow the loop to terminate, and review the workload in the intended task.

A loop should not be used as an unexplained way to wait for a physical event. A programme that repeatedly checks an unchanged input within one invocation may not behave like a sequence that observes the process over multiple task executions. State the intended observation and update model before choosing the structure.

For a classroom array exercise, begin with a small fixed number of elements and a declared valid range. Test the first and last elements, an empty logical selection if supported by the design, and invalid indices at the validation boundary. Do not treat successful compilation as proof that all runtime data is acceptable.

Inspect ST with the tools it actually provides

CODESYS documents monitoring within programming objects, including an ST editor view. It is inaccurate to describe ST as having no useful online visibility. Ask the instructor to demonstrate the monitoring available in the installed environment and explain which instance and values are being observed.

A current value still needs context. An observation after an assignment is not necessarily the value used earlier in the same execution. For difficult behaviour, retain a deliberate trace of inputs, state and outputs rather than drawing a conclusion from one changing display.

Function Block Diagram for connected operations

Function Block Diagram can make the relationship between calculations and function-block calls visible. It is useful when a reviewer needs to follow a value through a chain of operations. Label intermediate signals and units so the connections communicate meaning rather than only physical placement on the page.

Separate the graphical language from the concept of a function block. A stateful function block can be called from other implementation languages. Choosing FBD does not itself create a good reusable interface, and choosing ST does not prevent reuse.

The function block versus function guide explains why stored instance state matters. When comparing two representations, verify that they call the intended instance with the intended inputs and frequency. Similar-looking connections can still produce different behaviour if state ownership differs.

Use the Function Block Diagram learning guide to practise reading signal paths. Ask learners to explain the input and output meaning of each stage, not simply the order in which boxes appear on the screen.

03

SFC for explicit sequence structure

Sequential Function Chart makes steps and transitions visible. It can be useful when the main review question is which stage is active and what permits progression. Keep the action performed in each stage understandable and define how the sequence starts, stops and recovers within its educational scope.

A chart can become hard to understand when each step hides a large, unrelated programme. Use the chart to expose meaningful structure, then keep action interfaces and transition conditions traceable. The graphical overview should help a reviewer predict behaviour rather than merely decorate a complex implementation.

CODESYS has specific SFC processing-order documentation. Consult it when implementing actions and transitions; do not assume that the visual position of a step fully explains the execution semantics. A hand-drawn state chart and an implemented SFC need an explicit mapping.

For learning, the sequence logic guide helps define states and transitions before committing to an editor. A CASE-based ST implementation can also express a state machine. Compare the clarity, diagnostics and testing of the actual alternatives instead of declaring that every sequence must use SFC.

Distinguish CFC and legacy IL from a simple language list

CODESYS describes CFC and page-oriented CFC as implementation options available after installing CODESYS CFC. Its documentation describes freely arranged or page-oriented connected boxes and notes that the choice between those two forms is made when the POU is created. Check that choice before building a lesson around a particular layout.

Do not label every graphical block diagram as the same editor. A course should name the representation it uses and explain its execution model. Moving boxes until a diagram looks tidy is not a replacement for checking data dependencies and stateful calls.

For an existing IL application, first establish the supported maintenance environment and the reason for changing it. ABB's CODESYS-based help documents enabling IL in its applicable environment. That is evidence of a particular legacy-support route, not a recommendation to choose IL for every new project.

A language rewrite should have a requirement, a baseline and regression evidence. Rewriting unfamiliar legacy logic solely because another notation feels more modern can introduce errors. For new learning, prioritise the languages required by the target course and the team that will review the work.

04

Worked example: compare one Boolean rule in LD, ST and FBD

The fictional PermitStudy has three Boolean inputs: Enable, Ready and Override. Its output must follow the rule “Enable AND either Ready OR Override.” All inputs must be actual Boolean values. This is an educational logic exercise; the names do not define a safety function or an acceptable override arrangement for machinery.

An ST-style expression is Permit := Enable AND (Ready OR Override);. An LD representation would place Enable in series with a parallel choice between Ready and Override. An FBD representation would feed Ready and Override into OR, then combine that result with Enable through AND. These descriptions express the same stated Boolean rule.

Use all eight combinations to check the translation. A single successful case cannot show that the branch structure is correct.

Enable	Ready	Override	Required Permit
False	False	False	False
False	False	True	False
False	True	False	False
False	True	True	False
True	False	False	False
True	False	True	True
True	True	False	True
True	True	True	True

Now compare a mistaken expression: (Enable AND Ready) OR Override. It produces true whenever Override is true, including when Enable is false. The two cases with Enable false and Override true expose the error. The other six cases match, so a poorly chosen small sample could miss it.

This is why language choice and correctness are separate. Any of the three representations can express the intended rule or the mistaken one. The requirement and complete truth table provide the useful evidence for this small, stateless problem.

Make invalid input handling explicit

A missing Ready value is not one of the eight Boolean combinations. Do not silently substitute false and claim the original truth table covers missing data. Define a validation outcome separately if the exercise is extended to include absent, stale or malformed inputs.

Likewise, the text “false” supplied from a file is not automatically the Boolean value false in every programming environment. A parser needs a declared conversion rule. Keep those boundary concerns outside the small Boolean model until the lesson explicitly introduces them.

A stateful translation needs more than a truth table

Extend the exercise to a virtual counter that increments once on a false-to-true transition of a Boolean Sample input. Define the stored previous value as false and the starting count as zero. After every valid sample, update the previous value to the current sample.

For the sequence false, true, true, false, true, the expected count after each observation is 0, 1, 1, 1, 2. A mistaken implementation that increments whenever Sample is true produces 0, 1, 2, 2, 3. Both may look plausible if the reviewer checks only the first rising event.

When translating this behaviour between languages, preserve the previous-value state, its initial condition and update order. A different editor does not excuse a different counting rule. If a function block is used, give the exercise its own instance and document when it is called.

Add a reset only after its priority and effect on previous state are specified. Resetting Count while leaving previous state unchanged can produce a different next result from resetting both. There is no single correct extension until the requirement says which behaviour is intended.

This model does not capture every physical pulse. It operates on a supplied sequence of observations. A real input system introduces sampling and timing considerations that require separate study. Keep that limitation visible in the portfolio rather than presenting a paper trace as a measured high-speed counter result.

05

Make the language decision reviewable

Compare candidate representations against the same small requirement. Ask a reviewer to explain the normal result, find a deliberately wrong condition and identify where state is stored. Record the effort and misunderstandings observed. This gives the team evidence about readability in its own context.

Use a short decision note with the selected language, the reason, the alternatives considered and the limits. For example, a team might choose LD for the small permissive because its maintainers interpret the branches accurately, while using ST inside a separate calculation function. The interface between those parts should remain explicit.

Avoid treating a mixed-language project as automatically better or worse. Mixing can make each component clearer, but it also increases the knowledge required to review the application. Keep the number of conventions proportionate to the problem and provide a navigable structure.

The IEC language-choice criteria guide supports a broader team discussion. Use actual reviewer tasks and target constraints. Claims that one occupation always prefers one language are less useful than observing how the people responsible for the project understand it.

How to choose CODESYS training in South Africa

Ask the provider which implementation languages learners use directly, which are only demonstrated and which are outside the syllabus. Request the installed version, target environment and a sample practical. A course titled “IEC programming” may distribute its time very differently from another course with a similar name.

For a beginner, a useful sequence is a small Boolean requirement, a simple calculation and a stateful exercise. The learner should explain the expected result before running each example. The goal is to connect notation to behaviour, then extend complexity once that connection is reliable.

For an experienced technician, ask for review and diagnosis tasks across the languages present in the intended application. For a developer, ask for structured data, reusable interfaces and regression tests. For an instructor, ask how each learner's reasoning is assessed when multiple representations are allowed.

Our training-centre guide can help define an educational software evaluation. A suitable tool should support the intended lesson and evidence, not merely display several language names on a feature list. Confirm access and licensing for the actual class arrangement before planning delivery.

Practise concepts and verify the target implementation

This site is commercially connected to PLC Simulation Software. Its Structured Text learning resources can support preparation within the product's current educational scope. Check the documented feature set before expecting a particular CODESYS extension or editor.

Use its PLC programme testing resources to practise requirements, input selection and expected results. The examples on this page do not claim native CODESYS compilation, project import or identical runtime behaviour across targets.

For a portfolio, retain the requirement, chosen representation, test cases, observed results and a short explanation of a corrected mistake. Identify whether the result came from paper reasoning, educational simulation or the actual vendor environment. That distinction helps a reviewer understand the evidence and choose an appropriate next assessment.

06

Questions about choosing a CODESYS language

Should I learn ladder or Structured Text first?

Begin with the representation used by your course or target team, then learn to express a small requirement in another form. Ladder can make Boolean branches visible; ST can make calculations concise. Understanding the behaviour is more important than treating either language as a universal starting rule.

Is FBD the same thing as a function block?

No. FBD is a graphical implementation language. A function block is a reusable programme unit with instance state and an interface. It can be called from different supported languages. Check state ownership and call behaviour separately from the appearance of the editor.

Does SFC remove the need to understand execution order?

No. Steps and transitions provide structure, but the implementation has defined processing rules. Consult the applicable CODESYS documentation and test the sequence's initial, normal and exceptional cases. A clear chart still needs clear action and transition semantics.

Can I prove two implementations equivalent with one successful test?

Not generally. The Boolean exercise uses all eight combinations, while the counter needs a sequence of observations. Choose evidence appropriate to the state and input space. One matching output can coexist with a significant difference in an untested case.

Should I rewrite every legacy IL routine into ST?

Make that a planned change with a reason, supported tools and regression evidence. First understand the existing requirement and environment. A new notation may improve maintainability, but an uncontrolled rewrite can change behaviour and erase useful baseline evidence.