Why Do LLMs Fail at Ladder Logic? The Graphical Advantage in OLLA Lab

Large Language Models struggle with Ladder Logic because they predict one-dimensional text, while Ladder Diagram and SFC depend on two-dimensional spatial relationships, parallel execution, and scan-cycle order. OLLA Lab provides a visual simulation environment where engineers can validate power flow, I/O behavior, and timing errors before logic reaches a live process.

AI does not mainly fail at ladder logic because ladder syntax is obscure. It fails because PLC control is not just syntax; it is spatial execution under deterministic scan timing. That distinction matters more than most prompt-engineering advice admits.

During a recent internal benchmark of 50 AI-generated motor control circuits imported into the OLLA Lab simulation engine, 68% of the AI-suggested sequences failed during the first virtual scan cycle due primarily to rung-order and state-dependency errors rather than syntax faults. Methodology: sample size = 50 generated motor-control tasks; task definition = import and simulate AI-generated start/stop, seal-in, permissive, and fault-reset patterns; baseline comparator = manually reviewed reference implementations accepted by Ampergon Vallis engineering review; time window = Q1 2026. This metric supports a narrow point: AI-generated ladder logic often breaks at execution time even when it appears structurally plausible. It does not support a general claim that all AI-generated PLC logic is unusable.

That is the real issue: text plausibility versus deployable control behavior. PLCs are not grading essays.

Ladder Logic is difficult for LLMs because the model predicts serialized text, while Ladder Diagram represents control intent through two-dimensional topology. The mismatch is architectural, not cosmetic.

IEC 61131-3 defines Ladder Diagram (LD) and Sequential Function Chart (SFC) as graphical languages used to express control relationships that are easier to reason about visually than as flat text alone (IEC, 2013). In LD, branch structure, power flow, rung order, and parallel conditions are part of the meaning. In SFC, divergence, convergence, active steps, and transition ownership are also part of the meaning. When that structure is flattened into XML, JSON, or prompt text, some of the execution context becomes easier to lose or misbind.

The 1D vs. 2D execution gap

Primarily serialize intent in a linear order. Even when they express branching or concurrency, the representation remains token-sequential and explicit.

• Text languages such as Python or C

Encodes logic as an electrical-style network with left-to-right power flow and top-to-bottom evaluation. Parallel branches are not decorative; they define execution relationships.

• Ladder Diagram (LD)

Encodes state progression spatially. Divergence and convergence indicate simultaneous or alternative paths that are harder to preserve when reduced to plain text structures.

• Sequential Function Chart (SFC)

Predict likely next tokens from training patterns. They can imitate ladder notation, but imitation is not the same as maintaining topological invariants across a control graph.

• LLMs

Research on LLM reasoning has repeatedly shown that token prediction does not reliably preserve spatial or topological structure, especially when the task requires consistent mapping across non-linear representations (Bubeck et al., 2023; Bang et al., 2023). The details vary by benchmark, but the direction is stable: sequence models are better at plausible continuation than at deterministic spatial bookkeeping.

A useful correction is this: ladder logic is not "easy for AI because it is simple." It is often hard for AI precisely because it is graphical, stateful, and scan-bound. Simplicity on the screen can hide difficult timing underneath.

What does “mastering visual logic” actually mean?

Mastering visual logic is not the ability to place a contact and a coil in the right order. It is the ability to prove how power flows through a multi-rung program under scan-cycle execution, including abnormal states.

Operationally, that means an engineer can:

• trace left-to-right power flow through nested branches,
• explain top-to-bottom rung dependencies,
• identify where a permissive is evaluated before it is updated,
• distinguish retained state from transient state,
• test fault, trip, and reset behavior,
• compare ladder state against simulated equipment state,
• revise logic after observing a failed sequence.

This is what Ampergon Vallis means by Simulation-Ready: an engineer who can prove, observe, diagnose, and harden control logic against realistic process behavior before it reaches a live process. Not syntax fluency. Not résumé theater. Evidence.

AI-generated ladder logic often fails because PLCs execute in a deterministic scan cycle, and many generated sequences ignore that execution order. A rung that looks reasonable in isolation can still fail when the controller reads inputs, solves logic, and writes outputs in sequence.

The standard scan model is straightforward:

1. Read inputs
2. Execute logic
3. Update outputs
4. Repeat

That cycle may run in milliseconds, but the timing is real enough to create race conditions, stale-state reads, and false permissives if logic is ordered badly. This is basic PLC behavior, yet it is exactly where text-only generation tends to drift.

The “looks correct” fallacy

The most common AI error is not invalid syntax. It is valid-looking logic with invalid execution behavior.

Examples include:

A permissive bit is checked on Rung 2, but the logic that sets it does not execute until Rung 5.

• Inverted rung order

A branch reads an output state as if it were already updated, even though the relevant rung has not yet solved in that scan.

• Premature output dependency

The generated pattern resembles a standard motor starter but fails to maintain state correctly when a stop or fault transition occurs.

• Broken seal-in logic

