How to Prompt AI for PLC Programming with Control Philosophies for Yaga

Effective AI prompting for PLC programming requires structured control philosophies, not open-ended requests. When engineers provide explicit I/O mappings, permissives, interlocks, sequence states, and failure conditions, Yaga can generate ladder-logic scaffolding that is materially easier to validate inside OLLA Lab’s simulation environment.

AI does not fail at PLC work because it is “bad at coding.” It fails because ladder logic is not just code generation; it is deterministic control behavior under constraints, scan order, and abnormal states. That distinction is often missed.

During a recent internal beta exercise of OLLA Lab’s Yaga Assistant, prompts that included a tag dictionary, defined safe state, and at least one explicit interlock produced simulation-usable first-pass scaffolding in 22 of 24 tasks (91.7%), while generic prompts such as “write a pump sequence” required major correction in 17 of 24 tasks (70.8%) before simulation could proceed. Methodology: n=48 prompt-task runs across pump, mixer, conveyor, and tank-level exercises; baseline comparator = generic natural-language prompt versus structured control-philosophy prompt; time window = internal beta window, February–March 2026. This supports one narrow claim: prompt structure strongly affects first-pass usability in simulation. It does not prove field deployability, safety sufficiency, or production readiness.

In automation, prompt engineering should be defined narrowly: the systematic translation of mechanical constraints, I/O mapping, and safety interlocks into machine-readable parameters so an AI agent can generate syntactically correct, testable scaffolding. That is a useful tool, not a substitute for engineering judgment. OLLA Lab matters here as the validation loop, not as a permission slip.

General LLMs fail at ladder logic because they predict plausible token sequences, while PLCs execute deterministic scan logic against stateful inputs and outputs. A language model sees text continuity; a controller sees evaluation order, memory bits, edge conditions, and device state.

Ladder logic is also spatial. Parallel branches, seal-in paths, permissive chains, and mutually exclusive states carry meaning through structure, not just through words. A general-purpose LLM tends to linearize that structure into text and can lose execution intent in the process. This is one reason AI-generated ladder can look competent while behaving badly.

A second failure mode is weak scan-cycle awareness. PLC logic is evaluated repeatedly, and outputs may be written, reset, or overridden within the same scan depending on program structure. Without explicit constraints, an LLM may generate:

• duplicate writes to the same output coil,
• missing one-shot behavior,
• race conditions between auto and manual modes,
• timers with unclear reset conditions,
• analog thresholds without deadband or fault handling,
• interlocks that appear in comments but not in executable logic.

The common result is familiar to practitioners: logic that reads well and misbehaves as soon as inputs change. Syntax is cheap; determinism is harder.

This limitation is broadly consistent with literature on LLM reasoning and code reliability. Published work across software and embodied systems suggests output quality degrades when tasks require persistent state tracking, spatial reasoning, or exact constraint satisfaction rather than fluent pattern completion (Bubeck et al., 2023; Huang & Chang, 2023). PLC programming is especially unforgiving on all three.

An automation-grade AI prompt is a compact functional specification. It should tell the model what the machine is, what “safe” means, what devices exist, what conditions must be true before action is allowed, and how failure should be handled. If the prompt cannot support a basic Functional Design Specification review, it is probably too vague for reliable ladder generation.

In practice, a good PLC prompt behaves less like a search query and more like instructions to a junior controls engineer. Senior engineers do not say, “make me a pump program.” They specify the process, the tags, the sequence, the trips, and the expected fallback state.

The 3 pillars of an automation prompt

#### 1. Context and objective

State the machine or process unit, the operating objective, and the safe state.

Include:

• equipment type,
• operating mode,
• start/stop objective,
• safe shutdown condition,
• abnormal-state expectation.

Example:

• “Single transfer pump fills a day tank.”
• “Safe state is pump off and outlet valve closed.”
• “If level transmitter is invalid, inhibit automatic start.”

#### 2. I/O and tag dictionary

Define the tags explicitly. AI performs better when naming is unambiguous and typed.

Include:

• digital inputs,
• digital outputs,
• analog inputs,
• analog outputs if relevant,
• internal memory bits,
• timers and counters,
• alarm or fault bits.

Example:

• `DI_PB_Start`
• `DI_PB_Stop`
• `DI_EStop_OK`
• `AI_Tank_Level_Pct`
• `DO_Pump_Run`
• `M_Auto_Mode`
• `T_FillTimeout`

