AI Writes the PLC Code. Proving It Works Is the Hard Part — 7 Free Hands-On Lessons

Posted on Oct 20 • Originally published at hubwiz.com

The missing piece in AI-assisted PLC programming isn't code generation — it's proof. PLC AI 实战 is a free, seven-lesson, text-and-screenshots course that breaks that problem into seven checkable endpoints: a compile with 0 errors and 0 warnings, a read-back that matches the spec, a scenario report that says PASS/FAIL, and a regression run that shows behavior didn't change. No videos, no course upsell, and nothing to download.

I went through all seven lessons and pulled out the parts that matter if you already write PLC code for a living — plus the three failures the course deliberately shows instead of hiding.

Almost every engineer's first reaction to AI-generated SCL is the same: looks about right, but I don't dare use it.

"Looks about right" comes from the model's strengths — interfaces, variable names, IF/THEN structure. "I don't dare" comes from the plant floor: a wrong PLC program doesn't cost you a compile error, it costs you a machine doing the wrong thing.

The course is valuable because it shows three real failures rather than a demo where the AI gets it right the first time:

All three have the same shape: the compiler cannot see them. So the only defensible criterion is: every step needs evidence someone else can re-check — not the agent saying "done."

This is the table worth remembering. Each lesson tells you which layer you're on:

A practical detail: scl_validate returning ok: true only means the source parses. The timer call from lesson 1 that omits PT will likely pass structural validation, while TIA reports Parameter 'PT' has to be used.

About 3.5 hours total. The order isn't by topic — it's the order work actually happens: write → modify → read → assess impact → simulate → verify → regress. Every lesson ends with a verification checklist; if you can't tick it, you're not done.

The only input is one requirement: an FB_Sorter with Start / SensorA / SensorB / Reset in, DiverterA / DiverterB / Running out, interlocked, 2-second outputs, reset clears everything. Everything after that — read the project, add a CPU, write the block, import, compile, fix, read back, save — is the agent's job.

Measured on TiaLink 1.1.0.0 + TIA Portal V19 + S7-1200 (CPU 1214C, V4.6). The first version reads like it satisfies the spec, and compiles to 2 errors and 2 warnings:

Two engineering disciplines hide here as well: every import leaves behind an external source file in the project (they pile up over iterations), and import ≠ save — a successful import is not a saved project.

The second lesson practices the more common job: take existing logic and change it. The simplest library example (a single-button toggle, 4 networks in LAD) gets one new input: Enable at %I0.1, forcing the output off when 0 and preserving the toggle when 1.

Two edits total: one new tag, and one series contact after the power rail in Network 2. After a clean compile, structural read-back confirms Motor = Enable AND (Tag_1 OR Motor) AND NOT Tag_2.

And one precondition: examples ship with Main (OB1) and Default tag table, so importing overwrites same-named objects. Get a clean baseline compile first, so that when something breaks later you know whose fault it is.

The third lesson is read-only against an MIT-licensed sample project: 5 blocks ( OB1 + FB2/FB3 + DB12/DB13 ), 51 tags, 3 HMI screens with 40 variables. The output is a project specification, with zero changes to the project.

Three classic legacy shapes show up immediately:

One more reconciliation: 6 of the 51 tags are not referenced by any PLC block, and HMI_PID deserves special mention — the HMI has a PID screen, but there is no PID block and the tag is unused. "PID may not be implemented" is a human-confirm item. A document that doesn't distinguish confirmed / inferred / unconfirmed is fiction.

The fourth lesson answers "can I touch it?" One candidate change: ZS-101 (Infeed Sensor) from %I29.0 to %I29.4. Read-only throughout, with a dryRun preflight at the end.

The result is cleaner than expected — and more dangerous:

The fifth lesson runs the program: the library example "exhaust fan control" (one network, TOF of 1 minute) is downloaded into an S7-PLCSIM Advanced 6.0 instance, driven by a scenario table, with measured values recorded.

The first whole-project compile is 0 errors, 1 warning: Inputs or outputs are used that do not exist in the configured hardware — the 1516 has no onboard I/O, so %I0.0 / %Q0.0 don't exist. Insert a DI and a DQ module (starting at 0) and it's 0/0.

The order is fixed: register instance → power on → wait for Stop → download → RUN. A freshly registered instance is empty, which is why you wait for Stop before downloading. /sim/status returning 403 means exactly two things: TiaLink was started with --no-sim, or PLCSIM Advanced isn't installed.

Four scenarios surface something the compiler can't see and the diagram reads wrong:

Press the stop button and the fan doesn't stop immediately. The TOF input is Turn_On_PB AND NOT Turn_Off_PB — for a TOF, releasing the start button and pressing stop are the same falling edge, so the fan keeps running for another minute either way. Reading the ladder, "stop means stop" is the natural (and wrong) conclusion.

Which changes the deliverable: not "I looked at it, it's fine," but scenario table + measured values + one conclusion.

