TL;DR: The most dangerous illusion when you inherit a TIA Portal program is "it compiles with 0 errors and 0 warnings, so it's fine." The compiler checks syntax and consistency — not cross-network logic bugs like "the infeed conveyor runs when no box is present." Lesson 5 of the free, text-based PLC AI in Practice course series (Lesson 5 here, ~35 minutes) closes exactly that gap: it has AI perform a read-only program review against a fixed checklist, and produce an evidence-backed, severity-graded, reproducible review report before commissioning.
Where this lesson sits in the series
"PLC AI in Practice" is a free, text-and-figure course for TIA Portal engineers. Its main thread breaks "daring to let AI touch a real project" into individually verifiable steps: understand a legacy project → assess change impact → write a block to a clean compile → get the program running in a virtual PLC. Lesson 5 is the last gate before commissioning: what in this program will go wrong, and what do you fix first?
The lesson deliberately separates "program review" from "code commentary." Asking an AI to review a PLC program with one sentence ("review this code please") gets you a pile of style notes — naming, comments, network splitting. All of that sounds reasonable, but not a single line of it proves the machine will stop when it should. The course defines review strictly: read-only, checklist-driven, defects only if they come with a failure scenario. Style preferences and candidates without failure scenarios are kept out of "findings."
The method: one task brief, four gates
The core deliverable of the lesson isn't knowledge — it's a reusable review task brief you can paste to an AI agent. Its structure is worth describing in its own right:
Gate 1 — what to review. A fixed 7-category checklist: structure & calls; state & retention (set/reset pairs, power-up recovery); timing & scan (double coils, edge storage, timer types); interlocks & safety; data & addressing (type/range, I/O addresses vs. hardware channels); maintainability; testability. The checklist stops the agent from reviewing only what it is comfortable with.
Gate 2 — evidence. Every candidate finding must carry seven elements: evidence (block + network + tag), the failure scenario (which inputs/timing/hardware state triggers it and what happens), a severity grade (P0 downtime/safety → P3 needs confirmation), confidence (confirmed / inferred / cannot confirm), a minimal-change fix suggestion, a verification method, and — critically — a counter-evidence pass: is there another network, an external write, or a process requirement that makes this conclusion wrong? "No failure scenario, no findings section" is a hard constraint in the brief.
Gate 3 — global view. The lesson builds an output → writers table: for every output, list every network and instruction that writes it. Multi-driver outputs, broken set/reset pairs, and scan-order issues are invisible if you look at one network at a time; you have to reconcile per output, globally.
Gate 4 — read-only. During review, no object is modified and the project is not saved; the report ends with a read-only declaration. Review first, produce the report; fixing is a separate, later process.
The course actually ran it: target and scoreboard
This isn't a pure methodology lesson. It runs the review against the Sorting Boxes (Factory IO) open-source example: an OB1 with 18 ladder networks plus one SCL communications FC, 31 tags, and 5 system instance DBs. The example deliberately preserves real defects from the original project — ideal review practice material.
Per the lesson's own published results (I have not independently re-run them; treat the numbers as the course's):
- 2 × P1: right-hand sorting doesn't track box type — with a left-type box, both chains can fire simultaneously; and the infeed conveyor is driven by three networks, so it runs when no box is present, and its "stop" doesn't hold;
- 2 × P2: the ejector gets a pulse exactly one scan period long (10 ms) — an actuator may never see it; plus a compiler warning "inputs or outputs used that do not exist in the configured hardware";
- 1 × P3: no e-stop / safety logic inside the program — explicitly marked "cannot confirm": the original machine may have a hardwired safety circuit, and that's for electrical drawings and a safety review to decide;
- 1 false positive, eliminated by counter-evidence: the exported SCL text contains concatenation artifacts that look like compile failures — but when TIA actually compiles the block, it's 0 errors.
That last item is, to me, the most valuable part of the whole lesson. The biggest risk of AI-assisted review is not missing a defect; it's treating "looks like a problem" as "confirmed defect." The lesson dedicates an entire step to counter-evidence: for every candidate, ask three questions — is there another network or external write that reverses the conclusion? Is the signal maintained or a pulse — does the failure scenario still hold? Is there a process requirement that makes this intentional? Three scary-looking candidates get downgraded or eliminated that way, and only the provable ones survive into the report.
This is a general lesson for anyone using AI to review code (well beyond PLC): trust the compiler for compile results — never substitute text export for an actual compile, and always keep "confirmed" and "inferred" as separate labels.
Compiling, simulation, and humans are not interchangeable
The course hammers on the boundaries between three verification methods: compiling catches syntax and consistency, but not logic errors; simulation / scan-by-scan reasoning validates logical behavior, but not wiring, physical channels, or safety circuits; humans own process intent, hardware configuration, and safety review. Every finding must state its verification method — none of the three may impersonate another.
Safety is treated with particular rigor: the course's stance is "AI assists the review; conclusions must be human-verified." E-stop and safety functions must be confirmed by qualified personnel; the report is not a safety certification, and "the program doesn't contain it" must never be inverted into "the machine is unsafe." That red line matches what we've argued on this blog all along — AI assists, humans gate.
Who it's for, and what you need
Good fit: electrical/automation engineers inheriting someone else's (or their own past) TIA Portal projects; teams wanting AI in code review without knowing how to constrain it; anyone who wants to turn the 7-category checklist into a team review template — the course explicitly suggests using "7 categories + evidence + counter-evidence + severity" as an MR/review template. It also recommends taking one of your own legacy projects, running the brief against it read-only, and only then deciding what's worth fixing.
Prerequisites: a Windows machine with TIA Portal V19, TiaLink (an MCP gateway that connects TIA Portal to your AI agent; it runs locally, so project data stays in the plant), and any Streamable-HTTP MCP client (Claude Code, Cursor, VS Code, ...). The lesson is ~35 minutes, free, no videos, nothing to buy.
Not for you if you're looking for a one-click "AI will optimize my code" button — the methodology here points the other way: zero changes during review, human verification of every finding before any fix enters a change process.
Further reading (all in Chinese, on our blog)
- AI PLC Programming: 7 Free Hands-On Lessons, Each With a Verifiable Gate — our overview of the whole 7-lesson series;
- Taking Over a Legacy PLC Program: A 4-Step Forensics Routine — evidence gathering and baselining before the review;
- Learn-LAD Ladder Example Library — where the Sorting Boxes example comes from;
- AI Editing TIA Portal Projects: Write Protection in TIA Openness MCP Tools — write-protection design patterns when letting AI modify projects.
If you'd rather read the primary source: Lesson 5, in Chinese, at Learn-LAD — the task brief and the report template are copy-paste ready.
Disclosure: all measured numbers above (2×P1, 2×P2, 1×P3, 1 eliminated false positive; 18 networks; 31 tags; 5 system instance DBs; 10 ms pulse) come from the course page's own published run, not from an independent re-test by this publication. This article is a syndicated English translation of our original Chinese post and originally appeared there.
Top comments (0)