Naming discipline is not cosmetic. It is the difference between traceable logic and a debugging tax.

#### 3. Permissives and interlocks

Define what must be true before action can occur, and what forces action to stop.

Include:

• permissives,
• trips,
• mode restrictions,
• feedback requirements,
• timeout behavior,
• alarm conditions.

Example:

• Pump may start only if `DI_EStop_OK = TRUE`
• Pump may start only if `AI_Tank_Level_Pct < 80`
• Pump must stop if `AI_Tank_Level_Pct >= 95`
• Raise alarm if run command is true and no run feedback within 3 seconds

This is where many prompts collapse. Engineers often specify the happy path and omit the reasons the machine must refuse to move. Real plants spend a great deal of time in off-normal conditions.

For AI prompting, a control philosophy should be defined as the minimum functional specification needed to generate testable control scaffolding. It is not a marketing phrase and not a vague design narrative. Operationally, it should contain the same core behaviors a controls engineer expects in an FDS-style document:

• initial state,
• operating modes,
• sequence of operations,
• permissives,
• interlocks,
• alarms and trips,
• failure responses,
• reset behavior,
• operator actions,
• success criteria.

That definition is bounded by engineering observables. If the prompt does not tell the model what the process should do when a sensor fails, a lid opens, a level exceeds threshold, or a feedback never arrives, then the prompt is not a control philosophy.

This framing aligns with established industrial documentation practice. IEC 61131-3 governs PLC programming languages, but good ladder logic still depends on upstream functional clarity. Standards do not rescue vague intent.

A useful misconception to retire

Prompt engineering in automation is not about making the AI more creative. It is about making the specification less ambiguous.

The most effective way to prompt Yaga is to provide a constrained, reusable template. The model should be told the role, the process objective, the tags, the sequence, the permissives, the interlocks, and the expected output format. If any of those are left implicit, the model may improvise.

Recommended prompt template for Yaga

Act as an IEC 61131-3 ladder logic assistant.

Objective: Create ladder-logic scaffolding for the following control task.

System Description: - Equipment: [machine/process unit] - Operating goal: [what the system should do] - Safe state: [what outputs/states must be true when stopped or faulted]

I/O and Tag Dictionary: Digital Inputs: - [tag]: [description] - [tag]: [description]

Digital Outputs: - [tag]: [description]

Analog Inputs: - [tag]: [description and engineering units]

Internal Bits / Timers / Counters: - [tag]: [purpose]

Operating Modes:

• [Auto / Manual / Maintenance]
• [mode rules]

Sequence of Operations:

Permissives:

• [condition required before start]
• [condition required before transition]

Interlocks / Trips:

• [condition that must stop or inhibit operation]
• [fault condition and response]

Alarms:

• [alarm condition]
• [timeout condition]

Reset / Recovery Rules:

• [manual reset requirement]
• [auto reset rule if allowed]

Output Requirements:

• Use clear rung-by-rung ladder structure
• Do not write to the same output coil in multiple conflicting locations
• Use named internal bits for sequence states where needed
• Include comments for each rung
• Identify assumptions explicitly

This template does not guarantee correct logic. It does something more useful: it makes errors visible earlier.

1. [step 1]
2. [step 2]
3. [step 3]

Junior prompt vs. senior prompt

| Prompt Style | Example | Likely Result | |---|---|---| | Junior prompt | “Make a ladder diagram that turns on a mixer for 10 seconds when I press start.” | Ambiguous stop behavior, missing lid interlock, unclear reset logic, weak tag structure | | Senior prompt | “Act as an IEC 61131-3 programmer. Create ladder scaffolding for a mixer. Inputs: `PB_Start` (NO), `PB_Stop` (NC), `LS_LidClosed`, `EStop_OK`. Output: `MTR_Mixer`. Interlock: mixer cannot run unless lid closed and E-stop healthy. Use TON for 10 s run cycle. Stop immediately on lid open or stop command. Safe state = motor off. Provide rung comments and identify assumptions.” | Testable baseline with explicit permissives, safer stop behavior, clearer simulation path |

The difference is not eloquence. It is constraint density.

A good PLC prompt should define the machine as a stateful system, not as a verbal task. Before Yaga writes any rung, the prompt should already answer six engineering questions.