Fault-reset logic clears a trip before proof conditions are revalidated, creating a sequence that is tidy in text and potentially unsafe in operation.

• Improper reset sequencing

The model invents branch combinations that appear expressive in XML but do not map cleanly to a legal ladder network.

• Illegal or non-compilable branch structures

This is where visual validation becomes operationally useful. You need to see the active path, toggle the input, inspect the tag, and watch the sequence fail in order. A text export will not reveal that by itself.

Common AI spatial errors caught in OLLA Lab

In OLLA Lab’s simulation workflow, these failure modes are usually visible within the first test pass:

• active power flow does not reach the expected coil,
• a simulated motor run command drops out after one scan,
• an interlock remains false because the enabling bit is set too late,
• a reset sequence clears the alarm but not the underlying trip condition,
• analog thresholds trigger in the wrong order relative to state transitions,
• the simulated equipment state diverges from the ladder state.

The important point is not that AI makes mistakes. Human engineers do too. The important point is that PLC mistakes are temporal and stateful, so they must be observed in execution, not merely inspected as text.

AI struggles with SFC because SFC is a visual state machine whose meaning depends on branch ownership, simultaneous step activation, and transition discipline. Flatten the chart carelessly, and the machine logic becomes ambiguous.

SFC is often harder for LLMs than basic ladder because the model must preserve:

• which steps are active at the same time,
• which transition belongs to which branch,
• where divergence begins,
• where convergence is legally resolved,
• what should happen when one parallel path completes before another.

These are not small details. In batch, packaging, utilities, and process skids, they define whether a sequence waits, advances, deadlocks, or trips.

Why text conversion weakens SFC reasoning

When engineers convert SFC into prompt text, XML, or intermediate JSON, they usually preserve labels and transitions but lose some of the macro-structure that makes the chart intelligible at a glance.

What gets weakened includes:

• spatial grouping of simultaneous branches,
• visual ownership of transitions,
• relative position of step convergence,
• state visibility during abnormal conditions,
• the operator’s mental model of sequence progression.

This is one reason AI-assisted generation can produce SFC fragments that are locally plausible but globally incoherent. The model can describe a transition condition without preserving the chart-wide consequences of that condition.

In practice, SFC punishes shallow serialization.

Graphical representation matters because control correctness is not only logical correctness. It is also observable sequence correctness under realistic plant behavior.

In industrial automation, the question is rarely just "does the rung compile?" The real question is closer to this:

• Does the pump start only when permissives are true?
• Does the proof feedback arrive within the expected time?
• Does the alarm latch correctly?
• Does the trip reset only under valid conditions?
• Does the sequence recover safely after an abnormal state?
• Does the simulated equipment behavior match the intended control philosophy?

That is why standards and safety practice emphasize validation, verification, and lifecycle discipline rather than trusting generated code at face value. IEC 61508, for example, is explicit about systematic integrity, specification quality, verification rigor, and the danger of latent design faults in programmable systems (IEC, 2010). It does not contain a special exemption for code that looked convincing in a chat window.

Simulation and digital-twin-based validation are increasingly relevant here because they allow engineers to test behavior before site exposure. The literature is broad and uneven, but the central result is consistent: simulation-based training and virtual commissioning can improve fault discovery, sequence understanding, and operator or engineer preparedness when the simulation is tied to realistic process behavior rather than generic visualization alone (Tao et al., 2019; Negri et al., 2017; Uhlemann et al., 2017).

OLLA Lab bridges the AI gap by giving engineers a bounded visual environment to build, simulate, inspect, and revise control logic before it touches physical equipment. It is not an AI replacement and not a guarantee of field competence. It is a validation and rehearsal layer.

That positioning matters. A simulator should reduce commissioning risk, not manufacture false confidence.

What OLLA Lab does in this workflow

Within the scope of the product, OLLA Lab provides:

• a web-based ladder logic editor for building and revising rungs,
• simulation mode for running and stopping logic safely,
• a variables panel for monitoring inputs, outputs, tags, analog values, and PID-related states,
• 3D/WebXR/VR equipment views where available,
• scenario-based labs that connect ladder logic to realistic machine or process behavior.

Used properly, that supports a disciplined workflow:

1. Take the AI-generated suggestion as a draft, not as proof.
2. Rebuild or import the logic into a visual ladder environment.
3. Define the expected sequence and permissives.
4. Toggle inputs and observe outputs in simulation.
5. Compare ladder state against simulated equipment state.
6. Inject a fault or abnormal condition.
7. Revise the logic and retest.

This is where OLLA Lab becomes operationally useful. It turns "the model gave me code" into "the engineer observed the sequence, found the failure, and corrected it."

Which OLLA Lab features matter most for AI validation?

For this specific problem, the most useful features are the ones that expose execution state rather than decorate it:

Lets the engineer inspect branch structure and rung order directly.

• Visual ladder editor

Lets the engineer run logic safely and observe cause-and-effect without hardware.

• Simulation mode

Makes tag state, analog values, and output behavior visible during testing.

