PLC Coding and LLMs

How to use LLMs to safely speed up IEC 61131-3 PLC development—Structured Text, reviews, tests, and guardrails.

LLMs can accelerate PLC work—scaffolding Structured Text (ST), documenting tags, and creating test scenarios—without touching runtime safety. The key is guardrails and review: generate offline, validate determinism and timing, and merge only after a human‑in‑the‑loop approves.

Where LLMs help (and where they don’t)

Strong fits:

  • Boilerplate ST functions, AOI/FB skeletons, and IO mapping tables.
  • Commenting legacy routines; generating diagnostics and operator messages.
  • Converting simple Ladder patterns to ST for reuse, with caveats.
  • Creating HMI tag descriptions and change logs from IO sheets.

Weak fits (keep human ownership):

  • Safety‑critical interlocks, SIL logic, and vendor‑specific nuances that affect scan determinism.
  • Precise timing networks, motion, and comms stacks.

Treat the model as a fast junior. It drafts; you review, simulate, and decide.

Safety and determinism come first

  • Deterministic scan: avoid dynamic branching explosions and lingering timers.
  • Bounded timing: keep watchdog margins; verify p95 cycle time under peak IO churn.
  • Side‑effects: isolate writes to outputs; centralize interlocks; prefer pure FBs.
  • Proven‑in‑use: keep safety logic curated and versioned; LLMs never write safety by themselves.

Prompt pattern for Structured Text

Give the model structure and constraints:

  • Inputs: IO table (tags, types), acceptance criteria, timing limits, and failure modes.
  • Output format: ST only (no prose), or ST + JSON test cases.
  • Validation: ask for simple static checks (unused tags, unreachable branches).

Example prompt (truncated):

You are drafting IEC 61131-3 Structured Text for a non-safety motor interlock.
Constraints: deterministic, no dynamic arrays, cycle-safe, no global side-effects beyond listed outputs.
Inputs:
  - estop: BOOL (true = emergency stop active)
  - start_cmd: BOOL
  - stop_cmd: BOOL
  - motor_running: BOOL (feedback)
Outputs:
  - motor_enable: BOOL
Acceptance:
  - Never enable when estop is true
  - Rising-edge start_cmd enables if estop=false and not motor_running
  - stop_cmd or estop clears enable
Return ST only.

Example ST (illustrative):

VAR
  start_z : BOOL; (* edge memory *)
  start_re : BOOL;
END_VAR

(* Rising edge on start_cmd *)
start_re := start_cmd AND NOT start_z;
start_z := start_cmd;

IF estop THEN
  motor_enable := FALSE;
ELSIF stop_cmd THEN
  motor_enable := FALSE;
ELSIF start_re AND NOT motor_running THEN
  motor_enable := TRUE;
END_IF;

Review for race conditions (e.g., feedback latency), add time filters if needed, and centralize interlocks.

Tests and simulation

Use a simple scenario table the model can generate, then replay in a simulator (Codesys, Studio 5000, TIA Portal test rigs):

  • Each row: inputs at t, expected outputs at t+Δ, and notes.
  • Include edge cases: bouncing start, estop flicker, delayed feedback, overlapping commands.
  • Persist results; fail the run on mismatches.

For richer checks, add a small harness to feed sequences and assert outputs per scan. Even a CSV‑driven player catches many regressions.

Guardrails for codegen

  • Constrain decoding: prefer grammar/format-enforced output for ST blocks.
  • Schema checks: parse generated blocks to ensure only allowed constructs.
  • Policy checks: no direct writes to safety outputs; no unbounded loops; no system time reads in cyclic tasks.
  • Require a reviewer sign‑off and attach traces of generation + test results to the change.

See also: Guardrails Beyond Regex.

Vendor specifics and portability

  • Siemens (TIA Portal), Rockwell (Studio 5000), Codesys, Beckhoff (TwinCAT) each have dialects and libraries.
  • Prompt with the exact dialect and library expectations; include minimum versions.
  • Keep adapters thin so logic FBs stay portable; isolate vendor IO and comms in wrappers.

Workflow that works

  1. Spec: write acceptance criteria and IO sheet.
  2. Generate: model drafts ST and scenario table.
  3. Static checks: lint, schema, policy.
  4. Simulate: replay scenarios; add misses to the suite.
  5. Review: human approves; record risks.
  6. Deploy: small, reversible change; watch scan and alarms.

Costs and privacy

  • Prefer small or on‑prem models for sensitive plants; redact P&IDs and proprietary tags.
  • Cache prompts; reuse partials; store diffs not blobs.
  • Keep generation in CI; never in the PLC itself.

Quick checklist

  • Deterministic ST only; no hidden state.
  • Interlocks centralized; safety logic curated manually.
  • Scenario tests pass in sim; watchdog margins respected.
  • Reviewer sign‑off; changes linked to test artifacts.

FAQ

Can LLMs write Ladder? They can draft simple rungs, but text limits clarity. Ask for ST or vendor‑specific export formats, then translate to Ladder with a human pass.

What about timing‑critical motion? Keep motion and safety as hand‑crafted libraries. Use LLMs for wrappers, diagnostics, and documentation.

How do I keep outputs safe? Separate calculation from actuation. Compute desired states in FBs, then gate them in a single, reviewed output network.

Want more detail? Contact us and we'll share implementation notes for your use case.