1. What is the system?

Define the equipment, process boundary, and intended operation.

Example:

• “Lead/lag duplex pump station with high-level alarm and alternation.”

2. What is “correct” behavior?

Define the operational success condition in observable terms.

Example:

• “In auto mode, lead pump starts at 70% wet-well level and stops at 30%; lag pump starts at 90%; both stop on E-stop or motor overload.”

This matters because simulation-ready should be defined operationally: an engineer is simulation-ready when they can prove, observe, diagnose, and harden control logic against realistic process behavior before it reaches a live process. That is a stronger standard than knowing ladder syntax.

3. What are the tags and signal types?

List the tags, signal direction, and units.

Example:

• `AI_WetWell_Level_Pct` = analog input, percent
• `DI_P1_OL_Trip` = digital input, overload trip
• `DO_P1_RunCmd` = digital output

4. What abnormal conditions exist?

Define failures, invalid states, and fault responses.

Example:

• level transmitter bad quality,
• run feedback absent after command,
• both overloads active,
• E-stop not healthy,
• HOA switch conflict.

5. What must never happen?

State prohibited behavior explicitly.

Example:

• “Never command both pumps in manual alternation logic.”
• “Do not auto-restart after overload reset without operator action.”
• “Do not start mixer with lid open.”

6. What assumptions are allowed?

Require the AI to declare assumptions rather than bury them.

Example:

• “Assume stop pushbutton is healthy NC unless otherwise stated.”
• “Assume analog scaling already performed upstream.”

Hidden assumptions are a common source of weak AI-generated ladder logic.

OLLA Lab validates AI-generated logic by placing it inside a simulation environment where inputs, outputs, variables, and equipment behavior can be observed and manipulated before any live deployment is considered. That makes it a risk-contained validation loop, not an oracle.

The ladder editor provides the logic surface. Simulation Mode provides execution. The Variables Panel provides observability into tags, I/O states, analog values, and control variables. Together, they let an engineer test whether the generated logic behaves as specified when conditions change.

In practical terms, this means you can:

• toggle digital inputs,
• force fault conditions,
• inspect output response,
• watch timers and internal bits change state,
• compare ladder state against simulated equipment behavior,
• revise the logic after a failed test.

Validation is not a screenshot of a correct-looking rung. Validation is a sequence of disproven assumptions followed by tighter logic.

What the generate-validate loop looks like

1. Generate scaffolding with Yaga Use a structured control philosophy prompt.
2. Inspect the generated ladder Check tag names, output ownership, sequence structure, and interlock placement.
3. Run the logic in simulation Start with nominal conditions.
4. Inject abnormal conditions Force sensor loss, invalid permissives, lid-open states, overload trips, or timeout cases.
5. Observe whether the logic fails safely Confirm safe stop, alarm latch, inhibit restart, or hold state as required.
6. Revise and re-test Tighten the prompt or edit the ladder directly.

This is where OLLA Lab becomes operationally useful. It gives engineers a place to rehearse high-risk tasks that live systems are poor teachers for.

You test it by defining fault cases before trusting the nominal sequence. A ladder routine that works only when every signal behaves is not validated; it is merely unchallenged.

At minimum, test these categories in simulation.

Input integrity faults

• sensor stuck high,
• sensor stuck low,
• transmitter out of range,
• bad analog value,
• feedback absent after command.

Interlock failures

• E-stop unhealthy,
• guard or lid open,
• permissive lost during run,
• overload trip active,
• valve proof not made.

Sequence faults

• timer never resets,
• state bit remains latched,
• manual and auto command overlap,
• restart occurs after trip without reset,
• output remains energized after stop path.

Analog and PID-related faults

• process variable exceeds trip threshold,
• analog deadband missing,
• alarm chatter near threshold,
• controller output saturates,
• mode transfer causes bump.

The presence of analog tools and PID dashboards in OLLA Lab matters here because many AI examples stay trapped in discrete logic. Real process control usually does not. A pump station, AHU, thermal loop, or dosing skid often includes thresholds, delays, deadbands, and mode-dependent behavior.

A worked example should show the translation from process intent to machine-readable constraints. Below is a compact mixer example suitable for Yaga.

Example structured prompt

Act as an IEC 61131-3 ladder logic assistant.