• Variables panel and I/O visibility

Provide realistic contexts such as motor control, pumping, HVAC, utilities, and process skids where permissives, trips, alarms, and sequencing actually matter.

• Scenario-based exercises

Helps users move from first-rung construction to more advanced timing, counting, comparison, and PID behavior.

• Guided build workflow

Can assist with onboarding and corrective suggestions, but the final authority remains the observed simulation behavior and engineering review.

• GeniAI lab guide

The product value is bounded and practical: it gives engineers a place to validate high-risk commissioning tasks that cannot be rehearsed casually on live plant equipment. That is a credible claim. Anything larger would overstate the evidence.

Engineers should validate AI-generated ladder logic as if it were an untrusted draft from a junior contributor: useful for acceleration, unsafe as final authority, and only acceptable after deterministic review.

A workable validation sequence is:

1. Define the control intent before reviewing the code

Write down:

• start conditions,
• stop conditions,
• permissives,
• trips,
• reset rules,
• proof feedback expectations,
• alarm behavior,
• fail-safe states.

If the control philosophy is vague, the code review will be vague too. The machine usually notices.

2. Check execution order, not just syntax

Review:

• rung order,
• branch legality,
• state dependencies,
• latch/unlatch behavior,
• reset sequencing,
• analog threshold ordering,
• whether any output is referenced before its governing logic is solved.

3. Simulate nominal and abnormal cases

At minimum, test:

• normal start,
• normal stop,
• loss of permissive,
• failed proof,
• sensor disagreement,
• power-up or reset state,
• alarm acknowledgement,
• recovery after fault.

4. Compare controller state to equipment state

A correct-looking rung is not enough. The simulated motor, valve, pump, fan, or skid must behave in a way that matches the intended sequence.

5. Revise and retest until the sequence is stable

One passing run is not validation. It is a first pass.

A credible body of engineering evidence is not a screenshot gallery. It is a compact record showing that the engineer defined correctness, tested failure, revised the logic, and learned something specific.

Use this structure:

1) System Description

State what the system is and what it is supposed to do.

Example:

• Reversing conveyor with start permissives, jam trip, motor feedback, and fault reset.

2) Operational definition of “correct”

Define observable success criteria.

Example:

• Conveyor starts only when guard closed and overload healthy.
• Jam trip stops motion within the simulated sequence.
• Reset is blocked until jam sensor clears.
• Restart requires a fresh start command.

3) Ladder logic and simulated equipment state

Show the ladder and the simulated machine behavior together.

Example:

• Seal-in rung energizes run command.
• Simulated conveyor state changes from stopped to running only after permissives and feedback align.

4) The injected fault case

Introduce one abnormal condition deliberately.

Example:

• Motor feedback fails to prove within the expected interval.
• Jam sensor remains active during reset attempt.

5) The revision made

Record the logic change.

Example:

• Added proof timer and trip latch.
• Moved reset permissive below fault-clear condition.
• Reordered rung evaluation to eliminate stale-state dependency.

6) Lessons learned

State what the failure taught.

Example:

• The original draft was syntactically plausible but read a permissive before it was updated.
• The revised logic aligned controller state with equipment state during restart.

This kind of evidence is far more useful than a polished image set. It demonstrates engineering judgment, not just software access.

AI can still be useful for PLC programming, but mainly as a drafting and assistance layer rather than an execution authority. It is good at pattern recall, boilerplate generation, explanation, and translation support. It is weaker at preserving deterministic behavior across graphical control semantics.

Reasonable use cases include:

• generating first-draft rung patterns,
• explaining timers, counters, comparators, and PID blocks,
• translating comments or tag descriptions,
• proposing test cases,
• summarizing control philosophy text,
• helping learners understand why a sequence failed.

Less reasonable use cases include:

• trusting generated logic without simulation,
• assuming XML export preserves topology correctly,
• using AI output as proof of commissioning readiness,
• treating prompt quality as a substitute for execution review.

The practical distinction is simple: draft generation versus deterministic veto. AI may help write the draft. The simulation and engineering review get the veto.

The current evidence supports a narrow but important conclusion: LLMs struggle with ladder logic and SFC not because industrial control is too niche to describe, but because these languages encode meaning through spatial structure, parallel relationships, and scan-cycle execution that are not naturally preserved by one-dimensional token prediction.

That conclusion does not mean AI is irrelevant to automation. It means the validation burden remains firmly with the engineer.

For ladder logic, the decisive question is not whether the generated text looks familiar. It is whether the sequence can be observed, faulted, corrected, and re-run against realistic behavior before deployment. That is the standard that matters in practice, and it is the standard OLLA Lab is designed to support as a bounded simulation environment.

Syntax is cheap. Determinism is the expensive part.

- IEC 61131-3: Programmable controllers — Part 3: Programming languages - IEC 61508 Functional safety standards family - NIST AI Risk Management Framework (AI RMF 1.0) - EU Industry 5.0 policy background - Digital twin overview (NIST)