The sixth lesson takes a lighter path: no TIA, no PLCSIM, no Windows. The same SCL goes to a cloud simulation MCP endpoint, executed scan by scan, turned into PASS/FAIL by a scenario table.

Setup is three steps: sign in, create a sim_live_ API key, add https://tia.hubwiz.com/sim/mcp to any Streamable HTTP MCP client. The endpoint exposes six tools ( lad_* / scl_* ); this lesson uses scl_validate, scl_simulate, scl_run_scenario.

Billing and fields worth knowing up front:

The first acceptance run produces the course's signature failure (indented block below — the source page prints it with full scan counts):

PASS start latches, reset clears (3 step(s), 5 scan(s)) FAIL sensor A pulse gives a 2 s diverter pulse: step 3 scan 100: DiverterA expected true, got false FAIL both sensors: A wins, only one output: step 2 scan 1: DiverterA expected true, got false RESULT: FAIL (2 failure(s), 109 scan(s)) Enter fullscreen mode Exit fullscreen mode The same root cause as lesson 1: a TON requires IN to stay true for the full PT, and the sensor is high for exactly one scan. "Trigger, then output for 2 seconds" was implemented as "hold it for 2 seconds, then output" — two different requirements.

Switching to TP (fixed pulse width) passes the first three scenarios, and then a new boundary case fails: a TP pulse is not cut short by IN:= FALSE. DiverterA:= PulseA.Q AND NOT Reset merely masks the output while the pulse keeps running, so the diverter comes back on when reset is released. The final design is latch + TON to end the pulse: make "currently diverting" an explicit ActiveA / ActiveB state, let Reset clear the state, and interlock on the other side's Active rather than its output.

The ALL PASS run: 8 scenarios + 16 sweep combinations + a 5,000-scan fuzz = 5,735 scan cycles. The report replays identically on local scl-sim 0.1.0 and the hosted endpoint (2026-10-19): same SCL plus the same scenario file yields the same PASS/FAIL and scan counts.

The last lesson covers "change the structure, not the behavior." The target is a three-motor delayed-start sequence: one button opens a 20-second window, three motors start at +5 / +10 / +15 s, and everything stops after the window. The original writes TON + coil three times in one network, differing only in PT and output — classic copy-paste.

The refactor collapses it into one parameterized FB ( Enable / Pt in, Q out) instantiated three times, with tag table, symbols and addresses untouched.

The author also crashed once, which is the point: IEC_Timer_0_DB was called as TON instead of TP. Compile: 0 errors, 0 warnings. Press the button: no motor moves. Switching back to TP and replaying the same scenario table brings behavior back point for point.

Which is why the two disciplines matter more than the code:

The course deliberately minimizes the human's actions, because in industrial work the interesting question isn't "can the AI write code" but "which actions have to stay with a person."

Short version: actions can be delegated, judgment cannot. The checklists and tables exist to turn "a human took a look" into "a human verified something."

Do I need TIA Portal installed? Not for the whole course. One of the seven lessons (cloud PASS/FAIL) never touches TIA — browser, account, and any Streamable HTTP MCP client. The other six need Windows plus TIA Portal V19.

Can TiaLink change my project on its own? It doesn't save silently. It exposes Openness operations as MCP tools, so writes are explicit: preflight before import, no overwrite of same-named objects by default, no auto-save afterwards. "Import ≠ save" appears more than once in the seven lessons.

If cloud simulation passes, is the program fine? No. Cloud simulation runs SCL scan semantics only — no bus, HMI, drives, safety circuits, and it is not the TIA compiler. What it is very good at is exactly the "compiles clean, behavior broken" class of bug, like TON where the requirement said "trigger."

Can AI-written blocks go straight into production? I wouldn't. The course's stance is consistent: AI assists, the compiler and read-back decide, every change gets human review, and safety functions, interlocks and e-stops are not delegated. What ships isn't "AI-written code" — it's code that passed the acceptance chain.

For: engineers who know TIA Portal but don't trust AI-written blocks in a real project; people inheriting a legacy program who want a specification before touching it; anyone training juniors who needs a checkable practice path; technical leads deciding how far AI can go.

Not for: people who have never opened TIA Portal (start with the 60-example ladder library ); anyone looking for "one-click ladder generation, download the project"; anyone who wants to skip human review and safety validation.

Read together, the seven lessons aren't about how much the AI can write. They describe an auditable delivery chain:

write → compile → read back → assess impact → simulate → PASS scenarios → regression shows behavior unchanged.

Every step has a criterion that doesn't depend on the AI claiming success. That's the part worth copying, even if you never use TiaLink or the cloud simulator: put evidence at every step, and AI actually gets to enter an engineering workflow.

Start with the 20-minute modify-an-example lesson, or the 35-minute cloud PASS/FAIL lesson.

This article was originally published in Chinese on hubwiz.com.