System Description: - Equipment: Batch mixer - Operating goal: Run mixer for 10 seconds after operator start command - Safe state: Mixer motor off immediately on stop, E-stop loss, or lid open

I/O and Tag Dictionary: Digital Inputs: - DI_PB_Start: Start pushbutton, normally open - DI_PB_Stop: Stop pushbutton, normally closed - DI_Lid_Closed: Lid closed proof - DI_EStop_OK: Emergency stop healthy

Digital Outputs: - DO_Mixer_Run: Mixer motor run command

Internal Bits / Timers: - M_Mix_Cycle_Active: Mix cycle active latch - T_Mix_Run: 10 second TON timer

Sequence of Operations:

Permissives:

• DI_Lid_Closed = TRUE
• DI_EStop_OK = TRUE
• DI_PB_Stop healthy

Interlocks / Trips:

• If lid opens during run, de-energize DO_Mixer_Run immediately
• If E-stop unhealthy, de-energize DO_Mixer_Run immediately

Output Requirements:

• Provide rung-by-rung ladder scaffolding
• Use one output ownership path for DO_Mixer_Run
• Add rung comments
• State any assumptions

1. On start command, begin mix cycle only if lid is closed and E-stop is healthy
2. Run mixer motor for 10 seconds
3. Stop motor when timer done
4. Abort immediately if stop command, lid open, or E-stop unhealthy

What to check after generation

After Yaga generates the ladder, inspect for:

• one clear ownership path for `DO_Mixer_Run`,
• timer enable tied to active cycle state,
• immediate drop-out on lid-open or E-stop loss,
• no hidden auto-restart,
• comments that match actual rung behavior,
• explicit assumptions.

Then run it in simulation and force `DI_Lid_Closed` false during the timed run. If the motor command persists, the prompt or the logic is wrong.

Engineers should document AI-assisted PLC work as engineering evidence, not as a gallery of interface screenshots. A credible record shows what the system was supposed to do, how it was tested, how it failed, and how it was corrected.

Use this structure:

Record the exact fault introduced: sensor loss, overload, permissive drop, timeout, invalid analog value, and so on.

1. System Description Define the equipment, process objective, operating mode, and safe state.
2. Operational definition of “correct” State the observable success criteria, including stop conditions and abnormal-state behavior.
3. Ladder logic and simulated equipment state Show the generated or edited ladder alongside the relevant simulated machine state or variable behavior.
4. The injected fault case
5. The revision made Document the logic change or prompt refinement used to correct the behavior.
6. Lessons learned State what the failure revealed about the original control philosophy, assumptions, or sequence design.

This produces a compact body of evidence that is useful to reviewers, instructors, or hiring managers.

AI-assisted PLC prompting is useful for scaffolding, drafting, and accelerating first-pass logic structure. It is not sufficient for safety validation, commissioning sign-off, or site-specific deployment decisions.

That boundary matters for both ethics and engineering. OLLA Lab is described here as a web-based interactive ladder-logic and digital-twin simulator with guided support through Yaga, 3D/WebXR/VR simulations, scenario-based exercises, analog and PID tools, and instructor workflows. Those features make it useful as a rehearsal and validation environment. They do not convert generated logic into approved plant logic by association.

A few limits should remain explicit:

• AI-generated ladder may be syntactically plausible and functionally unsafe.
• Simulation can expose many logic defects, but it is not identical to site commissioning.
• Digital twin validation depends on model fidelity and scenario scope.
• Functional safety obligations still require formal methods, competent review, and standards-based lifecycle discipline.

This is consistent with broader safety literature. IEC 61508 and related guidance treat systematic failures, specification errors, and verification discipline as central concerns. A model that produces code quickly does not remove those duties.

This approach is more useful because it shifts the task from unconstrained generation to bounded engineering. When you write a control philosophy first, you force the important decisions into the open: safe state, permissives, trips, sequence ownership, and fault response.

That has three practical benefits:

• better first-pass scaffolding,
• faster debugging in simulation,
• clearer review by humans.

It also teaches the right habit. The professional transition is not only from not knowing ladder to knowing ladder. It is from writing rungs to defending behavior.

- IEC 61131-3 standard overview (PLCopen) - NIST AI Risk Management Framework (AI RMF 1.0) - W3C Web Content Accessibility Guidelines (WCAG) 2 overview - IEEE taxonomy and publications portal - ISO/IEC 23894 AI risk management standard page