DEV Community: tia-forge

Claude Code Meets TIA Portal: One Prompt, a Compiled and Simulated PLC Program

tia-forge — Tue, 27 Oct 2026 08:19:21 +0000

Most "AI writes PLC code" posts stop at the SCL listing. The listing is the easy part. What matters is whether the thing lands in your project, compiles, downloads, and behaves — and whether you can tell when it doesn't.

We ran that whole path on a real TIA Portal V19 machine: from an empty device, one requirement, one prompt, to a program that compiled with zero errors, downloaded to S7-PLCSIM Advanced, and passed three behavioural scenarios. Everything below is measured, including the parts that failed.

How this was measured. 2026-10-27, Windows, TIA Portal V19 (Openness 19.0), S7-PLCSIM Advanced 6.0, gateway 1.3.2.0 driving the open project. The agent talked to TIA Portal over MCP, the same way any MCP client would.

What the gateway gives an agent

Five groups of capability, all against the project that is currently open in TIA Portal:

Capability	What it does
Read	project tree, block contents, tag tables, UDTs, cross-references, HMI screens, hardware config
Write	generate or rewrite SCL, create blocks and tables, write back, compile one block or the whole PLC
Configure	add a CPU, plug modules, create subnets, wire IO systems, set PROFINET device names
Verify	download to S7-PLCSIM Advanced, read and write variables, run scenarios
Archive	export SimaticML for offline diffing and version control

This build exposes 34 tools across those five groups, plus one more for LAD work. Install it in whichever client you use — the tool surface is identical.

Hooking it up

With Claude Code, it is two commands:

claude mcp add --transport http tialink http://192.168.1.110:8080/mcp
claude mcp list          # confirm it connected, and how many tools it sees

Other clients differ only in where the config lives: Cursor (.cursor/mcp.json), Claude Desktop (claude_desktop_config.json), or a UI connector in WorkBuddy/CodeBuddy (remember to click Enable — an added-but-disabled connector shows no tools and looks broken).

One practical note: raise the client timeout. Adding a CPU took 34 s on an older device and 2.2 s on a current one; a download takes ~10 s. A 60 s default will fire on work that is merely slow, and you will misread it as a failure.

One requirement, one prompt

The requirement, as an engineer would write it:

One start button starts motor 1; motor 1 running for 3 s starts motor 2 automatically.
The stop button (normally closed) or a fault on either motor stops both immediately.
Each motor has a run output; timing uses IEC timers.
The logic lives in a reusable FB; OB1 calls it.
I/O on M area: M0.0 start, M0.1 stop (normally closed), M0.2 fault, M0.3 motor 1, M0.4 motor 2.

The prompt we actually sent (verbatim):

【需求】两台电机的顺序启动控制
- 一台启动按钮启动 1 号电机；1 号电机运行 3 秒后自动启动 2 号电机
- 停止按钮（常闭）或任一电机故障时，1 号、2 号电机立即全部停止
- 两台电机各有运行输出，定时用 IEC 定时器
- 逻辑写成一个可复用的 FB，OB1 里调用它
- 输入输出用 M 区：M0.0 = 启动按钮，M0.1 = 停止（常闭，1 表示允许），M0.2 = 故障，
  M0.3 = 1 号电机，M0.4 = 2 号电机

【要求】
1. 自己决定步骤和工具，把它们下发到 PLC_3 并编译通过（0 错误）
2. 编译通过后下载到 S7-PLCSIM Advanced，创建全新的实例名，运行后用场景验证
3. 不要保存工程
4. 最后贴出完整的 SCL 源码和实测数值

No SCL template, no step list — the sequence was the agent's choice.

What it produced

FUNCTION_BLOCK "FB_MotorSeq"
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
   VAR_INPUT
      Start : Bool;             // start button (M0.0)
      StopPermit : Bool;        // stop, normally closed: 1 = allowed (M0.1)
      Fault : Bool;             // fault (M0.2)
      RunDelay : Time := T#3S;  // motor 2 delay
   END_VAR
   VAR_OUTPUT
      Motor1 : Bool;            // motor 1 running (M0.3)
      Motor2 : Bool;            // motor 2 running (M0.4)
   END_VAR
   VAR
      statRun : Bool;           // run latch
      statPermit : Bool;        // run permitted
      rtStart : R_TRIG;         // rising edge of the start button
      tonRun2 : TON_TIME;       // IEC on-delay timer
   END_VAR
BEGIN
    // Run is permitted when the normally-closed stop is closed and there is no fault
    #statPermit := #StopPermit AND NOT #Fault;

    // Latch on the start edge; stop or fault clears it immediately
    #rtStart(CLK := #Start);
    #statRun := (#rtStart.Q OR #statRun) AND #statPermit;

    // Motor 1 runs at once; motor 2 starts RunDelay after motor 1
    #Motor1 := #statRun;
    #tonRun2(IN := #Motor1,
             PT := #RunDelay);
    #Motor2 := #statRun AND #tonRun2.Q;
END_FUNCTION_BLOCK

And OB1, wiring it to the M area:

ORGANIZATION_BLOCK "Main"
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
BEGIN
    "DB_MotorSeq"(Start := %M0.0,
                  StopPermit := %M0.1,
                  Fault := %M0.2,
                  RunDelay := T#3s,
                  Motor1 => %M0.3,
                  Motor2 => %M0.4);
END_ORGANIZATION_BLOCK

Compile: state=Success, errorCount=0, warningCount=0, both Main (OB1) and FB_MotorSeq (FB1) cleaned.

Two details worth reading in that code: the start is edge-triggered (R_TRIG) — otherwise holding the button keeps it latched — and stop/fault runs through #statPermit, a path that never touches the timer. That second one is exactly what the third scenario below checks.

How long each step took

Step	Time
health probe (attached, project, device count, prerequisites)	< 1 s
look up the CPU model in the hardware catalogue	~1 s
create the CPU (CPU 1516-3 PN/DP, FW V2.9)	2.2 s
import the FB from SCL source	11.8 s
import the instance DB and OB1	0.6 s each
compile	1.4 s
create a virtual PLC and power it on	~6 s
download to S7-PLCSIM Advanced	9.6 s
run, write variables, read variables	< 100 ms per call

One ordering constraint you cannot skip: import does not compile. Right after import the block is not marked consistent, and even exporting it is refused (Block is inconsistent (not compiled)). Import → compile → read back, in that order.

Three scenarios

A green compile only says the code is acceptable to the PLC. These three runs say what it does.

Scenario	Action	Observed	Read as
Start	`M0.1=1`, pulse `M0.0`	motor 1 goes to 1 at once; motor 2 at +3.12 s; both hold after the button is released	delay is fed by "motor 1 running", not by the button
Stop	both running, `M0.1 → 0`	both drop within one sample; restoring `M0.1=1` does not restart them	the stop path is not gated by the timer
Fault	both running, `M0.2 → 1`	both drop within 13 ms (one scan); clearing the fault does not restart	fault is an independent cut-out, and it does not self-heal

The 3.12 s figure is 120 ms off the 3 s setting; that is one polling quantum (150 ms) plus scan jitter, not a logic error. The stop and fault cases are the ones worth insisting on: they are invisible at compile time, hard to reproduce on a machine, and they are what decides whether an operator has to press reset afterwards.

Beyond "Success"

A download that returns success still deserves a look at what actually landed. We exported the three blocks as SimaticML and checked three things: OB1 really calls the instance DB with those M addresses, the FB uses an IEC TON and no stray instance, and the block metadata says consistent. Sizes for the record: Main 7,766 B, FB_MotorCtrl 15,978 B (the earlier single-motor variant), DB_MotorCtrl 6,903 B.

The gateway's own notes make one behaviour explicit: nothing is persisted until you save. Imports, hardware writes, deletes and compiles all live in memory. That is what makes "try it, look at the result, throw it away" safe — and it is also the trap: if you never save and assume you are done, closing TIA Portal loses the lot. Our habit: verify first, save once, at the end.

A checklist before you let it touch a real project

Read-only first. Have it read the tree, blocks and cross-references; confirm it understood your project before it writes anything.
Preview writes for a week. Compare its previewed diff against what a person would change.
Read back after every write. Export or compare hashes; if it does not match, treat it as not written.
One project, one session, one writer at a time. The Openness side is serial; parallel agents produce half-finished work.
Compile as a gate. Passing does not mean correct, but failing must block the commit. This is the only gate you can fully automate.
Archive before changing. VCI or Git, exported as diffable text.
Keep an audit trail. Who, when, in which mode, which object.
Do not hand download or go-online to an unattended agent. Man in the loop, one step at a time, with a rollback plan.

And the rule that outranks all of them: AI-generated SCL gets a human review, especially safety logic (emergency stop, interlocks, F-programs). The tool guarantees it was written, not that it is right.

Versions and boundaries

Item	What we ran
TIA Portal	V19 / V20 supported; this run was V19 with Openness 19.0
Simulator	S7-PLCSIM Advanced 6.0, Softbus
CPU firmware	matters more than expected — a V1.1 device was refused by the simulator, V2.9 worked
Deployment	the gateway runs on the same Windows machine as TIA Portal; the agent can be anywhere that can reach its HTTP port
Tool count	34

The deployment line surprises people: the gateway has to be on the TIA machine, the agent does not. Every call in this article was made from a different computer over HTTP.

Run it yourself

You need two things: a Windows machine with TIA Portal V19 or V20, and the gateway installed on that same machine. It publishes its endpoint on http://localhost:8080/, and the client side is the one line of config from earlier.

Setup and version support: tia.hubwiz.com/tia-link. If you want the agent to understand the project before it starts writing, TIA-Context feeds it blocks, tag tables and call relationships.

Once the loop works, the mistake to avoid is asking for too much at once. One block, one change with a test case in front of it, beats "refactor this project" every time.

Further reading (in Chinese): AI changes a TIA Portal program: write guards and boundaries · OPC UA MCP hands-on · AI × industrial / PLC guide

Timings and error strings come from the 2026-10-27 run. AI-generated PLC code needs human review before it goes anywhere near production.

Three Kinds of LAD-to-SCL Tooling, and Why Only One Belongs in a Real Project

tia-forge — Tue, 27 Oct 2026 03:37:16 +0000

"Which software converts ladder to SCL?" is the wrong question, and not because the tools are bad. It's because three completely different classes of tool get filed under one name, and their failure modes have almost nothing in common. Comparing them on "accuracy" is comparing nothing.

Here they are.

1. The three classes

Class	How it works	What it actually reads	Ceiling	Where it fails
Built into TIA Portal	LAD ↔ FBD, LAD → STL	The blocks in your project	Cannot produce SCL — only FBD/STL	Not SCL. STL is assembler-ish: it runs, but nobody can review it, and diffs show nothing semantic
In-project add-in	Reads LAD blocks out of the project via TIA Openness / SimaticML, emits SCL source	The project itself — interfaces, tag tables, instance DBs, network order, every part and every wire	Whole-project coverage; anything its rules cannot handle must be surfaced as "review required"	Semantic structures its rule set does not cover (edge memory bits, jumps, MCR, multiple coils) — the answer must be "flag it", never "guess"
Screenshot / paste-a-text converters	Paste an image or a text blob, get code back	Pixels or characters — no tags, no instances, no network order	One small network; demos and learning	The information was lost on the input side. This is where "error rate is huge" comes from

So the widely repeated claim that third-party converters are inaccurate is true of class 3 and false of class 2. Class 2 and class 1 read the same data — the only difference is who generates the SCL.

One more thing to retire: there is no "convert everything in one click". What decides the outcome is not the software; it's the ratio, in your project, between structures that map mechanically and structures that only look like they do.

2. Fourteen structures, judged one by one

The table below is derived from the semantics of the two languages, not from a sample — which is why every row also says how you verify it yourself instead of taking my word for it.

#	Structure	What conversion can do	Verdict	What you must do
1	Series/parallel contacts	Boolean expression	✅ Safe	Check parentheses and operator precedence; don't rely on default associativity
2	Plain coil	`x := expr;`	✅ Safe	Confirm it isn't a multiple coil (row 10)
3	Set `(S)` / Reset `(R)` coil	`IF cond THEN x := TRUE/FALSE; END_IF;`	✅ Converts — inspect the output	When the condition is false the value must hold; an unconditional assignment has already broken the semantics
4	`RS` / `SR` boxes	Calls the corresponding FB	⚠️ Converts, trivially easy to pick the wrong one	They look identical in LAD; the difference only shows when set and reset are true in the same scan. Picking wrong does not error
5	Positive / negative edge contacts	`R_TRIG` / `F_TRIG` instance, or an explicit last-scan compare	⚠️ The most commonly broken row	The edge bit must live in static memory. Put it in TEMP and it is rebuilt every scan — the edge disappears, silently
6	`TON` / `TOF` / `TP`	Calls the IEC timer FB	⚠️ Converts; instance matters	Instance must sit in STATIC or a multi-instance DB; check PT type/units, and whether "wrapped in an IF" matches the original EN behaviour
7	`CTU` / `CTD` / `CTUD`	Calls the counter FB	⚠️ Same as above	Instance location, preset, and the priority of reset vs. load
8	Multi-instance FB call with parameters	`#myFB(IN1 := ..., IN2 := ...);`	⚠️ Converts, parameters get dropped	A missing pin does not error — it just keeps its previous value, so the bug surfaces only in one specific operating case
9	`JMP` / `LABEL`	—	❌ Cannot convert	SCL has no `GOTO`. Rewrite the control flow as a `CASE` state machine or structured branching
10	Multiple coils (same variable written in several networks)	Sequential assignments	⚠️ Converts — result depends on order	Make the write order explicit and check whether anything reads between the writes; which write gets read changes everything
11	`MCR` (master control relay)	—	❌ Cannot convert	Expand into an explicit condition chain: write out what the outputs do while the zone is disabled
12	`EN` / `ENO` chain	`EN` → `IF` wrapper	⚠️ Half converts	`ENO` routinely gets dropped → upstream fails, downstream keeps running. Check the return value or error bit explicitly
13	Implicit type conversion	Explicit conversion functions	⚠️ Converts — the boundaries move	Re-check divide-by-zero, integer overflow, REAL precision, TIME and counter type limits
14	Initialisation / first scan (OB100)	—	❌ Must be manual	Start-up block, static initial values, first-scan behaviour. These only fail after a power cycle

The pattern is easy to state: connection structure converts; state and timing do not. Rows 5, 6, 8 and 12 are all "the picture carried this for you, and the text won't".

And none of the fourteen will produce a compile error. Which is the real reason "it compiles" proves nothing about a LAD→SCL migration.

3. The brand question, briefly

Search suggestions often put "Siemens" and "Mitsubishi" in the same sentence. There is no universal converter, and there cannot be: the pictures look alike, but three things differ underneath — device addressing (I/Q/M/DB vs X/Y/M/D), instruction set and function-block semantics, and how edges and timers are implemented. A TIA Portal add-in reads TIA Portal projects. Across vendors it's a re-implementation with a fresh I/O mapping, not a conversion.

4. How to verify, without trusting any tool

Three steps, in this order:

Compare interfaces and tags. IN / OUT / IN_OUT / STATIC / TEMP, one by one; symbol names, types, retentivity. This alone kills most "looks like it runs" illusions.
Run the same inputs twice. Feed the original LAD block and the new SCL block an identical input sequence, then compare output timing and final values. Minimum coverage: first scan after power-up, start alone, stop alone, both at once, interlock opened mid-run, timer at the threshold, counter at the preset, manual/auto switchover.
Localise the divergence to a network. The first step where they differ maps back to one row of the table above — then it's either "converted but unchecked" or "should have been rewritten by hand".

Step 2 needs two environments that can run. With TIA Portal and PLCSIM you have them. Without TIA Portal you can still run the SCL side on a cloud simulator that executes scan cycles and returns final values plus PASS/FAIL — I used PLC Cloud Sim for regression runs, and its MCP endpoint lets an agent replay the same case set. To be precise about the boundary: that verifies logical equivalence only. It does not replace PLCSIM timing detail, hardware diagnostics, or commissioning on the machine.

5. So which one

For a real migration, class 2 for the bulk, your own judgement for rows 3–14, and class 3 nowhere near a project. Concretely, the add-in I use is LAD2SCL — a TIA Portal add-in by Hubwiz that reads LAD blocks from the open project and emits SCL. In the interest of not overselling: only the V19 installer has run on a real machine so far; V17/V18/V20/V21 are advertised on the page but have not been verified version by version, and the download buttons for them currently say "not released yet".

The longer Chinese version, with the migration workflow and the pre-release checklist, is here (in Chinese).

The 14-row table is a semantic analysis, not a benchmark. If you find a row that's wrong for your project, that's more useful than a star — tell me which one and what it did.

Empty Folder to MP4 in 162 Seconds: What a Coding Agent Can't Do With Video

tia-forge — Mon, 26 Oct 2026 04:29:50 +0000

The one-paragraph version. There are two unrelated technologies behind the phrase "AI video". One paints pixels from a prompt (Veo, Gemini Omni, Sora). The other renders a program into frames — a video is a React component tree or an HTML file, and the output is deterministic. Only the second one is something a coding agent can own end to end: it writes files, reads type errors, renders, looks at frames. We ran the whole loop on a clean machine and timed it. Total to first MP4: about three minutes. Then we hit the wall that every article about this topic skips — the agent has no way to know whether what it rendered is any good.

Disclosure. All commands and timings below were run by us on 2026-10-26 (Windows 11, 8-core CPU, Node 24.21.0, npm 11.19.0, Remotion 4.0.538). Everything else — license terms, skill counts, design rationale — is quoted from the vendor's own docs and is linked in Sources. We did not benchmark cloud rendering, and we did not run a paid generative model.

1. Two things are called "AI video"

	Prompt → pixels	Code → frames
Examples	Veo 3.1, Gemini Omni Flash, Sora	Remotion, HyperFrames
Unit of authoring	A sentence	A file in git
Output for the same input	Different every time (sampling)	Byte-identical
Editing a detail	Re-prompt, hope	Change one number, re-render
What the model must know	Cinematography, physics, faces	The API you gave it
Where an agent fits	Calls an API	Owns the whole repo

The distinction matters because the two have wildly different failure modes. A diffusion model fails by hallucinating a sixth finger; a render pipeline fails by throwing TypeError: undefined is not a function. Coding agents are good at the second kind of failure and useless at the first.

That is the whole reason this niche got hot in 2026: Remotion shipped Agent Skills in January, HeyGen open-sourced HyperFrames in April, and both are pure text — which is the only substrate a coding agent actually understands.

2. What "video as code" means mechanically

The mental model is one line: a frame is a pure function of time.

const frame = useCurrentFrame();          // 0, 1, 2, … 149
const p = spring({ frame, fps, config: { damping: 200 } });
return <div style={{ opacity: p }}>…</div>;

There is no timeline, no keyframe UI, no video editor. You write a component that, given a frame number, returns what that frame looks like. The renderer then:

bundles the project (Remotion) or loads index.html as-is (HyperFrames),
opens headless Chrome and seeks each timestamp,
screenshots the frame,
pipes the frames into FFmpeg.

Both frameworks do this. HyperFrames' README states the property that makes it usable in CI: "The renderer seeks each frame in headless Chrome and encodes the result with FFmpeg, so the same input produces the same video." Remotion's pitch is the same idea with a React component tree as the authoring surface.

Why agents like it: the artifact is TypeScript or HTML, the feedback loop is a compiler, and the diff is reviewable. git diff on a video is a strange sentence that is now literally true.

3. The demo, with real numbers

Four commands, no editor, no API key.

npx create-video@latest --yes --blank demo   # scaffold
cd demo
npx skills add remotion-dev/skills -a claude-code -y   # 12 skills → .claude/skills
npx remotion render MyComp out/video.mp4      # render

Measured, on the machine above:

Step	Wall time	Note
`create-video --yes --blank`	1 m 56 s	almost entirely `npm install`; dominates the clock
`skills add …`	6.0 s	12 skill folders written
first `remotion render` (5 s @ 1080p)	39.9 s	includes downloading headless Chrome
same render, warm	11.7 s	150 frames, 1080p30, `--concurrency` default = cores/2
60 s @ 1080p	68.7 s	1800 frames; ≈ 26 frames/s of output
60 s @ 1080p, `--concurrency=2`	84.4 s	forcing 2 workers is 23% slower on 8 cores

Two things fall out of that table. First, render time is linear in duration: 150 frames took 11.7 s, 1800 frames took 68.7 s — the same ~26 frames per second of output either way (we only measured one composition, so treat "per frame" as roughly constant, not proven constant). Second, the "three minutes to your first video" claim is real, but it is scaffold time, not authoring time: 116 s of install + 6 s of skills + 40 s of cold render ≈ 162 s, and the npm install is two-thirds of it.

A note on the install command, because half the articles online get it wrong. Remotion's own docs now say npx remotion skills add. The generic installer also works: npx skills add remotion-dev/skills -a claude-code -y. They write to different directories — the first put 12 skills in .agents/skills/ and created a skills-lock.json; the second put 12 skills in .claude/skills/. If your agent "can't see the skills", check which directory got them before you debug anything else.

4. What the skills actually cost you in context

People assume installing agent skills means stuffing a manual into the prompt. It doesn't, and the numbers are worth knowing:

Measurement	Value
Skills installed	12
Frontmatter (`name` + `description`) of all 12	1,031 chars ≈ 290 tokens — this is the always-visible part
Full `SKILL.md` bodies, all 12	43 KB ≈ 12k tokens, read on demand
Support files (docs, example `.tsx`, SVGs, map data)	285 files / 2.3 MB — opened only if the agent asks

The biggest single skill is remotion-best-practices, whose SKILL.md is a 4.2 KB router: it tells the agent which of the other eleven references to load for the task at hand. That's the whole design — pay ~300 tokens up front, buy 12k tokens of API knowledge. It also means the failure mode is silent: if the router doesn't fire, the agent writes Remotion from memory and you get plausible-looking code that renders a black screen.

5. The cost model nobody writes down

Two numbers matter: license and compute. Compute you can measure (§3). License is where the surprise is.

	Remotion	HyperFrames
License	Source-available Remotion License	Apache 2.0
Free tier	Individuals and companies of up to 3 people; unlimited commercial use	No per-render fees, no commercial-use threshold
Paid tier	Company License: Creators $25/seat/mo, or Automators $0.01/render, $100/mo minimum	—
Render engine	Headless Chrome + FFmpeg	Headless Chrome + FFmpeg
Authoring	React components	HTML + CSS + seekable animation (GSAP, Lottie, Three.js, WAAPI…)

The threshold is the thing to read twice. A three-person studio is free. Hire a fourth person and you are, by the license's own terms, in Company License territory — and if you're building a product that renders videos for other people, that's the Automators plan at $0.01/render with a $100/month floor. For a tool that renders 50,000 personalized clips a month, $500 is fine. For a side project that renders nine, it is not.

HyperFrames is the escape hatch: Apache 2.0, same rendering mechanism, different authoring bet (HTML instead of React). Its README is blunt about the trade-off — "Remotion's bet is React components; HyperFrames' bet is plain HTML that humans and agents can both write easily."

For the token side, one datapoint rather than a claim: NiharDaily's October 2026 hands-on reports $0.13 in model cost for a first prompt-to-MP4 run in Claude Code. Treat that as an order of magnitude, not a benchmark — it depends entirely on how many times the agent renders, reads a frame, and iterates.

6. Where it actually breaks

This is the section that decides whether you ship or abandon, and it's the part the tutorials skip.

The verification gap. "It compiles" is not "it looks good." An agent can run remotion render and get a green exit code from a composition where the text is white on white, the logo is cropped, or the animation finished at frame 12. Digital Applied calls this the hardest self-verification problem in the agentic toolchain, and they're right: there is no unit test for "does this look right", and the visual-regression tooling that exists measures pixel differences, not intent.

Practical workarounds, in order of usefulness:

Give the agent a component library, not a blank canvas. Improvised motion is exactly where AI video looks cheap. If it composes <LowerThird/> and <StatCard/> instead of inventing springs, the floor on quality rises enormously.
Make it render stills, not videos, while iterating. npx remotion still MyComp out/f.png --frame=45 took 6.7 s; a full 5-second render takes 11.7 s and a 60-second one takes 68.7 s. Bundling is a fixed ~5 s cost, so the longer your composition, the more the still saves — and it catches most layout errors.
Have it read the frame back. Agents with vision can open out/frame.png. Without this, you are the verification loop.

Everything else that bites:

Your first render is not your render time. Headless Chrome download alone is most of the 40 s. Budget for it in CI warm-up, not in your demo.
Fonts and media load asynchronously. A frame screenshot that races an image decode is a flaky test you'll spend a day on. Local assets, not CDN URLs.
Long videos stay linear. 10 minutes at 1080p is ~11 minutes of render on this machine. That's fine locally, unacceptable in a request handler — this is what Remotion Lambda and HyperFrames' Lambda path exist for.
The license threshold is a headcount trigger, not a usage trigger. Track it before legal does.
Auto-generated is visible. If you can tell a video was made from a prompt, the tool didn't fail; the brief did.

7. When to use which

You need	Use
Motion graphics, explainers, charts, lower-thirds, data-driven or parameterized clips	Video as code (Remotion / HyperFrames)
Photoreal footage, people, b-roll, "a rainy street in Osaka"	A generative model (Veo 3.1 / Gemini Omni Flash), then assemble in code
A talking head	An avatar product; neither of the above
10,000 personalized variants of one template	Video as code + Lambda; this is the killer use case
One 30-second promo, once	Neither. Open an editor.

The honest framing: video as code is not a cheaper way to make the video you were going to make in Premiere. It's a way to make videos that didn't exist as a category before — one per customer, one per data update, one per pull request.

8. Checklist before you commit

[ ] Decide the authoring surface first (React vs HTML). Migrating later is a rewrite, not a refactor.
[ ] Read the license terms against your current headcount, not next year's.
[ ] Ship a component library on day one; never let the agent invent motion.
[ ] Use remotion still (or render --frames=0-59) for iteration; full render only on merge.
[ ] Keep media local; pin fonts.
[ ] Put a human on frame review — that loop is the product.
[ ] Measure render seconds per output second on your box; ours was 26 fps of output at 1080p.

Sources

Remotion docs — Coding Agents: https://www.remotion.dev/docs/ai/coding-agents
Remotion docs — Agent Skills (12 skills, installers): https://www.remotion.dev/docs/ai/skills
Remotion — license and pricing: https://www.remotion.pro/license
HyperFrames — repository and README (determinism, Apache 2.0, comparison table): https://github.com/heygen-com/hyperframes
HyperFrames — docs: https://hyperframes.heygen.com
HeyGen Research — HTML to Video Was Not Easy: Here's How We Solved It, James Russo, 2026-06-22: https://www.heygen.com/research/html-to-video
Digital Applied — Video as Code: Remotion and the Agent Feedback Gap, 2026-08-11: https://www.digitalapplied.com/blog/video-as-code-remotion-agentic-generation-2026
NiharDaily — Claude Code and Remotion: install the skill, render a video, 2026-10-17: https://www.nihardaily.com/posts/claude-code-and-remotion-install-the-skill-render-a-video
snapcn — Claude Code + Remotion, 2026-09-24: https://snapcn.dev/claude-code-remotion-videos
VEED — open-edit, agent-driven editing pipeline: https://github.com/veedstudio/open-edit

Your coding agents don't need more messages — they need a handoff contract

tia-forge — Sun, 25 Oct 2026 04:56:58 +0000

I run several coding agents at once. The part that keeps costing me time is not the code they write — it is the note I hand from one to the next.

When I write that note by hand, I write what hurts: "CSV export loses the filters." That sentence is accurate and completely useless to an executor. It does not say which revision to start from, which command reproduces it, what output counts as correct, or who is allowed to say it is done.

That is the whole thesis of this post, and it comes from four October 2026 write-ups by people who hit the same wall. Everything factual below is theirs; I reproduced none of it, so treat the numbers as claims with sources. Sources and disclosures are at the end.

A ticket describes the symptom. A contract describes the job.

The author of the first write-up puts it in one line: a ticket can accurately describe a bug while leaving the executor unable to start.

His framing is more useful than a tool comparison, because it applies before any tool enters the picture: compare responsibilities, not labels. A task tracker can be part of a well-managed execution system. An agent runner can be badly managed. The difference is whether the handoff specifies four things.

Dimension	The question it must answer	How it usually gets faked
Context	Which exact starting revision? Which behavior, constraints, allowed files?	"Just change it on main"; a long conversation instead of a short, current spec
Runner	Who is the authorized operator? Is the environment actually ready?	Naming an agent when nobody installed the deps or can grant repo access
Evidence	Patch revision, commands actually run, results, and untested cases?	`"done"` — a state label, not a verification record
Acceptance	Who decides the result satisfies the requirement?	The executor quietly swapping the requirement for an easier reading

Note the asymmetry: three of these four are things an agent cannot invent for itself. Acceptance in particular has to be a person or a role that is not the implementer, which is why "the agent said it was done" is not a verification story.

The template

The original template is for a CSV repair. Here it is generalized, with the author's own warning intact: values in angle brackets must come from the real project, and command names must not be invented.

task:      Preserve the selected filters in CSV export
context:
  repository:    <authorized repository>
  base_revision: <verified commit>
  reproduction:  Select status=open, then export CSV
  expected:      Export contains exactly the rows matching the filter
  fixtures:      <sanitized fixture path>
scope:
  allowed:  Export query and focused regression coverage
  excluded: Authentication, schema migrations, unrelated UI changes
execution:
  operator:      <developer or authorized agent operator>
  setup_command: <verified command from this repository>
  test_command:  <verified command from this repository>
  permissions:   Existing authorized development access only
delivery:
  patch_revision:        required
  commands_and_results:  required
  sample_output:         sanitized CSV from the fixture
  untested_cases:        required, even when empty
acceptance:
  product_owner: Confirms filtering semantics
  engineer:      Reviews implementation and regression evidence

Three rules ride along with it, and the second one is the one people break in a hurry:

Do not paste credentials into the contract. The executor uses their own authorized tools and access.
An unavailable environment is an execution blocker, not an invitation to share an account.
The template is a proposed operating practice — not evidence that any platform fills in every field automatically.

untested_cases: required, even when empty deserves its own sentence. Empty and "none" are different claims: the first is missing information, the second is a checkable statement.

What one handoff actually looks like

The walkthrough in the source is worth keeping whole, because it shows where a human belongs:

The product owner builds a fixture: three records, two open and one closed. The expected filtered export is exactly two rows.
An engineer confirms the behavior and points at the export path.
The executor first reproduces the failure at the recorded revision. If it does not reproduce, the next useful delivery is not a patch — it is the attempted command, environment details, and observed output. Editing before resolving that mismatch risks fixing a different problem.
Only then: a scoped change, plus coverage for the filtered export. The unfiltered export gets checked too, because repairing one path can silently narrow the other.
The delivery attaches the patch revision and the real output of the verified test command.
Two reviewers, separately: the engineer reads the diff and the regression evidence; the product owner looks at the sanitized sample and confirms that "filtered" means what users think it means.
If either review fails, the same task records the reason and the next attempt.

Honest note from the original: those are proposed checks. No passing results were claimed. That restraint is part of the standard, not a weakness of the article.

The portable version: five fields, five sections of evidence

The follow-up post targets a messier reality: one teammate uses a terminal agent, another uses an editor assistant. What transfers between them is the task contract — inputs, allowed changes, required evidence, a reviewer. Conversation history is optional context.

outcome:    reject invalid worker-count configuration before startup
scope:
  allowed:  config parser and focused parser tests
  excluded: deployment, credentials, queue architecture
inputs:
  revision:     record the real base commit
  config_key:   replace with the actual key
  reproduction: supply a synthetic invalid value
acceptance:
  - omitted value preserves the current default
  - valid positive integer preserves behavior
  - zero, negative, and non-integer values are rejected
  - error names the key without printing secret configuration
stop_when:
  - the parser contract conflicts with documented behavior
  - the change requires a production configuration update
  - unrelated failures prevent a trustworthy comparison

stop_when is the field I stole immediately. It gives the executor permission to stop and a reason to record, which is exactly what you want from an autonomous worker that is about to guess.

The evidence protocol is five lines:

Before:      command, exit code, observed output, base revision
Change:      files and the reason each file is necessary
After:       same reproduction, focused tests, actual exit codes
Uncertainty: checks not run, and why
Review:      commit reference and named acceptance owner

Two sentences from that post are worth pinning above a desk:

"The model says validation is fixed" is a hypothesis. A command and its output are evidence that a check ran.

…and the reviewer still has to judge whether that check covers the intended failure.

Two gates that get skipped:

Eligibility comes before capability. Access is a gate: the runner must already be authorized. A teammate with a strong model and no repository permission is not eligible just because someone could paste them a token.
Honest non-results. In the article's example the executor discovers that a worker count of zero deliberately means automatic sizing. The correct move is to stop, return the fact, and revise the requirement — not to change working behavior to satisfy an invented test.

Pre-acceptance checks: verify the recorded revision, reproduce the named cases, look for accidental configuration disclosure in the error message, and confirm no deployment or unrelated cleanup slipped into the diff.

Making the handoff an object (and holding the writes)

The third write-up takes the opposite route: no template, a document model.

Its observation is blunt — passing messages between agents is straightforward; keeping track of requirements, decisions, results, validation, and unfinished work is not. A research agent handing off to a coding agent cannot send a summary: the receiver needs the original requirements, the constraints, the decisions already made, the results, the open questions, and the next steps.

So Work Order in, Work Report back, with one model and one set of validation rules behind three entry points — a TypeScript package, an MCP server (so Claude Code and friends can create/accept/report/review through tools), and a Python implementation that runs the same shared test cases and reports the same findings for the same documents.

The interesting part is the MCP gateway in the middle. The worker does not touch real tools directly; every call goes through the gateway, which enforces that order's allowed tools and budget on each call and records the call as evidence.

Version 0.7 added a side-effect gate — staged tools:

Reads pass through, writes are held, and only an approval makes them run — once. (Image: the source post at dev.to, rehosted.)

Mechanics worth copying:

Reads run normally. Only staged calls wait, so the worker can still research.
Writes are held. The gateway counts and logs the call with its arguments but does not forward it; the worker gets a placeholder like pending:gmail/send#3 and lists it under effects in its report.
The manager decides. Approve → the gateway runs the held calls once, in order. Send it back → they are dropped, and nothing has to be undone because nothing ran.

Four details the author says only showed up in real workflows:

Partial approval. Approve the work but run only chosen effects: effects: ["gmail/send#3"].
Dependent effects. A later held call can reference an earlier one — {"$ref": "github/create_issue#3", "pointer": "/structuredContent/number"} — and the gateway fills it in at execution time.
At most once, by reconciliation. Before running anything, the gateway checks every effect in the report against what it actually logged. Mismatch → nothing runs. Re-running --commit never double-sends, even after a crash.
Sub-agents cannot route around it. A worker cannot hand a staged tool to a sub-agent: the sub-agent's writes would execute when the worker approves, before the manager has seen anything.

There is also progress() for in-flight notes and trackRecord() — a worker's history of first-time approvals, rework, failures, expiries, and budget spent. Judge a worker by that, not by its self-report.

Disclosure: the author is building these packages, so read it as "someone doing the thing", not neutral review.

The ledger: derive health, never store it

Writing a contract solves what to hand over. The Agent Board write-up solves the other half: whether you can still see the whole board afterwards.

The problem statement is three questions you cannot answer when agents run in parallel: is it still working, is it stuck, and how much of the subscription is it burning? The original requirement was blunter — one always-accurate page. The author then names why that is hard: this is a distributed systems problem. Agents start and die outside any single process, report asynchronously, and lie by omission when they crash.

His answer: the board is a projection; the ledger is the only source of truth. Four invariants:

Register before spawn. The task row exists before the process does, so nothing started through the supported path can run unrecorded.
Unknown stays unknown. No estimated percentages, no inferred exit codes, no guessed usage. A Claude session without a reliable PID shows unknown and its Stop button is disabled.
Derive, do not store, health. Status is a fact written by a producer; health is computed at read time from status plus idle time.
Never block the agent. Instrumentation fails open: a busy ledger drops an event rather than adding latency.

Three producers, one append-only ledger

Launch wrapper. Writes the row, then spawns the agent in JSON-event mode; heartbeats every 15 s while the child lives; records the exit code; a spawn failure is recorded as failed with exit 127 instead of vanishing; signal forwarding is installed before the prompt is sent, so stop reaches the child. A test asserts the ordering: a fake agent blocks before its first event while the test polls the ledger and asserts the row already exists.
Lifecycle hooks. Session start/stop, prompt submit, helper start/stop, tool events before and after each call. Lifecycle hooks run synchronously, tool hooks asynchronously. Each hook gets a 25 ms lock wait and a 150 ms work budget, targeting an exit under 200 ms; on timeout it logs and drops the event; it always exits zero and never writes to stdout — anything printed would be injected into the agent's context.
Reconciler, every 5 s. A running task whose process is gone with no exit becomes lost. A running task idle for more than 600 s becomes stalled, flipping back on the next event. It also scans the process table for Codex processes that never went through the wrapper, walks up to three parent levels to avoid double counting, and records them as untracked, keyed by PID.

Seven statuses; health is a read-time function, so the board cannot drift from the ledger. (Redrawn from the source's section 5.)

Progress exists only when there is a denominator

My favourite rule in the whole write-up: percent complete is shown only when a denominator was declared. Runs launched with a step count ask the agent to emit PROGRESS n/total, parsed from messages; Claude tasks report checklist items; everything else says "progress not reported". Even then it is the agent's own claim — the timeline is the evidence.

Admission control: one writer, two slots

Concurrency per repository is bounded by kernel advisory locks, with the lock root derived from a hash of the checkout path. A writing run takes an exclusive writer lock, then one of two slot locks, tried without blocking. No sentinel files, no sleeps, no polling loops — a crashed holder releases when the kernel closes the file.

The cap of two came from evidence, not taste: on day one, with everything at high effort, the Codex weekly allowance dropped to 11% left, and a third concurrent stream stalled while two ran. Runs also carry a token budget — 40 million by default — counted from the agent's own token events; over budget, the run is stopped and exits 125.

What the ledger actually recorded (2026-09-08 → 10-23)

Measure	Value
Task rows / events	28,149 / 540,175
By source	8,331 Codex, 7,267 Claude sessions, 12,373 Claude helpers, 178 other
Wrapper-launched Codex runs	1,380 done, 116 failed, 267 lost
Codex processes found outside the wrapper	6,568 — all ended as lost
Mean wall time, done runs	7.95 min over 803 runs
Review verdicts	160 APPROVE, 337 FIX, 87 INVALID
Tests	188 methods in 22 Python files + 12 browser scripts

The largest number is the useful one: most Codex rows were never launched by the wrapper at all. They are processes the reconciler caught running on their own, recorded as untracked, then lost. That is the detector working — and a measure of how much agent activity is otherwise invisible.

Five failures worth stealing

The kill chain reaction. Killing a reviewer produced a signal exit → parsed as INVALID → triggered the fix loop → spawned a new worker and a new review. Each kill produced two or three more tasks. Fix: a reviewer stopped by a signal ends the chain with a STOPPED verdict.
Budget burn, itemized. Day one: 36 tasks, ~24 agent hours in 36 hours, all high effort. The breakdown: re-reading context ~25%, oversized command output 18%, repeated aggregate verification 12%, high effort on routine work 12%. Roles, bounded packets, a release window and the two-run cap all came out of that.
Phantom helpers. Helpers that never closed showed as stalled for hundreds of hours and flooded the view. Aggregation by project plus a 15-minute idle cutoff replaced one sprite per helper.
Lock contention. Builds in the board's own repo failed with database is locked while a rendering service held the ledger. Operating rule: pause that service during builds.
Ready before verified. UI work was reported ready before anyone opened it in a real browser with real data. New rule: no UI is ready until someone has looked at a screenshot.

The review gate: packet, grammar, one fix round

Implementation runs as the role worker, followed by an isolated review. The reviewer gets a packet, not a conversation: the task-local diff, at most 200 lines of test output, the worker report, and the path to the original brief — inside a 256 KB budget. When the budget is tight, unchanged context and non-test file bodies are dropped, with recovery paths the reviewer can open.

The verdict grammar is strict: exactly APPROVE, or a numbered list of fixes. Anything else is classified INVALID. A FIX returns to the worker once; a second review follows; still unresolved → exit 2, surfaced in a human queue. Nothing escalates automatically. Reviewers can be two different models, in which case both must approve and disagreements are labelled.

584 verdicts on record: 160 APPROVE, 337 FIX, 87 INVALID. Fix requests outnumber approvals two to one — and the author says that is the point of the loop, not a bad sign.

The human queue is computed, not curated, from five sources (tasks failed in the last two hours, reviews still asking for changes, manually raised needs, needs raised by a live Claude session, work items waiting on the owner), with three suppression rules (acknowledged after the latest signal; a later run in the same directory or with the same title succeeded; dedupe per task, keep the newest signal). Display cap: five per lane. In the author's words — needs you, maximum five, real and current only.

Where the "discussion" part goes wrong

Handoffs are half the problem. The other half is agents disagreeing about a plan.

A vendor write-up (CEO's column, so read it as an argument) describes a consensus cycle: agents share draft plans, surface conflicts, revise, repeat. It settles many disagreements — and when it cannot, the system escalates to a human. Then the important observation: the safe thing has a cost curve. One team escalating occasionally is governance; fifty teams escalating every unresolved disagreement is a flooded queue, and flooded people approve by default. That is automation bias (Parasuraman & Manzey 2010; the EU AI Act names it in Article 14). A rubber stamp and a working control produce the same output while conditions are normal.

So the constraint is not agent capacity — that is cheap and getting cheaper. It is the handful of people who understand the operation well enough to settle an argument.

The triage that follows is the part I actually use. Take the last twenty decisions your team pushed to a person and sort them:

Pile one: the parties disagreed about what will happen — different data, different history, different confidence in the same lever. This pile does not need a person's judgement; it needs both parties to see the same evidence.
Pile two: they agreed on what will happen and disagreed about what to want — throughput against energy cost, this customer's order against that one's. This pile is where a person's day should go.

If your queue is mostly pile one, you are running an evidence problem through a governance process, and adding approvers will not fix it.

The proposed split is clean: agents strategize, mathematics closes the deal. Each agent decides only two things — eight weights over delivery slots, and a walk-away floor:

U(o) = w1·u1(o1) + w2·u2(o2) + … + w8·u8(o8)   accept only if U(o) ≥ r

The agreement itself is produced by a bargaining engine running alternating offers. No language model makes an offer, concedes a point, or declares a deal; the same positions in produce the same agreement out, auditable to the individual offer, settling in about a second — and when there is genuinely nothing to trade, the agents walk away, which is also correct.

That gives you a third stage between "force consensus" and "page a human": a mediator proposes candidate settlements, filtered so nothing breaching a constraint is ever offered; each agent judges only whether a candidate beats the one on the table, and any agent can veto — without revealing its weights. What reaches the person is not two drafts and a deadlock notice, but a short list of what could not be settled and who vetoed what.

The companion piece on roles adds four short rules that keep a "team" from becoming a demo:

A role is one job and one checkable output. "Research competitors and return a claims table with a source column" is a role. "Help with marketing" is not.
Boundaries belong in tools, not prompts. A reviewer reads the diff and posts comments; it cannot merge. Instructions can be ignored or misread; a missing tool cannot be used.
Make the handoff explicit: name the artefact, the reason it moved, and what the receiver must check — and log the handoff, so you can see where a decision changed hands.
Cap the coordinator: max reassignments, a time limit, and a rule for what happens after a task fails twice. It should also point at evidence per task, not "all complete".

And the sequencing advice I keep repeating to myself: start with two roles and one handoff, and get it boring before adding a third.

Putting the three layers together

Handoff contract for the next agent; ledger for the machine; gate before side effects. (Drawn by the author from the four sources above.)

Layer	Artifact	Written by	Read by	If missing
Handoff	`HANDOFF.md` (five fields + five evidence sections)	Upstream owner or upstream agent	The next agent's start script	The next agent guesses, or asks you — which is where we started
Ledger	`tasks.tsv` or SQLite, append-only	Wrapper, hooks, reconciler	Board, gates, coordinator	No answer to "who is running, stuck how long, spent what"; crashes lie by omission
Gate	Review packet + verdict + approval	Independent reviewer or authorized human	Merge, deploy, anything with consequences	You reject the report after the email has already gone out

Three things actually get automated here — none of them is "make the model smarter":

Generate the contract at the end of the upstream task: template plus a validator that checks the four fields are present, acceptor ≠ implementer, and base_commit actually exists.
Consume the contract at the start of the downstream task: the launcher injects HANDOFF.md into the first turn, instead of you pasting it into a chat box.
Gate before the side effect: not "reject the report afterwards", but "hold the write until approved". That is exactly why staged tools matters — a rejection leaves nothing to undo.

A three-week rollout with pass/fail criteria

Week 1 — contract plus validator. HANDOFF.md in the repo, a ~30-line script. Pass: ten consecutive tasks where no downstream agent comes back asking for missing information.

Week 2 — wrapper plus reconciler. Register the row before spawn; heartbeat every 15 s; mark lost when a PID disappears without an exit; mark stalled past 10 minutes idle. Pass: you can answer "who is running, stuck how long, spent what" at any moment, and unknown was never silently filled with 0.

Week 3 — reviewer plus grammar plus one fix round. Packet, not conversation; verdicts limited to APPROVE or a numbered list; a single fix round; a human queue capped at five. Pass: the fix/approve ratio is stable, and the queue stays under five — if it does not, fix the process before adding approvers.

The discussion layer goes after week 2: give plans an independent read-only reviewer, cap the loop at two rounds, and escalate — otherwise you build the flooded approver from the previous section.

Cautions

The ledger only covers runs that go through the wrapper. Those 6,568 outside processes are the proof: you must assume a share of activity is invisible.
Heartbeats prove liveness, not progress.
Lifecycle hooks cannot get a reliable PID for Claude sessions, so the board cannot stop them; progress counts are self-reported; budgets come from the agent's own token events.
A strict verdict grammar has a price: 87 of 584 verdicts were INVALID (~15%). Watch what INVALID looks like, or you will fix formatting instead of behaviour.
Locking collides with builds (database is locked); the rule is to pause the lock holder during builds.
"Ready before verified" is the most common self-deception; for UI, nobody has verified it until someone looked at a screenshot with real data.
Never put credentials in a handoff contract.
The four fields prevent "cannot start". They do not prevent "did it wrong" — that needs the evidence package and the acceptor. Do not merge the two jobs.
Thresholds quoted here (256 KB packet, 200 log lines, 15 s heartbeat, 10 min idle, 40 M tokens, two slots) are one operator's values, not universal standards — recalibrate for your repo and budget.

Sources

A task record is not an execution contract: a handoff template for coding agents, dev.to, 2026-10-12 — https://dev.to/hiroshi_takamura_c851fe71/a-task-record-is-not-an-execution-contract-a-handoff-template-for-coding-agents-4bp8
A portable handoff contract for teammates using different AI tools, dev.to, 2026-10-15 — https://dev.to/hiroshi_takamura_c851fe71/a-portable-handoff-contract-for-teammates-using-different-ai-tools-4ige
Stop AI Agents from Acting Before You Approve: Work Orders for TypeScript, Python and MCP, dev.to, 2026-10-16 — https://dev.to/murthyg/how-to-build-reliable-work-handoffs-between-ai-agents-in-typescript-1neh
Sam Ochoa, Agent Board: coordinating concurrent AI coding agents with a shared task ledger (WP-05), 2026-10-23 — https://samuelochoa.com/papers/agent-board/
Pieter van Schalkwyk, Should Multi-Agent Systems Negotiate?, XMPro, 2026-10-19 — https://xmpro.com/should-multi-agent-systems-negotiate/
Running a Team of AI Agents: Roles, Boundaries, and the Handoffs That Break, dev.to, 2026-10-24 — https://dev.to/flisk/running-a-team-of-ai-agents-roles-boundaries-and-the-handoffs-that-break-4fe9

Disclosures. The first two posts disclose AI assistance in drafting and state that the worked example was not run against a production repository, and reference a vendor's product page for the workflow model. The third is written by the author of the packages it describes. Agent Board is one operator's single-machine record (its own limitations section applies). The negotiation piece is a vendor CEO's column. Nothing here was independently reproduced by me.

A longer Chinese version with the field-level contracts, the seven-state machine and the full failure list lives at hubwiz.com/blog.

One machine, ten coding agents: giving each one its own identity

tia-forge — Sat, 24 Oct 2026 06:14:27 +0000

"An agent did it" stops being an answer the moment you run more than one.

On a single developer machine you can now have Claude Code, Codex, OpenCode, Copilot, Antigravity, or pi all working in the same repo, sometimes in the same hour. The default setup — one git config user.name, one GitHub login, one .env — works fine right up until something goes wrong and you have to answer a question that has no answer: which agent wrote this, and what was it allowed to touch?

This post compiles five write-ups from September–October 2026 where teams actually did this, including the mistakes. Everything below is attributed at the end; nothing here was reproduced by me, so treat the numbers as claims with sources rather than verified facts.

The cost of one shared identity

Vitruvian Software runs ten agents in one monorepo — Forge on Bazel, Atlas on infrastructure, Ridge on Kubernetes, Wren on application code, Scout on tests and CI, Aegis on security review, Quill on docs. Until recently, GitHub saw all of them as one person: every push, PR, and merge went out under the repository owner's account.

That looked harmless and cost them three things:

What you think you have	What you actually get
Attribution	"Ridge opened #1440" is a claim in a chat log. Neither git nor GitHub can back it up.
Peer review	GitHub blocks self-approval, and every PR looks self-authored — so a security agent cannot give a valid approval on an infra agent's diff.
Audit	The trail says one human did everything, including work that human never saw.

The second one is the one that hurts. If you want agents to check each other, the platform has to believe they are different identities. With one identity, the best you can do is have an agent leave a comment and hope someone reads it.

Layer 1 — Git: a token decides who can push, an environment variable decides who signed

This is the failure that silently corrupts history, and it is easy to miss.

# 1) who pushes (API + git push)
export GH_TOKEN="<installation token>"

# 2) who is named in the commit — completely independent of the token
export GIT_AUTHOR_NAME="vitruvian-wren-agent[bot]"
export GIT_AUTHOR_EMAIL="<bot_user_id>+vitruvian-wren-agent[bot]@users.noreply.github.com"
export GIT_COMMITTER_NAME="$GIT_AUTHOR_NAME"
export GIT_COMMITTER_EMAIL="$GIT_AUTHOR_EMAIL"

Vitruvian set only the token first. Result: the PR showed the bot, and the commit log still showed the machine owner — because git takes authorship from local config and environment, not from whoever pushes.

Three details worth copying:

Use the bot's noreply address. GitHub ties it to the App, so commits link back to xxx[bot].
One-hour installation tokens are a feature. The only long-lived secret is the private key, which lives in a vault; the token is minted per session and never pasted anywhere.
Set both GIT_AUTHOR_* and GIT_COMMITTER_*. Change only the author and a rebase or cherry-pick leaks the real operator into the committer field.

Layer 2 — Platform: GitHub Apps, not one bot account per agent

The obvious fix is a machine user per agent. GitHub's terms allow one free machine account per person, so ten agents would mean ten accounts the terms don't cover plus ten sets of credentials to rotate. GitHub Apps have no such limit: an org can own as many as it likes, each gets a real name[bot] identity that genuinely authors commits and submits reviews, and each authenticates with short-lived installation tokens instead of passwords or PATs. They named them vitruvian-<agent>-agent.

The question the docs don't answer

Before building, they needed to know whether an App's approval counts toward a require 1 approving review rule. The docs on protected branches say approvals come from "people with write permissions" or a designated code owner — Apps aren't mentioned either way.

So they measured it on a canary repo with required_approving_review_count: 1 and enforce_admins: true:

before   reviewDecision=REVIEW_REQUIRED  mergeable_state=blocked
POST /pulls/1/reviews   event=APPROVE   (App installation token)
after    reviewDecision=APPROVED         mergeable_state=unstable
         review  <app-slug>[bot]  type=Bot  state=APPROVED

It counts. (unstable was an unrelated pending check.) One limit surfaced: an App cannot be a code owner — CODEOWNERS accepts users, teams, and email addresses only. So they turned off "require code owner review" and used the approval count as the lever.

The step you cannot automate

App creation has no API. You either fill in a web form or use the App manifest flow, which is better because it returns the private key in an API response instead of a browser download:

{
  "name": "vitruvian-<agent>-agent",
  "public": false,
  "default_permissions": {
    "contents": "write",
    "pull_requests": "write",
    "metadata": "read",
    "checks": "read",
    "workflows": "write"
  },
  "default_events": []
}

GitHub redirects back with a one-time code you exchange within the hour for the App id and private key. That is the only copy of the key: straight into the vault, response deleted.

Two traps: the install screen preselects "All repositories" (accept it and every agent can write to every repo in the org — choose "Only select repositories"), and workflows: write is only for agents that should touch CI.

Make "who can write where" reviewable

repo_config:agentApps:
  - name: beacon
    installationId: "152031070"
  # ...one entry per agent
repo_config:requiredApprovals: "1"

Pinning each App's installation to the repo turns authorization into a diff you review, not a checkbox on a settings page nobody opens.

And ordering matters. requiredApprovals: "1" must be last. Enable required reviews before the agents have identities and there is nobody who can approve: every PR waits at REVIEW_REQUIRED forever, and release-please / Dependabot auto-merges get stuck too, because a ruleset bypass covers direct merges but never auto-merge into a merge queue.

Safe order: create and install one App per agent → put keys in the vault and point each harness at its key → add every agent to agentApps → then raise requiredApprovals.

Day to day, an agent takes on its identity with one command:

eval "$(bazel run //tools/agent-app -- env wren)"

It looks the agent up in a committed registry (App ids, installation ids, bot user ids are all public identifiers), signs a JWT, exchanges it for an installation token, and exports both the token and the git identity.

Layer 3 — Inside the commit: who writes the three lines

A git author field holds a name and an email. It cannot hold "which job, which tool, which model". Obi (a Rust agent execution engine) appends three trailers instead:

Oby-Job: 3f2a9c1e
Oby-Agent: Codex
Oby-Model: gpt-6.1-sol

Now a teammate reading git log can tell which code an agent wrote and with what, without asking the owner — and the owner can query a model's track record:

git log --grep "Oby-Model: gpt-6.1-sol"

Why the engine must write them, not the agent

This is the most transferable idea in the whole design:

trailers are written during keep_commits, when a finished job's commits are packed back into the engine's clone;
each new commit is rewritten directly — read the raw object with git cat-file commit, repoint parents, append the trailers, write the new object with git hash-object -t commit -w --stdin;
deliberately not git commit-tree or git interpret-trailers, which read commit.gpgSign / trailer.* and can change the bytes;
tree, author, committer, and both dates stay exactly as they were;
if the agent wrote Oby-* lines itself, they are removed first — only the engine gets to say this;
writing the same trailers twice produces the same commit id (idempotent).

Two more choices: Oby-Agent records the tool (Claude Code, Codex, Cursor), not an account; and nothing ever records an account name, email, or hostname, because commits can be public.

Compare with "make the agent add a Co-authored-by line": the agent can forget, can get it wrong, and can be talked out of it by an injected instruction. Attribution written by a layer that does not reason is attribution you can trust.

Layer 4 — Granularity: one action, one commit

Orquesta takes the other route: don't rewrite trailers, make every action a commit. Their argument is that today's tools either dump changes into the working tree or produce one mega-commit at the end ("AI refactor") — and that isn't traceability, it's a black box with a receipt.

The mechanism:

the agent works on a real branch cut from base;
every file edit, code-changing shell command, and test-fix cycle is committed, with a Conventional-Commits-style message;
the author field is the agent, via a separate git config:

git config user.name  "Orquesta Agent"
git config user.email "agent@orquesta.local"

read-only commands produce no commit (nothing changed), but they are logged in the activity feed.

The payoff is surgical rollback: when an agent both adds an endpoint and fixes an unrelated bug in one session, and the endpoint regresses, you revert one commit and keep the fix. Noise is handled by asking the agent to combine logically identical changes, plus a squash step before merge — granularity during execution, clean history after.

Layer 5 — Process and credentials: give a key to exactly one agent

Identity is not just a name; it is what the process can read.

Bill Mongan runs nine agents side by side on a small always-on Ubuntu box (~14 GiB RAM): Claude Code, Codex, Antigravity, Grok Build, Hermes, GitHub Copilot, two separate copies of OpenCode, and pi. Herdr (an agent-aware terminal multiplexer) gives each one a labelled tab and its own directory under ~/agents/<name>.

That directory separation matters more than expected: most CLIs resolve "resume the latest conversation" relative to the current directory, and several ask you to trust a workspace before touching it. One directory per agent keeps histories, trust decisions, and scratch files apart.

Most agents share a single mcpproxy instance for tools. One tool talks to a service that needs a personal API key, and only one agent should hold it. The trick:

the provider declares the secret both as a server-side env var and as a caller-supplied header;
the proxy's .env gets the base URL only, and the key is left unset — so the proxy has no credential to hand out;
the key lives in one scoped OpenCode's private env file and is forwarded as a header:

"mcp": { "servers": { "mcpproxy": {
  "type": "remote",
  "url": "http://127.0.0.1:8888/mcp",
  "oauth": false,
  "headers": { "X-MCPProxy-Service-Key": "{env:SERVICE_API_KEY}" }
}}}

the launcher is a small wrapper: set -a; source service.env; set +a; exec opencode. set -a exports every assignment, exec avoids leaving a shell process holding a copy — so the variable exists in that process tree and nowhere else.

Other agents can still see the tool; their calls simply fail to authenticate. When they need the capability, they delegate the task to the scoped agent instead of holding the key.

And the author is explicit that this is not a hard boundary

any agent with a shell, running as the same Unix user, can read that service.env;
the header travels over plain HTTP, acceptable only because the proxy listens on loopback;
real isolation between agents would mean separate Unix users or containers.

So: least privilege by process environment, not a security boundary — and not treated as one. Its value is that other agents can't use the key by accident, and can't leak it through a tool that dumps environment variables.

What identity does not stop

Be clear about this, or you'll think you're done. Vitruvian published two incidents from their own setup:

Incident	What happened	Fix
Merge queue bypass	`main` let repo admins skip the merge queue as a human emergency path. Agent sessions under that account inherited the bypass: 5 of 40 merges skipped the queue in two days; one of them had been rejected by the queue eight minutes earlier, and main went red.	A pre-tool hook refuses `gh pr merge --admin`, direct merges via REST/GraphQL, and pushes to `main` — and tells the agent to fix what the queue rejected. A human who really needs the bypass runs it in their own terminal, where the hook doesn't apply.
The worktree that uninstalled Argo CD	The homelab Pulumi config is gitignored, so it doesn't exist in a worktree → every toggle read `false` → one `pulumi up` removed Argo CD, its namespace, and every Application it managed.	The program now refuses to run unless the config states the setting explicitly; and "never apply from a worktree" lives in `AGENTS.md` next to the incident date.

Their conclusion is worth quoting in full:

Per-agent identity is a convention we keep, written into the AGENTS.md that every coding tool in the repo reads: use your own name; minting as another agent puts their name on your work. It makes honest work attributable and reviewable. It doesn't make dishonest work impossible.

What actually stops corner-cutting is the other layer: guardrails written after real incidents, where every fix ships with the check that would catch it again.

Safeguard's October write-up names the five risks of "running as you": excess authority, blind audit trails, prompt injection, credential reach (tokens in env vars and dotfiles are readable by anything you run), and long sessions that accumulate context and access. Their rollout advice is practical: start with the highest-risk accounts and tasks (production, releases, cloud admin), keep everyday coding in a sandbox but remove long-lived secrets — and remember that if a scoped token takes a day and a ticket, developers will keep using their own identity. Tooling matters as much as policy.

A weekend checklist (dependency order, not priority order)

Decide who appears in history. Give each agent its own GIT_AUTHOR_* / GIT_COMMITTER_* and a resolvable email. Ten minutes, immediate payoff: git log becomes readable.
Make the platform agree. One GitHub App per agent (manifest flow), key in a vault, installation tokens only, "Only select repositories".
Put attribution inside the commit. Either an engine that rewrites trailers (Obi) or one-commit-per-action with a distinct author (Orquesta). Do not rely on the agent to remember.
Narrow what the process can read. Per-agent config dirs and env files (mode 0600), header-injected or brokered credentials, nothing sensitive in a shared .env.
Raise required reviews last. After step 2, so a different identity can approve.
Write guardrails, not hopes. Incident date in AGENTS.md, every fix paired with a test that fails if it regresses, and "identity is attribution, not enforcement" as a stated design assumption.

If it's just you and three agents

The sources above are all team-scale. A lighter ladder:

Where you are	Smallest useful move	Why it's enough
Three agents on one `user.name`	per-agent `GIT_AUTHOR_` / `GIT_COMMITTER_` at launch	One hour to a readable `git log`, zero platform changes
You want them to review each other	trailers + branch prefixes (`agent/<name>/<topic>`)	Without platform identity, "peer review" is still human review; first make authorship legible
You want branch protection to actually bite	then GitHub Apps (or at least separate accounts)	"The platform accepts these are two identities" is the one thing env vars can't buy
You hold sensitive credentials	one config dir + one env file (0600) per agent	Keeps a key inside one process tree; the rest can't misuse it

A wrapper is enough to start:

# ~/bin/agent-run — usage: agent-run wren claude
agent-run() {
  local name="$1"; shift
  export GIT_AUTHOR_NAME="$name"
  export GIT_AUTHOR_EMAIL="$name@agents.local"
  export GIT_COMMITTER_NAME="$name"
  export GIT_COMMITTER_EMAIL="$name@agents.local"
  export PI_CODING_AGENT_DIR="$HOME/.pi/agents/$name"   # swap for your tool's config-dir variable
  exec "$@"
}

And one check that fails loudly when you got it wrong:

git log -1 --format='%an <%ae> | %cn <%ce>'   # expect the agent name, not yours

Boundaries

This is a compilation, not a reproduction. The App-approval measurement, the trailer rewriting, the git-native flow, and the nine-agent box all come from the authors' own environments.
Platform behaviour changes; "does an App approval count" and "can an App be a code owner" are both in the "not in the docs, measure it" category. Re-verify on a canary repo before relying on any number here.
Naming (vitruvian-*, Oby-*) is incidental. What transfers is the structure: who writes attribution, where it is stored, and which layer holds the credential.
Adjacent but different: sandboxing, egress limits, approval gates. Those answer "what can it do". This post answers "who does it count as".

Sources

Vitruvian Software, Every AI agent gets its own GitHub identity, 2026-10-09 — https://vitruviansoftware.dev/blog/2026/10/09/every-ai-agent-gets-its-own-github-identity/
Obi (obi-ai-bot/oby) issue #1068, obid: commits say which job, agent and model wrote them, 2026-10-22 — https://github.com/obi-ai-bot/oby/issues/1068
Orquesta, Git-Native AI Development: Every Action is a Commit, 2026-10-23 — https://getorquesta.com/blog/git-native-ai-development-every-action-is-a-commit-2026-10-23
William M. Mongan, Herding Agents: Multi-Agent Coordination with Herdr and Per-Agent MCP Credentials, 2026-10-04 — https://www.billmongan.com/posts/2026/10/herdr-multiagent-mcpproxy/
Safeguard Security Team, What are the identity risks when an AI coding agent runs as you, 2026-10-18 — https://safeguard.sh/resources/blog/when-your-ai-coding-agent-runs-as-you-identity-risks-and-fixes
Background: Sumant Thakur, I Ran Multiple Coding Agents. The Code Was the Easy Part., 2026-09-30 — https://sumantthakur.substack.com/p/multi-agent-coding-workflow

Chinese original (full version, with the platform-specific details): 多 Agent 同机：Git 作者、凭据与提交归属怎么分

More on this site (in Chinese): AI 编程 / Vibe Coding 完全指南 · Agent / MCP / 自动化完全指南

113 Siemens Ladder Instructions, One Page Each — and the Sections That Actually Save You Time

tia-forge — Thu, 22 Oct 2026 08:42:11 +0000

When you look up a ladder instruction mid-commissioning, the expensive part is never remembering what the symbol looks like. It's the next two questions: how is this different from the instruction next to it, and what happens if I pick the wrong one.

Learn-LAD's LAD instruction handbook answers exactly those. It's 113 S7-1200/1500 instructions in 13 groups, one page each, with a fixed seven-section structure per page: one-sentence summary, symbol and pins, minimal example, how it works (truth/timing table), typical uses, common pitfalls, related examples. Each page also carries an "try it in TIA" panel: pick an example block, and TiaLink imports it into the TIA Portal project you currently have open — pre-check first, no overwriting of same-named objects by default, no auto-save after import.

It is not a replacement for the TIA help. The help tells you what a pin is; this tells you which instruction to pick, and how it fails.

1. Where people actually get stuck

Everyone learns contacts, coils and timers once. The real problems show up later, and they cluster into four shapes:

Neighbours look identical. TON / TOF / TP are all "timers". SCoil and Sr both latch. The failure always happens between two instructions that resemble each other.
You know the definition, not the consequence. "ET resets when IN goes to 0" reads as trivia — until you use it as an accumulated run-time counter.
Parameter help stops at parameters. TIA help will tell you PT is the preset time. It won't warn you that a one-scan pulse never reaches PT.
You understand the page, then rebuild the network by hand — and introduce new mistakes in the rebuild.

So the useful test for any instruction reference is five criteria:

Criterion	Why it matters	What the handbook does
Pin table with directions	A flow input (RLO) is not a value input	Every page has one, labelled flow input / input / flow output / output
A minimal example	Definitions don't stick; a three-rung network does	Every page has a rendered ladder plus variable notes
Truth or timing table	"When is it 1" must be derivable scan by scan	Timers, counters and edges get state tables
"How it differs from its neighbour"	Misuse happens between lookalikes	A fixed "common pitfalls" section; its first line is usually "X is not Y"
Context	A single instruction is meaningless outside a program	Related examples graded basic/advanced/full, plus related instructions

2. Scale: 113 instructions, 13 groups

Group	Count	Representative instructions
Bit logic	7	Contact, Coil, SCoil, RCoil, Not, SBitfield, RBitfield
Flip-flops	2	Sr (set-dominant), Rs (reset-dominant)
Edge	8	PContact, NContact, PBox, NBox, PCoil, NCoil, R_TRIG, F_TRIG
Timers	10	TON, TOF, TP, TONR, CoilTON, CoilTOF, CoilTP, CoilTONR, PtCoil, ResetIECTimerCoil
Counters	3	CTU, CTD, CTUD
Comparison	13	Eq, Lt, Gt, Le, Ge, Ne, InRange, OutRange, OK, NOK, IS_ARRAY, IS_NULL, NOT_NULL
Word logic	9	SEL, And, Or, Xor, Inv, Mux, Demux, DECO, ENCO
String	10	LEN, CONCAT, LEFT, RIGHT, MID, FIND, INSERT, DELETE, REPLACE, S_Move
Shift/rotate	4	Shl, Shr, Rl, Rr
Math	24	Add, Sub, Mul, Div, Mod, LIMIT, MIN, MAX, Abs, Inc, Dec, trig/log/rounding
Move	12	Move, Swap, MoveBlockI/U, FillBlockI/U, Lower_Bound, Upper_Bound, GATHER, SCATTER, Serialize, Deserialize
Conversion	7	Convert, Scale_X, Normalize, Round, Trunc, Ceil, Floor
Program control	4	Jump, JumpNot, Switch, JmpList

Three editorial choices say a lot about the intent:

CoilTON / CoilTOF / CoilTP / CoilTONR get their own pages. Coil-form timers and box-form timers differ in syntax and in where they may be placed; mixing them is a standard commissioning incident.
OK / NOK / IS_ARRAY / IS_NULL / NOT_NULL are filed under comparison. These aren't comparisons of magnitude; they're validity checks, and you cannot write reusable FBs without them.
Only four program-control instructions. No attempt to mirror the whole instruction set — just the jump forms ladder actually uses.

Every page header also carries applicable CPUs (S7-1200/1500), the version basis (TIA V19), and aliases — TON is alias-mapped to "on-delay timer / SD", TP to "pulse timer / SP". The alias line matters when you're reading old drawings: the sheet says SD, TIA says TON, same thing.

One implementation detail worth knowing: pin names and directions come from the lad-ir instruction catalogue, and the figures are rendered by lad-render — the same renderer used by the example library, so a handbook figure and an example figure look identical side by side.

3. What one page contains (TON as the example)

Open TON — on-delay timer. Top to bottom, seven sections. The order is itself a reading strategy: usable first, mechanism second, boundary last.

1) One sentence. "TON is an on-delay timer: Q goes to 1 only after IN has been continuously 1 for PT; as soon as IN drops, Q and ET reset." Trigger condition, decision condition, reset condition — drop any one of the three and the instruction gets misused.

2) Symbol and pins.

Pin	Direction	Meaning
`IN`	flow input	Enable; starts timing while 1
`PT`	input	Preset time (Time)
`Q`	flow output	1 after elapsed; resets when `IN` drops
`ET`	output	Elapsed time; returns to 0 when `IN` is 0

Plus three metadata lines that decide whether it can live in an FC at all: group: timers, needs an instance, template value: time type.

3) Minimal example. Start held for 5 s, then Motor is set; Start dropping resets Motor immediately. The example uses a static multi-instance Timer inside an FB; in an OB/FC you can use a global IEC timer instance DB instead. The figure notes that # means a block-local variable, and that real projects may use global tags or DB variables.

4) How it works (state table).

`IN`	Elapsed	`Q`	`ET`
0	—	0	0
1	< `PT`	0	increments from 0
1	≥ `PT`	1	stops at `PT`
1 → 0	—	0	back to 0

Four notes follow, and each one is a pitfall in disguise: IN must be continuous; PT versus ET; ET stops growing once the time is reached; never call the same instance from multiple places.

5) Typical uses. Delay-on start (3–5 s confirmation before energising a motor); debounce / in-position confirmation (drop PT to 200–500 ms and use Q as "signal is stable"); timeout alarm (start timing on the command, alarm if "done" never arrives). That third one adds the premise most people miss: you usually need a NOT Done condition in series, and if Start is a momentary button you must first latch it with SCoil.

6) Common pitfalls.

TON is not TP: TON holds Q until IN drops; TP is a fixed pulse that IN cannot cut short.
TON is not TOF: TOF is off-delay; Q stays 1 for PT after IN drops.
A short pulse never reaches TON: a one-scan pulse never gets to PT.
ET resets: with IN = 0, ET goes back to 0 — don't use it as an accumulator.
Instance conflicts: calling the same instance from multiple networks overwrites the timing.
Missing PT: TIA reports an unused parameter; SCL calls like TON(IN:=...) lose it easily.

Five of the six describe failure shapes, not definitions. That's where the information density of this handbook actually lives — it reads like it was written from observed mistakes, not from a parameter table.

7) Related examples and related instructions. Two graded examples (delayed motor start with pump control; three-motor staggered start/stop), each with a one-line summary and a difficulty tag, plus two lateral links (SCoil, TOF) — "the next thing you will confuse this with".

Bonus: the "try it in TIA" panel. This is the difference from a normal documentation site. A block selector offers variants (TON has minimal example / signal debounce / timeout alarm). Importing then:

goes through TiaLink into the project you currently have open, with pre-check, no overwrite of same-named objects by default, and no auto-save;
does not run the block: you still call it from OB1 and wire real variables yourself;
uses http://localhost:8080 by default, or ?tialink= appended to the page URL;
accepts the --api-token value if TiaLink was started with one — stored only in the browser's localStorage, never uploaded.

"No overwrite" plus "no auto-save" keeps the risk on the reversible side: the import puts blocks into the project; whether they stay is still your decision.

4. Stress test: the three families people confuse

4.1 The timer trio — TON / TOF / TP

	`TON` on-delay	`TOF` off-delay	`TP` pulse
When timing starts	while `IN` is 1	when `IN` goes 1 → 0	on the rising edge of `IN`
When `Q` turns on	after `PT` with `IN` still 1	immediately, while `IN` is 1	for a fixed `PT` after the edge
`IN` drops mid-way	`Q` and `ET` reset instantly	this is when timing begins	does not cut the pulse
A one-scan pulse	never reaches `PT`; `Q` never turns on	is stretched to the full `PT`	is the normal operating mode
Typical use	start delay, debounce, timeout alarm	fan run-on, conveyor clearing	fixed-width valve pulse, start pulse

The two pitfalls are mirror images of the same physical fact:

TON's pitfall is "a short pulse never reaches PT" — so don't use it to catch pulses; use TP or latch an edge.
TOF's pitfall is "a short pulse is stretched to the full PT" — so don't use it as a pulse filter; it amplifies one scan into the whole preset time.

You only see that pairing when the two pages sit next to each other.

TP also carries an honest footnote: a second rising edge during the pulse usually does not extend it, but confirm the behaviour on your specific CPU/firmware. "I can't guarantee this in a document" is more useful than a confident wrong answer — it tells you to measure.

4.2 Bit logic — Coil / SCoil / RCoil / Sr / Rs

Five ways to write a 1, five different semantics:

Instruction	Form	Behaviour	How it resets
`Coil`	coil	follows RLO every scan	automatically
`SCoil`	coil	sets and holds while RLO = 1	only `RCoil` or writing 0
`RCoil`	coil	resets to 0 while RLO = 1	—
`Sr`	box	set-dominant latch	via the `r1` input
`Rs`	box	reset-dominant latch	reset wins when both are 1

Sr's pitfall list is entirely semantic, and every item is a real defect: operand cannot be an Output (TIA does not allow reading outputs — use InOut or Static); don't confuse it with SCoil/RCoil (box versus coil); pick the dominance according to the process; q is an RLO output you can continue in series; and scan order — when a latch bit is written from several places, the result depends on scan order.

That last one is really the thesis of ladder programming: write the same bit from several networks and you don't own a value — you own whatever the last network to reach it wrote.

4.3 Edges — PContact / PBox / PCoil / R_TRIG

Edge instructions are the source of two production classics: the missed pulse and the double count. Eight pages split them by what they watch:

Instruction	Watches the edge of	Instance needed	Output duration
`PContact` / `NContact`	an operand (0→1 / 1→0)	no, but needs an edge memory bit	one scan
`PBox` / `NBox`	the RLO on the left	no, edge memory bit	one scan
`PCoil` / `NCoil`	RLO edge, writes an operand	no, edge memory bit	one scan
`R_TRIG` / `F_TRIG`	`CLK`, `Q` pulses	yes, an instance	one scan

PContact explains the mechanism: the bit is edge memory that stores the operand's previous state, and each edge contact needs its own bit; out = 1 only in the scan where the operand goes 0 → 1, and bit updates at the end of the scan.

Its pitfalls double as a troubleshooting checklist:

No preceding logic: putting PContact first in a rung violates TIA's edge rules — place an Enable / Not / contact before it.
Shared edge bits: two PContact sharing one bit overwrite each other and drop pulses.
Non-retentive edge bits: a bit in Temp is reset on every call — use Static, a global M, or a DB.
Used as a level: it is high for exactly one scan; if you need persistence, follow it with SCoil or a latch.
Skipped networks: if a Jump skips the network, the edge isn't recorded — and when the scan returns, the edge may be misinterpreted.

That last one is rarely written down anywhere, yet it's the standard path by which "code that never executes" turns into "an occasional unexpected motion".

5. Three ways to use it

Firefighting (the 30-second rule). One sentence → pin table → pitfalls. Skip the rest. The one-sentence line tells you whether the semantic is the one you want, the pins confirm the wiring, the pitfalls confirm whether your current code is the failure shape.

Studying a group (read the pitfalls as a comparison table). A single page doesn't stick, but read all ten timer pages' pitfalls and you get a map of when not to use which timer; read the eight edge pages and you get a leak checklist. That's more durable than memorising symbols.

Feeding pages to an AI as a checklist. This is the biggest change in how the work is done now. When an AI generates or modifies ladder/SCL, the errors concentrate in four places: wrong timer family, shared edge bits, double coils, instance conflicts — and the pitfalls section of each page is a ready-made checklist. Practically: paste the relevant page (summary + pins + mechanism + pitfalls) as context and ask the model to check the code against it, instead of generating from memory.

Two companion pieces in the same series: 7 lessons from AI PLC programming (the four verification layers — structural validation → TIA compile → cloud simulation → virtual PLC/field — and what each layer does not prove) and the Siemens ladder example library (how 60+ examples are arranged into a practice path). Both are in Chinese.

⚠️ Keep the handbook's own disclaimer in view: instruction pages cover semantics and usage only; they do not replace the TIA help or a process/safety review. Safety-related conclusions require human confirmation.

6. From "found it" to "ran it" in four steps

Look it up — confirm semantics and pitfalls on the instruction page.
Import — use the "try it in TIA" panel to pull an example block (e.g. TON → timeout alarm) into your open project via TiaLink: pre-check, no overwrite, no auto-save.
Wire it — call the block from OB1 and connect real variables. It does not run by itself; this step is the pin comprehension.
Prove it — run the timing in cloud simulation, then watch IO behaviour on a virtual PLC. For the layer split, see 7 lessons; for practice without hardware, see Factory I/O + OpenPLC + Modbus TCP.

Compared to pasting a snippet into your project, only step 3 is extra work — and it's what buys you the knowledge of which scan cycle each line runs in. The classic counter-example: during a refactor TP was written as TON; compile reported 0 errors and 0 warnings; pressing the button started nothing.

7. What it deliberately doesn't do

It doesn't replace the TIA help. Semantics, examples and pitfalls live here; firmware and CPU specifics stay with the official documentation and your own measurements.
It doesn't replace a process review. Especially for safety (e-stops, safety doors, F-CPUs and F-blocks) — the pages state plainly that safety conclusions require human confirmation.
The scope is S7-1200/1500 on TIA V19. S7-300/400-era S5 timers (S_ODT and friends) are a different semantic family; don't transplant them.
Unknown behaviour is labelled unknown. Where a cross-version detail can't be guaranteed (e.g. TP retriggering mid-pulse), the page says "confirm on your CPU" instead of inventing an answer.
Examples are minimal readable shapes, not production code. No process interlocks, no fault handling — add them yourself and review them.
Import is not adoption. No overwrite, no auto-save: the decision stays on your side. That's protection and responsibility at the same time.

Sources and verification notes

Handbook index (113 instructions, 13 groups): tia.hubwiz.com/learn-lad/instructions/
Instruction pages quoted: TON, TOF, TP, CTU, SCoil, Sr, PContact
Page structure, counts, pin tables, pitfalls and import behaviour were read from the live pages on 2026-10-22. Nothing here was independently re-measured on hardware; instruction semantics remain governed by the TIA help and the process/safety review.
Cover photo: Pexels #257736 (Pexels License).

image-blaster: the real cost of one image 3D world

tia-forge — Wed, 21 Oct 2026 15:12:45 +0000

One image in, a walkable 3D environment out in under five minutes. That is the pitch on neilsonnn/image-blaster — 11.8k stars, MIT, front page of Hacker News in May 2026. Built by a World Labs team member (not an official World Labs product), it chains Marble, Hunyuan 3D, nano-banana and ElevenLabs behind a Claude Code skill.

Two questions decide whether you can use it, and the eight English write-ups I could find answer neither:

What does one run actually cost? (Short answer: the world is fixed at ~$1.34; every dynamic object adds ~$0.46.)
Can you drop the outputs into an engine? (Short answer: not before you apply a scale correction the CLI never applies for you.)

Both answers are below, with code references and prices as of 2026-10-21.

What it actually is

Not an app — a skill pack for Claude Code. You clone the repo, run claude inside it, hand Claude two API keys (World Labs + FAL), drop an image into input/, and say blast it and confirm each step with me.


Repo	`neilsonnn/image-blaster`, MIT
Timeline	created 2026-04-21, last push 2026-05-15; 11,794 ★ (snapshot 2026-10-21)
Form	`.claude/skills/*` + Node scripts
Requires	Claude Code CLI + World Labs key + FAL key
Outputs	dynamic objects `.glb`/`.obj`; static environment `.spz`; SFX `.mp3`

The three outputs are not the same kind of thing, and that is where every downstream problem starts:

Output	Format	What it is	What it is not
Static environment	`.spz`	a Gaussian-splat scene you can walk through	not a mesh — no faces, no UVs; needs splat render support
Dynamic objects	`.glb` / `.obj`	one real mesh per object	not a scene — you place them yourself
SFX	`.mp3`	ambient loop + per-object impact	not a mixed audio system

The pipeline, as it actually executes (read from the scripts, not the README):

input/ image
  ├─① clean plate / object cut-outs   fal-ai/nano-banana-2/edit          $0.08/img
  ├─② static environment             World Labs marble-1.1              1,500 credits
  │     └→ .spz (full_res + 500k + 100k + 150k downloaded)
  │     └→ collider mesh .glb (100–200k triangles)
  ├─③ each dynamic object            fal-ai/hunyuan-3d/v3.1/pro/...     $0.375/call
  │                                  (or .../rapid $0.225, fal-ai/meshy/v6 $0.80)
  └─④ SFX                            fal-ai/elevenlabs/sound-effects/v2 $0.002/sec

Two details that matter and are easy to miss:

Every object costs one image edit before the 3D call. The image-blast-3d skill instructs Claude to first write a cut-out prompt ("Isolate the <object> … white background, centered, tight crop"). So an object is edit + 3D, not 3D.
SFX go through FAL, not ElevenLabs directly (fal-ai/elevenlabs/sound-effects/v2). If you price this off ElevenLabs credit tables you will be off by an order of magnitude. The skill's defaults: ambient --loop --count 2 --duration-seconds 10, per object --count 4 --duration-seconds 1.

The bill

Prices below are the vendors' own pages, checked 2026-10-21.

Item	Price	Source
World Labs credits	$1.00 = 1,250 credits; minimum purchase $5	`docs.worldlabs.ai/api/pricing`
World generation `marble-1.1`	1,500 credits = $1.20	same
Pano generation (non-pano image)	+80 credits = $0.064	same
HQ mesh export	3,500 credits = $2.80	same (this pipeline never calls it)
Image edit `nano-banana-2/edit`	$0.08 / image (2K/4K ×1.5)	FAL model page
Object 3D `hunyuan-3d/v3.1/pro`	$0.375 / generation	FAL model page
Object 3D `.../rapid`	$0.225 / generation	FAL model page
Object 3D `meshy/v6`	$0.80 / generation	FAL model page
SFX `elevenlabs/sound-effects/v2`	$0.002 / second	FAL model page

Which reduces to a very simple structure:

fixed per run   = world 1.264 (1,500 + 80 credits) + one plate edit 0.08   ≈ $1.34
per object      = cut-out edit 0.08 + 3D 0.375 + impact SFX 4s × 0.002     ≈ $0.46

Scene	Math	Total
1 object	1.34 + 0.46	≈ $1.81
5 objects (one room)	1.34 + 5 × 0.46	≈ $3.66
20 objects (street / level)	1.34 + 20 × 0.46	≈ $10.60
20 objects on `rapid`	1.34 + 20 × (0.08 + 0.225 + 0.008)	≈ $7.62
20 objects on `meshy v6`	1.34 + 20 × (0.08 + 0.80 + 0.008)	≈ $19.10

Three non-obvious consequences:

The world is the cheap part. Marble renders an entire environment for $1.26; five small props cost twice that. Your budget is a function of object count, not canvas size.
The $2.80 HQ mesh export is not in the loop. generate-world.mjs only pulls assets.mesh.collider_mesh_url — the 100–200k-triangle collision mesh. If you want a static mesh you can actually look at, you have to go back to Marble and export the HQ version separately: ~600k triangles with textures (or ~1M with vertex colors), up to an hour, rate-limited to 4/hour, Pro plan.
Failures are billable. Unhappy with face count? Re-run: another $0.375. Bad cut-out? Another $0.08. This is exactly why the skill's default posture is confirm each step with me.

Scope: these are estimates derived from the pipeline structure and public unit prices, not our own invoice. No retries, no plan differences (Free can generate worlds but cannot export; Standard covers splat/collider exports; Pro adds HQ mesh + commercial rights).

The part nobody writes about: the `.spz` is not in metric space

World Labs documents this in api/rendering-spz:

Marble SPZ files are exported in the generated asset coordinate frame. When you render them outside Marble, use assets.splats.semantics_metadata to convert Gaussian centers and Gaussian sizes into metric, ground-aligned coordinates.

Field	Job
`metric_scale_factor`	raw generated units → meters
`ground_plane_offset`	puts the metric ground plane at y = 0
`flip_y` (optional)	Y-axis orientation (SPZ defaults to RUB, Unreal is Z-up)

So: is it handled? I grepped the whole repo (2026-10-21, main):

Location	Reads `semantics_metadata`?
`app/src/components/WorldViewer.tsx` (bundled React viewer)	Yes — `metric_scale_factor`, `ground_plane_offset`, `flip_y`, defaults 1 / 0
`.claude/scripts/**` (the CLI pipeline that hands you the files)	No — downloads `spz_urls` and `collider_mesh_url`, nothing else

Which means: it looks right in the bundled viewer because the viewer applies the correction, and it is wrong in Unity / Unreal / Blender / three.js because the exported files don't carry it. Symptoms: a door 30+ units tall, everything floating above or sunk into the floor, and props misaligned against the splat they were generated from.

// three.js: the loader reads the file, it does not fix the frame
const world = await new SPZLoader().loadAsync(url);
const m = semantics.metric_scale_factor;
world.scale.setScalar(m);
world.position.y -= semantics.ground_plane_offset;

Apply the same factor to the collider mesh (inference — the docs only spell this out for splats, but both come from the same generated frame).

What the outputs really are

Output	Official spec	Who reads it natively
Splat `.spz` (full res)	~2M splats	three.js (`SPZLoader` in addons); Unity / Unreal / Blender / Houdini need community splat plugins
Splat `.spz` (low res)	~500k / 100k / 150k	same; lower res is what you actually want in-engine
Splat `.ply`	~2M / ~500k	widest compatibility, much bigger — SPZ is roughly 10× smaller than the equivalent PLY
Collider `.glb`	100–200k triangles	any engine; it is a physics proxy, not a render mesh
HQ `.glb` (Pro)	~600k textured / ~1M vertex-color	any engine; not produced by this pipeline

Ten-minute acceptance checklist

#	Check	How	If it fails
1	Units are meters	measure a known reference (2 m door)	apply `metric_scale_factor`
2	Ground at y = 0	splat floor on the zero plane	subtract `ground_plane_offset`
3	Orientation	upside down → `flip_y`; rotated → world yaw	flip / rotate
4	Splat and mesh share scale	overlay the same chair twice	use one factor for both
5	Face count holds up close	zoom to player distance	re-run with `--face-count` (billed again)
6	Collider ≠ render mesh	100–200k tri file is the collider	keep both, don't swap
7	File size	prefer low-res `.spz` in-engine	see the payload comparison link below
8	Licensing	code is MIT; assets are generated by third-party APIs	Marble commercial rights sit on Pro; check each vendor

Four things that will bite you

Static/dynamic split errors → ghosting. The splat already contains the chair; generate a mesh of the chair and now you have two. Wrong split = double image, and an extra object you didn't want costs $0.46.
The splat/mesh boundary leaks. Splats have no geometry, cast no shadows, don't receive light like meshes. Contact shadows and occlusion at the seam won't match. (Inference: add AO blob decals under meshes, or cover the contact band with mesh.)
The 50k default is the skill's, not the API's. Hunyuan's own default is 500,000 faces. Background props are fine; hero objects look generated up close.
SFX are materials, not an audio system. Two 10-second ambient loops, four 1-second impacts per object. No rolling, no sustained sounds, no material variation. Non-loop output gets trimmed and loudness-normalized by ffmpeg; loop output is left raw for seamlessness.

When not to use it

You want	Why not	Instead
One model, no scene	the $1.34 world is wasted	call the FAL model directly
Precise dimensions	generation isn't dimension-driven	parametric CAD workflow
Editable topology / clean UVs	you get "scanned" topology	rebuild from the form (Mesh2CAD route)
Offline / on-prem	the whole chain is two cloud APIs	local text-to-3D (e.g. TRELLIS.2 in-browser)
Team doesn't use Claude Code	it's a skill pack, not a GUI app	drive the scripts yourself
Clean commercial rights	assets come from multiple vendors	verify each license

The one thing it is genuinely good at: you have an image — concept art, a film still, a photo of a room — and you need a prototype you can walk around in within five minutes to align the space, test framing, or show a client. For that, it beats hand-building the scene by a wide margin.

Scope and sources: repo README, `.claude/skills/ and .claude/scripts/ (2026-10-21, main); World Labs docs (api/pricing, marble/export/specs, marble/export/gaussian-splat, api/rendering-spz); FAL model pages; Niantic spz format notes and three.js SPZLoader`. **No end-to-end run was performed* — costs are structural estimates from public unit prices, and mesh/engine/license constraints come from documentation rather than our own tests. The author is a World Labs team member; this is their project, not an official World Labs product.*

Compiling Clean Isn't Proof: Have AI Review a PLC Program Before You Commission It

tia-forge — Wed, 21 Oct 2026 12:40:08 +0000

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.

DeepInfer: What's Actually Inside DeepSeek's Newly Open-Sourced Inference Engine

tia-forge — Tue, 20 Oct 2026 17:13:46 +0000

On October 20, 2026, DeepSeek open-sourced DeepInfer — the inference framework it says powers its own large-scale production services — under the Apache 2.0 license. The repo is deepseek-ai/DeepInfer, and it crossed 10,000 GitHub stars within days of the announcement (as of writing, ~10.5k stars / 926 forks).

The one-line version from the official account:

"Introducing DeepInfer, our in-house inference framework, now fully open source! Powering DeepSeek-V4.1-Flash at scale with high throughput..." — @deepseek_ai on X

There has been a wall of hot takes since (the Hacker News thread passed 1,400 points). Most of them skip the README, which is actually quite specific about what this release is and — more interestingly — what it is not. This post is a walkthrough of exactly that: what's in the box, what's deliberately left out, where it comes from, and who should actually deploy it.

What DeepInfer is

From the README, verbatim:

"DeepInfer is the high-performance inference framework that powers DeepSeek's large-scale production services. This open-source release provides offline inference with the core features needed for serving at scale."

Two words in that sentence matter more than the rest:

"production" — this is not a research playground. It's the same stack that serves DeepSeek's own API traffic, open-sourced as-is rather than rebuilt for external consumption.
"offline inference" — the release ships offline (batch-style) inference. A full online serving service needs components DeepInfer does not include (more on that below).

It supports exactly one model family today: DeepSeek-V4.1-Flash (default checkpoint: deepseek-ai/DeepSeek-V4.1-Flash-1017 on Hugging Face). This is a model-hardware co-optimized production engine, not a universal deployment framework for every model on HF.

What's in the box

The feature list from the README, with the configuration knobs that go with them:

Feature	How it's enabled
Optimized kernels (FlashMLA, DeepGEMM, DeepEP, TileKernels, DeepSelect, custom TileLang kernels)	built in
Draft-token decoding + confidence-scheduled verification	`DEEPINFER_ENABLE_MTP_VARLEN=1`; max draft length via `DEEPINFER_USE_NEXTN_DECODE` (default 5)
Parallelism: attention DP, balanced CP, MoE EP + EPLB	built in
Decoder SWA bounded replay (only replay a bounded suffix of the context)	`DEEPINFER_YOCO_PREFILL_TRUNCATION_MODE=compact`, `DEEPINFER_YOCO_PREFILL_KEEP_TOKENS=140`
Asynchronous scheduling (overlap CPU batch scheduling with device execution)	enabled by default
Batch-invariant inference (identical results across batch compositions)	`DEEPINFER_BATCH_INVARIANT=1` (NVIDIA only)
Deterministic sampling (identical outputs for identical inputs and seeds)	`DEEPINFER_BATCH_INVARIANT=1` + fixed `seq_seed` (NVIDIA only)
Structured outputs (regex / JSON schema / EBNF grammar constraints)	via `SamplingParams(so_args={...})`

Two of those deserve a note:

Batch invariance + deterministic sampling kill a whole class of production headache. If you've ever been burned by "the same prompt gives a different answer depending on who else is in the batch," this is the guarantee that removes that bug class — the kind of property usually only achieved with bespoke deployment tricks. Note, though, that it's NVIDIA-only in this release.
Confidence-scheduled verification is speculative decoding where the scheduler uses confidence estimates to decide how to spend verification budget — a scheduling refinement rather than a new algorithm, but the kind of thing that only gets built if you actually serve enormous volume.

What it's built on — and the hardware bet

The acknowledgments section settles the "is it a vLLM fork?" question:

"DeepInfer was originally built primarily on vLLM, with additional inspiration from SGLang and TensorRT-LLM."

So yes — vLLM lineage. What DeepSeek added on top is a stack of self-optimized kernels (FlashMLA, DeepGEMM, DeepEP are DeepSeek's own projects) and a scheduler designed around their model's architecture.

The hardware support is the political headline, though:

NVIDIA SM100 GPUs (CUDA 13)
Huawei Ascend 950 NPUs (CANN 9.2)

That second line is unusual for a top-tier open-source inference release: Ascend support sitting next to NVIDIA from day one, in a production engine. Requirements are strict on both sides — Linux, GCC ≥ 13.0, Python 3.12, and either CUDA 13 or CANN 9.2. This is not a laptop demo framework.

Benchmarks: transparency instead of a hero number

The README doesn't lead with a single "we're X% faster" number. Instead it publishes two Pareto plots — prefill throughput vs. latency, and decode throughput vs. per-user speed — measured on 4 SM100 GPUs for prefill and 64 for decode, each within one scale-up domain, with a run_sweep.sh script so you can reproduce the configuration yourself.

That's the right shape for claims like these: a Pareto curve with a reproduction script is auditable in a way a bar chart never is. Whether the curves hold up on your interconnect is, of course, a different question — the sweep script exists precisely because the answer depends on your topology.

What's deliberately missing

This is the part of the README most coverage skipped. DeepInfer is open about requiring three subsystems for a complete inference service that are not in this release:

A KV cache system
VE/prefill/decode disaggregation (though the README notes most required engine functionality is already implemented)
Load balancing across data-parallel replicas for both prefill and decode

In other words: this is an engine, not a turnkey server. If you were hoping to swap it in as the backend behind your OpenAI-compatible gateway tomorrow, you'll be building or bolting on those pieces. That's also a fair reading of DeepSeek's release philosophy: publish the hard, differentiating core; let the surrounding infrastructure stay open-ended.

One caveat worth repeating: batch invariance and deterministic sampling are NVIDIA-only in this release, and Ascend support, while present, carries exactly the same "read the fine print" weight as any first-version port.

Quickstart

Build from source (create an empty Python 3.12 environment first):

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

tia-forge — Tue, 20 Oct 2026 02:29:56 +0000

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.

1. The bottleneck moved from "write it" to "prove it"

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:

Compiles clean, spec not implemented. The requirement said "after the sensor triggers, output for 2 seconds." The implementation used TON. The sensor is only high for one scan cycle, so the timer's ET never reaches 2000 ms and the output never turns on once.
Compiles clean, nothing moves. While refactoring a three-motor delayed-start sequence, TP was written as TON. Compile: 0 errors, 0 warnings. Press the button: none of the three motors start.
Compiles clean, the field never reads it. When changing an IO address, the TIA compiler does not check whether a physical channel exists. Point a tag at I30.0, which this project doesn't have, and you still get 0 errors and 0 warnings.

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."

2. Four layers of verification, and what each one does not prove

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

Layer	Who judges	Proves	Does not prove
Structural validation (`scl_validate`)	The cloud simulator's parser	Source parses, structure is legal	TIA compile rules, behavior
TIA compile	The TIA Portal compiler	The block compiles in your project (0 errors, 0 warnings)	Behavior matches the spec; the address has a physical channel
Cloud simulation	A scan-level simulator	Under a given input sequence, output assertions hold (PASS/FAIL)	Hardware, bus, HMI, safety circuits; also not the TIA compiler
Virtual PLC / real hardware	S7-PLCSIM Advanced / the machine	Real scan behavior after download, diagnostics, faults	Safety functions, interlocks, e-stops still need human review

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.

3. How the seven lessons are ordered

Stage	Lesson	Tool	Time	Endpoint (what you walk away with)
Beginner	Write SCL: from requirement to 0 errors, 0 warnings	TiaLink	30 min	A clean compile plus a requirement → implementation → verdict table
Beginner	Modify the first example in the library	TiaLink	20 min	One added tag, one series contact, clean compile, structural read-back
Intermediate	Read an undocumented legacy TIA project	TiaLink (read-only)	25 min	A project specification document + a human review list; zero changes
Intermediate	Change one IO address — what breaks?	TiaLink (read-only + dryRun)	25 min	Reference list, risk list, change plan, preflight result
Intermediate	Simulate before commissioning: download to a virtual PLC	TiaLink + PLCSIM Advanced	35 min	A scenario table with measured values
Intermediate	No TIA install: turn SCL into PASS/FAIL in the cloud	Cloud simulation MCP	35 min	An ALL PASS report plus the scan count
Hands-on	Refactor without changing behavior: 3 copies → 1 FB	TiaLink + PLCSIM	40 min	Baseline vs regression, point by point

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.

4. The seven things that actually trip people up

4.1 First compile: 2 errors, 2 warnings

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:

[Error] Parameter 'PT' has to be used. — a timer call must supply PT every time, including the reset branch. The correct shape is one call per scan with reset folded into IN.
[Warning] The parameter '#Running' might not be initialized. — the output is read before it is definitely assigned. Carry the state in a Static variable with an initial value and assign the output unconditionally at the end.

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.

4.2 Modifying an example: don't import it into a live 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.

Two genuinely annoying traps:

UId must be a decimal integer — hex is rejected outright;
TIA renumbers UId after import, so you cannot assert on UId; assert on structure instead.

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.

4.3 Reading a legacy project: separate confirmed / inferred / unconfirmed

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:

The CPU is an F-type (1513F-1 PN, 6ES7 513-1FL02-0AB0, firmware V2.9) but there are no F-blocks. That doesn't mean the hardware is wrong, but it has to be listed as a safety item for a human to confirm.
An FB with an empty interface is not an empty block: Auto_mode / Manu_mode have no parameters at all; the logic reads and writes global variables (ZS-*, CV-*, HMI_*, SIM_*). Which means: track change impact through variables, not through interfaces.
One giant network: Auto_mode has a single network with 36 operands; 2 of Main's 4 networks are empty. Treating that as "one rung" is guaranteed to be wrong — split it into functional segments (sensor chain, actuator chain, alarm/simulation, MATLAB handshake).

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.

4.4 Change-impact analysis: a clean compile does not mean the field can read it

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:

References: 6 in Auto_mode + 2 in Manu_mode, all reads, and zero absolute addresses inside blocks. So no block needs editing; only the tag table changes. That's what "impact assessed" means.
The HMI is symbolic (AddressAccessMode=Symbolic), so the address change follows automatically — but address strings hard-coded in screens or comments are not visible to the compiler and need a human.
Hardware mapping: %I29.0 belongs to the ET200SP DI 8x24VDC ST_2 (Input29); I29.0–3 are ZS-101..104, so %I29.4 is a free channel on the same module.
The dangerous part: TIA does not validate that the address has a physical channel. Point it at a non-existent address and you still get a clean compile, while the field never sees the signal. Changing an address also means changing the wiring ↔ address mapping — moving a terminal is something only a person or a drawing can confirm.
dryRun returns {action: "overwrite", kind: "tagTable", tagCount: 27} — you thought you changed one line; the whole 27-tag table gets rewritten. Without this preflight, you find out after other tags silently revert.

4.5 Virtual PLC: behavior finally becomes visible

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.

4.6 Cloud simulation: define the word "trigger"

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:

initialize, tools/list, resources/read are free; each accepted tools/call costs one credit. New accounts get 100; this lesson uses roughly 8–12.
tickMs defaults to 10 ms, so 100 ticks = 1 second.
scl_simulate steps in scans; scl_run_scenario steps in ticks. That's the easiest mistake to make.

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))

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.

4.7 Refactor with regression: `TP` typed as `TON`, clean compile, zero motors

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:

Store a behavior baseline first. Same scenario table, run before and after, compare cell by cell. Refactoring without a baseline means using the plant as a test environment.
Trust only output bits and the scenario table. If a structured member (DB.Ton.ET) can't be read, change the evidence — don't fill the gap with "looks right."

5. Who does what: the agent acts, you judge

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."

Step	The agent does	You must do
Write SCL	Read the project, add a CPU, generate the block, import, compile, self-fix from compiler output, clean up source files, save	State the requirement; approve the "report before change" step; spot-check the read-back table
Modify an example	Update the tag table, insert a contact, compile, read back structure	Confirm the boundary (only `Main` + tag table); confirm it's not a live project
Read a legacy project	Inventory devices/blocks/tags/HMI, export, summarize per block and network, flag unreferenced tags	Decide which findings escalate to safety items; review inferred vs unconfirmed
Change impact	Scan references, classify read/write and symbolic/absolute, map to hardware channels, `dryRun`	Decide whether to change it; confirm terminals and drawings; confirm saving
Virtual PLC	Add device, insert modules, import, compile, register, power on, download, read/write, fill the table	Click the TIA authorization prompt; check that "measured" values really came from reads
Cloud simulation	Write scenario JSON, run assertions, locate the failing scan	Verify the scenario table covers the requirement — especially the definition of "trigger"
Refactor + regression	Save the baseline, write the parameterized FB, replace, rerun, diff	Decide which blocks must not be "refactored while you're in there"; confirm replacing the original

Short version: actions can be delegated, judgment cannot. Your part boils down to three kinds of moves: state the requirement and the boundary, approve before a change is written and before it is saved, and verify the evidence instead of the claim. The checklists exist to turn "a human took a look" into "a human verified something."

6. Four questions people ask

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.

7. Two ways to start

Path A — Windows + TIA Portal V19

Open a sandbox project, start TiaLink on the same machine; the page header auto-detects the connection and project name.
Add a Streamable HTTP MCP server at http://localhost:8080/mcp with a Bearer token; on another machine, replace localhost with the TIA PC's LAN address.
Start with "modify the first example" (20 minutes, smallest diff, fastest verification), then go back to "write SCL to 0/0" (30 minutes).
If the health check flags the allow-list, the first write triggers a TIA authorization dialog that only a human can confirm; running TiaLink.Helper.exe once avoids it.

Path B — no TIA available yet

Open the cloud simulator, sign in with a QR code, create an API key (shown once — don't commit it).
Set the MCP endpoint to https://tia.hubwiz.com/sim/mcp.
Do the "no TIA install" lesson with the same FB_Sorter that compiled clean in path A — and watch it fail twice before it passes.

8. What the course deliberately does not provide

No downloads. By design: no files land on disk; import goes through TiaLink with a preflight, and nothing is auto-saved.
Cloud simulation only accepts examples or desensitized code. Don't paste a customer project; lessons that touch TIA run entirely on your machine, and project data stays in-house.
Passing simulation is not commissioning. PLCSIM only simulates CPU behavior; bus, HMI, drives and safety circuits are out of scope. Cloud simulation is narrower still.
Every change needs human review. Safety functions, interlocks, e-stops are not delegated; AI output is "unverified" by default.
Version-specific. Everything was measured on TiaLink 1.1.0.0 + TIA Portal V19 + S7-PLCSIM Advanced 6.0. Different versions change error text and tool names — which is exactly why the course insists on structured results instead of matching error strings.

9. Who it's for, and who it isn't

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.

10. Takeaway

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.

Verification notes

Course structure, lesson steps and all measured numbers (2 errors / 2 warnings, 36 operands, 51 tags with 6 unreferenced, dryRun rewriting 27 tags, 5,735 scan cycles, 1513F-1 PN, 1516-3 PN/DP) come from the official course pages at tia.hubwiz.com/learn-lad/ai/ and its seven sub-pages, checked on 2026-10-20.
The stated test environment is TiaLink 1.1.0.0 + TIA Portal V19 + S7-PLCSIM Advanced 6.0; the cloud simulation report replays identically on scl-sim 0.1.0 and the hosted endpoint (2026-10-19).
This article does not independently reproduce the measurements; numbers and conclusions follow the official pages and may change with tool versions.

Siemens PLC Ladder Logic Examples: 60 Exercises You Can Import Into TIA Portal

tia-forge — Sat, 17 Oct 2026 12:47:09 +0000

The hard part of learning ladder logic isn't memorizing contact symbols — it's getting from a one-line requirement to a program that actually runs in TIA Portal. Learn-LAD breaks that step into 60 worked examples. Each one gets its own page: the ladder diagram, a network-by-network walkthrough (purpose / condition → action / why / watch out / logic expression), a signal table and a variable table, common questions, and variants. Install TiaLink and you can also pre-check the example's objects and then import them into the TIA Portal project you have open — same-named objects are not overwritten by default, and the project is not saved automatically after the import.

It's not a "watch the video, still can't write it" tutorial, and it's not an archive of files you download and forget. It's closer to a problem set with answers and explanations: the tasks mirror real machine behavior, and the answers can be read, modified, or imported into a project to check against.

1. Where learning ladder logic actually gets stuck (it's rarely syntax)

Contacts, coils, normally open / normally closed — an afternoon is enough to memorize all of it. The real sticking points show up later:

You can read it, but you can't write it. You can explain any single network. But give yourself one sentence — "after the start button is pressed, run the motor for 10 seconds, wait 10 seconds, then stop" — and you don't know what belongs in the first rung.
You can copy it, but you can't modify it. Someone else's program runs fine in your project. Change a timer value, add an interlock, add a mode — and you don't dare touch it.
You've practiced, but not correctly. The snippets you find online are scattered: no variable table, no addresses, no explanation of why it's written that way. You finish practicing and still don't know whether you got it right.

None of these three is a syntax problem. They're all the same missing thing: complete, verifiable, usable examples.

Five criteria for judging a PLC example library

Criterion	Why it matters	How Learn-LAD does
Real ladder diagrams	Not pseudocode or a spoken description — you can trace the contacts	One ladder screenshot per network
Network-by-network explanation	Explains why it's written this way, not just the answer	Purpose / condition → action / why / watch out / logic expression
Signal table and variable table	Real addresses and data types, ready to land in a project	Signal table + variable table + instance DB
Common questions and variants	Tells you in advance where people go wrong and how to extend it	Two fixed sections on every page
Can go into your own project	Otherwise you never leave "reading other people's code"	One-click import into TIA Portal via TiaLink

Those five criteria are also the order of this article: what it is, what's on one page, and how to turn it into your own practice.

2. What Learn-LAD is: one screen

Item	Detail
Entry	tia.hubwiz.com/learn-lad
Size	60 examples: beginner 23, intermediate 33, advanced 4 (verified 2026-10-17)
CPU tags	S7-1200: 57, S7-1500: 2, S7-300: 1
Multi-block projects	4 examples are tagged "multi-block", made of a main program + function blocks / functions + data blocks, and may include SCL
Page structure	Overview → signal table → workflow → network-by-network walkthrough → variables and data blocks → common questions → variants and extensions → related examples → next step
How to get it	Read directly on the page; program objects are imported through TiaLink — there is no file download
Import requirement	A Windows machine with a licensed TIA Portal install (TiaLink is currently built on V19 and Openness)

One thing to make clear up front: it is not a simulator, and it doesn't hand you a project file that opens with a double click. Every example can be read on the page; to get it into a project you go through TiaLink. That's both the limitation and the main difference from a "material pack": there's a pre-check before anything enters your project, and you save explicitly after.

3. What the 60 examples cover

Grouped by learning goal, they form roughly this ramp:

Learning goal	Representative examples	What you practice
Logic fundamentals	Circuit diagram → ladder, Basic digital logic (AND/OR), Technician logic drills	Series/parallel, normally closed contacts, the mapping between Boolean expressions and ladder
Buttons and state retention	Toggle output with one button, button-controlled solenoid valve, switch logic, oil pump control	Self-latching, set/reset, edge detection, "press once on, press again off"
Timers and counters	Coffee grinder timer, flashing indicator, automatic coffee machine, traffic light control	TON / TOF / TP differences, cascaded timers, counter-based phase switching
Interlocks and sequence control	Level pump start/stop, assembly line control, conveyor sorting, bottle filling and capping	Condition confirmation, interlocks, anti-short-cycling, multi-step sequences
Multi-block and SCL	SCL training: storage function block, SCL intro: FB calls, Factory IO connection, Sorting boxes (Factory IO)	LAD + SCL mixed, FB/FC/DB, main-program scheduling and layered business FBs

The size distribution shows the ramp too: beginner examples are mostly 1 block / 2–4 networks; intermediate ones reach 7–8 networks; the traffic light in the advanced row is 8 visible networks + 7 imported objects, and the Factory IO sorting box is 2 blocks / 19 networks, covering start/stop, infeed, left/right sorting, counting and outfeed.

4. Inside one page: the traffic light example

An example page doesn't just paste a ladder diagram and stop. The traffic light page, for instance, contains:

Overview: three phases (east → west → north), 20 seconds each (15 s green + 5 s yellow), implemented with SR start/stop + a counter for phase switching + three TP timers + comparison instructions.
Signal table: type (I / Q / M / TP / CTU), meaning and role of every point.
Workflow: the full sequence from START setting STARTED, through the three phases running, to the counter returning to 0.
Network-by-network walkthrough: every network follows the same template.

For example, network 2 (the phase counter) reads:

Purpose: increment the counter at the end of each phase; use CV to select the next phase.
Condition → action: falling edges of STEP1.Q, STEP2.Q, STEP3.Q (NContact) in parallel into the CU input of a CTU; PV = 3, and CV wraps to 0 after 3.
Why: one counter instead of three interlocked state bits keeps the phase logic much simpler; STEP*_FINISHED are the edge-memory bits for the three NContacts.
Watch out: NContact detects the falling edge — the instant the timer pulse ends — not the moment the timer starts.
Logic: COUNTER_STEP = CTU(CU = FALLING(STEP1.Q) OR FALLING(STEP2.Q) OR FALLING(STEP3.Q), PV = 3)

That short passage tells you three things: what the network is for, why it uses a counter instead of state bits, and the point people most often misread (the falling edge). That is far more productive than copying the diagram once.

Further down the page:

Variables and data blocks: the variable table (with %M addresses) plus the four timer / counter instance DBs TIA generates automatically.
Common questions: where to look first if phases don't switch, what to do when comments and phases don't line up, how to wire the lamp outputs from %M, which values to change together when you change a phase duration.
Variants and extensions: four phases / with left turn, night-time flashing yellow, pedestrian lights — each with a direction for the change.
Related examples and next steps: the "what to practice next" list, already ordered.

Two details worth noticing

First, the examples flag their own flaws. The traffic light page says in its common questions that the comment numbering on Networks 3/4 is off in the original project and to read it via CV and the actual network logic; the trash compactor cycle notes "the output uses a %I address, likely a typo"; the delayed lamp page notes "the lamp output in the point list is never driven in the block." Marking defects instead of hiding them is good for learners — real projects contain programs like this, and learning to spot them is more useful than pretending they don't exist.

Second, the page gives you a checkable logic expression. Besides the ladder diagram, every network has a line like STARTED = SR(SET = START, RESET = STOP). Its job isn't to replace the diagram — it's to let you cross-check between diagram and semantics: if the diagram doesn't make sense, read the expression; if the expression doesn't, go back to the diagram.

5. How to use it: three routes

Route A: read only (teaching, prepping, quick reference)

Nothing to install — just open the pages. Good for:

Self-study, working up the difficulty curve, and asking after each page "what happens if I remove XX?";
Training / classroom use, with a page as the worked example, the signal table as the board notes, and the common questions as discussion material;
On the job, when you need a small piece of logic (flashing, off-delay, level interlock) — come here and compare how it's written.

Route B: import into your own project (the recommended path)

This is the biggest difference between Learn-LAD and an ordinary example site. It's four steps:

Install and run TiaLink on Windows (default service address http://localhost:8080), and open the target TIA Portal project you want to import into at the same time.
On the example page click "TiaLink settings", confirm the address and test the connection. (If you started TiaLink with --api-token, enter the same value there; it's stored only in your browser's localStorage, never uploaded.)
Click "Import into my TIA project": pre-check first, then import.
Back in TIA Portal, save explicitly.

Three safe defaults to remember: there's a pre-check before import; same-named objects are not overwritten by default; nothing is saved automatically after import — so if you don't like the result, you can just abandon it.

After importing, take one more step: run it in S7-PLCSIM, force a few inputs, and see whether the output changes match the "workflow" section of the page. Read → import → verify in simulation — only after that loop is an example actually learned.

Route C: turn it into your own version

Every example page ends with "Variants and extensions". For the traffic light: add a phase, add night-time flashing yellow, add pedestrian lights. In each case you change a parameter or add a mode bit first, then extend the output mapping. Verify in simulation again — that's the transition from "reading someone's program" to "defining your own requirement and verifying it yourself", which is the jump the library is ultimately there to help you make.

Route	Who it's for	What you need	What you get
A Read only	Self-study, teaching, quick reference	A browser	Understanding + a logic explanation you can check against
B Import	Engineers / students with a TIA Portal setup	Windows + TIA Portal + TiaLink	Real project objects you can compile and simulate
C Modify	People who want to practice independent design	Everything in B + a bit of patience	Your own variant and a verification habit

6. A 4-week practice plan (copy it as-is)

Week	Suggested examples	Weekly acceptance test
Week 1	Circuit → ladder, basic digital logic, technician logic drills, toggle output	Without looking anything up, draw `Y=(A OR B) AND (NOT C OR D)` as ladder and explain the role of every NC contact
Week 2	Coffee grinder timer, flashing indicator, automatic door with delay, switch + timed output	Explain what TON / TOF / TP each do in that example; change a time parameter and predict the output change
Week 3	Level pump control, assembly line control, traffic light, multi-stage conveyor	Point out each example's interlocks; say what happens if a sensor chatters, and which part of the example exists for exactly that
Week 4	SCL training: storage FB, Factory IO connection, Sorting boxes (Factory IO)	Explain the division of labor between main program and FBs; import an example, compile it, and run the basic flow in simulation

7. Boundaries and caveats (read before you practice)

These are teaching examples, not safety programs you can put into production. Emergency stop, safety circuits and hard interlocks are hardware and functional-safety scope; no example replaces safety design and acceptance.
Many outputs use %M intermediate bits; map them to %Q for your own hardware before connecting real devices.
Import has environment prerequisites: TiaLink runs on the same machine as TIA Portal and is currently built on TIA Portal V19; MCP / clients can connect from another machine over the LAN.
Import does not equal trustworthy: pre-check, compile, simulation and human review are still all required. Automation saves you repeated copying and address mistakes; engineering responsibility stays with the engineer.
No file downloads — examples only enter a project via TiaLink, though everything is readable on the page.
The library keeps changing: the counts, categories and CPU tags in this article are as of the site on 2026-10-17; check the site for the current state.

8. FAQ

Q1: Does the library cost anything?
The example pages are free to read. Importing depends on TiaLink — see the TiaLink product page for current availability and licensing.

Q2: Can I use it without TIA Portal installed?
Yes, for reading and learning. But importing requires a licensed TIA Portal on the same machine, because TiaLink wraps TIA Portal's Openness capabilities and has to live next to it.

Q3: Can I download the program files from the site?
No. It's designed that way: no files land on disk, everything goes through TiaLink, so there's a pre-check before import and no automatic save after.

Q4: Will importing overwrite blocks with the same name in my project?
By default, no — same-named objects are not overwritten, and there's a pre-check first. Even after the import completes, the project isn't saved automatically, so you can inspect before deciding to keep it.

Q5: Can I use these examples directly on my machines?
Not recommended as-is. The point of a teaching example is to make the logic clear; before real hardware you still need I/O mapping, a safety assessment, commissioning and acceptance.

Q6: Is it suitable for teachers?
Yes. Every page has a signal table, workflow, network-by-network explanation and common questions, usable as worked examples, homework and discussion material; the import feature lets students bring the answers into their own project and verify.

9. Summary

What's missing when people learn ladder logic usually isn't "more knowledge" — it's enough complete, self-checkable practice. Learn-LAD puts 60 exercises into one consistent format: clear requirement, legible diagram, an explanation for every rung, address tables, and the usual pitfalls. Add TiaLink's "pre-check → import → explicit save" and the gap between "I understand it" and "it runs" is no longer a manual retyping exercise.

Where to start? Begin with toggle output — only 4 networks and 2 imported objects, but it already uses self-latching, edges and state evaluation. Then take on traffic light control.

Verification notes

The example library, page structure and counts come from the official Learn-LAD site tia.hubwiz.com/learn-lad, verified 2026-10-17; the import mechanism and version dependencies come from the TiaLink product page.
Example counts, categories and CPU tags are public site data; the current site version is authoritative.

An AI Agent Programmed a Siemens S7-1500 Through an MCP Bridge — Here's the SCL and the Race Conditions It Caught

tia-forge — Mon, 12 Oct 2026 15:00:26 +0000

We built an MCP server that drives Siemens TIA Portal V19 through the Openness API, pointed an LLM agent at it, and gave it a real engineering task: implement a conveyor-sorting control program for an S7-1500 (CPU 1511-1 PN), verified in S7-PLCSIM.

Not "generate a snippet." The whole loop:

add CPU → compile → start simulator → create FB/UDTs → write SCL → compile → download → verify.

I expected the code to be the interesting part. It wasn't. The interesting part is which engineering decisions the agent made, and where it drew a line and refused to cross it.

Here's what happened, with the actual code and the failure modes it flagged.

The toolchain

Agent: an LLM agent (WorkBuddy) that reads the spec, plans steps, writes code and tests.
Bridge: an MCP server (TiaLink) exposing TIA Portal operations over MCP — add device, create block, write SCL, compile, download, read back.
Target: TIA Portal V19 with Openness, S7-PLCSIM for verification.

The bridge runs on the same machine as TIA Portal (an industrial PC); the agent can run elsewhere as long as it can reach the bridge.

The prompt

Hardware and network configuration were already done. The task:

SCL state machine, with state numbers identical to the spec (so HMI, alarms, tests and field debugging all reference the same numbering)
Logic as a reusable FB with its own instance DB (line #2 becomes a second instance DB, not copy-paste)
Clear separation of i_ inputs / q_ outputs / stat_ internals
Use IEC timers (TON_TIME) — no hand-rolled scan-cycle accumulation
Implement: entry de-dup, quality-result latch, dual-cylinder interlock, fault latch, manual reset, normal stop
Every output must have a deterministic value every scan — no reliance on last-cycle residue
Emergency stop is only read as a safety-circuit status input; ordinary PLC code is not a safety function

Deliverables: FB SCL source, UDTs, state-transition doc, ≥10 automated test cases, boundary/race analysis.

And one line at the end:

"First add a CPU and check whether the simulator works."

That line is the part I actually cared about testing. Config tasks are judged from a screenshot. Programs are judged by behavior. So: does the agent build the verification environment first, or just start writing code?

The sequence it chose

Check whether a CPU already existed — only then add PLC_1 (CPU 1511-1 PN)
Compile, start S7-PLCSIM, confirm download/run works
Create FB_ConveyorSort and write the state machine in SCL
Create the needed UDTs
Call the FB in OB1 with instance DB DB_ConveyorSort_1
Compile + download — no errors
Deliver the state transition table, 14 test cases, and a race/boundary analysis

It built the verification environment first. Good sign.

The state machine

State	Name	Enter when	Main action	Exit → target
0	INIT	first scan	clear latches, fault code, commands	unconditional → 10
10	READY	power-on / reset / after stop	conveyor stopped, wait for start	start → 20
20	FEED	after start	conveyor runs; entry de-dup; latch quality; sort timeout	at sort pos → 30; timeout → 90; stop → 100
30	CHECK	at sort position	stop conveyor, branch on latched result	OK → 50; NG → 60
50	PUSH_A	judged OK	cylinder A extend, push hold	extended + hold done → 70
60	PUSH_B	judged NG	cylinder B extend, push hold	extended + hold done → 70
70	RETRACT	push done	cylinder retract, retract timeout	retracted → 80; timeout → 90
80	DISCHARGE	retracted	wait for part to leave sort position	sort photo-eye clear → 20
90	FAULT	any fault / safety circuit open	all outputs off, latch fault	reset + conditions OK → 10
100	STOPPED	normal stop	outputs off, restartable	start → 20

The SCL

Here's the full function block it delivered. Two things to look at as you read:

Section 0 writes every output to a deterministic value at the top of the cycle (requirement #6).
Section 7 is the final output mapping with the interlock and the same determinism guarantee.

FUNCTION_BLOCK "FB_ConveyorSort"
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1

VAR_INPUT
   i_xSafetyOK     : Bool;             // safety circuit healthy (1 = closed, run allowed)
   i_xStart        : Bool;             // start (edge-triggered)
   i_xStop         : Bool;             // normal stop (edge-triggered)
   i_xReset        : Bool;             // fault reset (edge-triggered)
   i_xPartAtEntry  : Bool;             // entry photo-eye
   i_xPartAtSort   : Bool;             // sort-position photo-eye
   i_xQualityOK    : Bool;             // quality result: 1 = OK
   i_xCylA_ExtEnd  : Bool;             // cylinder A extended limit
   i_xCylA_RetEnd  : Bool;             // cylinder A retracted limit
   i_xCylB_ExtEnd  : Bool;             // cylinder B extended limit
   i_xCylB_RetEnd  : Bool;             // cylinder B retracted limit
   i_tSortTimeout  : Time := T#5S;     // sort timeout
   i_tPushHold     : Time := T#800MS;  // push hold time
   i_tRetractTO    : Time := T#3S;     // retract timeout
END_VAR

VAR_OUTPUT
   q_xConveyor     : Bool;
   q_xCylA_Extend  : Bool;
   q_xCylA_Retract : Bool;
   q_xCylB_Extend  : Bool;
   q_xCylB_Retract : Bool;
   q_xFault        : Bool;
   q_xReady        : Bool;
   q_wState        : Word;
END_VAR

VAR
   stat_wState     : Word;             // current state
   stat_wFaultCode : Word;             // fault code
   stat_xFault     : Bool;             // latched fault
   stat_xCmdAExt   : Bool;             // cylinder A extend request
   stat_xCmdBExt   : Bool;             // cylinder B extend request
   stat_xQualityNG : Bool;             // latched quality result (1 = reject)
   stat_xPartSeen  : Bool;             // entry de-dup latch
   stat_xInTransit : Bool;             // part in transit
   stat_xStartEdge : Bool;
   stat_xStopEdge  : Bool;
   stat_xResetEdge : Bool;
   stat_xStartOld  : Bool;
   stat_xStopOld   : Bool;
   stat_xResetOld  : Bool;
   stat_tSortTO    : TON_TIME;         // sort timeout
   stat_tPush      : TON_TIME;         // push hold
   stat_tRetract   : TON_TIME;         // retract timeout
END_VAR

BEGIN
   // ---------- 0. write every output to a deterministic value each cycle ----------
   q_xConveyor     := FALSE;
   q_xCylA_Extend  := FALSE;
   q_xCylA_Retract := FALSE;
   q_xCylB_Extend  := FALSE;
   q_xCylB_Retract := FALSE;
   q_xFault        := FALSE;
   q_xReady        := FALSE;
   q_wState        := stat_wState;

   // ---------- 1. button edge extraction ----------
   stat_xStartEdge := i_xStart AND NOT stat_xStartOld;
   stat_xStopEdge  := i_xStop  AND NOT stat_xStopOld;
   stat_xResetEdge := i_xReset AND NOT stat_xResetOld;
   stat_xStartOld  := i_xStart;
   stat_xStopOld   := i_xStop;
   stat_xResetOld  := i_xReset;

   // ---------- 2. safety circuit: read-only, do NOT implement a safety function ----------
   IF NOT i_xSafetyOK THEN
      stat_wFaultCode := 16#0001;      // safety circuit open
      stat_xFault     := TRUE;
   END_IF;

   // ---------- 3. sensor plausibility checks ----------
   IF i_xCylA_ExtEnd AND i_xCylA_RetEnd THEN
      stat_wFaultCode := 16#0002;      // cylinder A contradictory position sensors
      stat_xFault     := TRUE;
   END_IF;
   IF i_xCylB_ExtEnd AND i_xCylB_RetEnd THEN
      stat_wFaultCode := 16#0003;      // cylinder B contradictory position sensors
      stat_xFault     := TRUE;
   END_IF;

   // ---------- 4. dual-cylinder interlock check (software supplement, NOT a hard interlock) ----------
   IF stat_xCmdAExt AND stat_xCmdBExt THEN
      stat_wFaultCode := 16#0010;      // both cylinders requested to extend
      stat_xFault     := TRUE;
   END_IF;

   // ---------- 5. fault reset (requires human confirmation AND recovered conditions) ----------
   IF stat_xFault THEN
      IF stat_xResetEdge
         AND i_xSafetyOK
         AND NOT (i_xCylA_ExtEnd AND i_xCylA_RetEnd)
         AND NOT (i_xCylB_ExtEnd AND i_xCylB_RetEnd) THEN
         stat_xFault     := FALSE;
         stat_wFaultCode := 16#0000;
         stat_wState     := 10;
      END_IF;
   END_IF;

   // ---------- 6. state machine ----------
   IF stat_xFault THEN
      stat_wState := 90;               // fault has priority, force fault state
   END_IF;

   CASE stat_wState OF
      0:  // INIT on power-up
         stat_xCmdAExt   := FALSE;
         stat_xCmdBExt   := FALSE;
         stat_xQualityNG := FALSE;
         stat_xPartSeen  := FALSE;
         stat_xInTransit := FALSE;
         stat_wFaultCode := 16#0000;
         stat_wState     := 10;

      10: // READY waiting for start
         q_xReady := TRUE;
         stat_xCmdAExt := FALSE;
         stat_xCmdBExt := FALSE;
         IF stat_xStartEdge THEN
            stat_wState := 20;
         END_IF;

      20: // FEED conveying
         q_xConveyor := TRUE;
         q_xReady    := TRUE;
         stat_xCmdAExt := FALSE;
         stat_xCmdBExt := FALSE;
         IF stat_xStopEdge THEN
            stat_wState := 100;
         ELSE
            // entry de-dup: latch only on "new part entered"
            IF i_xPartAtEntry AND NOT stat_xPartSeen THEN
               stat_xPartSeen  := TRUE;
               stat_xInTransit := TRUE;
               stat_xQualityNG := NOT i_xQualityOK;   // latch quality result
            END_IF;
            IF NOT i_xPartAtEntry THEN
               stat_xPartSeen := FALSE;               // part left entry, allow the next one
            END_IF;

            // sort timeout
            stat_tSortTO(IN := stat_xInTransit, PT := i_tSortTimeout);
            IF stat_tSortTO.Q THEN
               stat_wFaultCode := 16#0020;            // sort timeout
               stat_xFault     := TRUE;
               stat_wState     := 90;
            ELSIF i_xPartAtSort THEN
               stat_xInTransit := FALSE;
               stat_tSortTO(IN := FALSE, PT := i_tSortTimeout);
               stat_wState     := 30;
            END_IF;
         END_IF;

      30: // CHECK decide on latched result
         stat_xCmdAExt := FALSE;
         stat_xCmdBExt := FALSE;
         stat_tPush(IN := FALSE, PT := i_tPushHold);
         IF stat_xQualityNG THEN
            stat_wState := 60;                        // reject -> cylinder B
         ELSE
            stat_wState := 50;                        // OK     -> cylinder A
         END_IF;

      50: // PUSH_A extend A for a good part
         stat_xCmdBExt := FALSE;                      // interlock: B stays retracted
         stat_xCmdAExt := i_xCylB_RetEnd;             // only allow A after B is confirmed retracted
         stat_tPush(IN := stat_xCmdAExt, PT := i_tPushHold);
         IF i_xCylA_ExtEnd AND stat_tPush.Q THEN
            stat_xCmdAExt := FALSE;                   // push done, retract
            stat_wState   := 70;
         END_IF;

      60: // PUSH_B extend B for a reject
         stat_xCmdAExt := FALSE;                      // interlock: A stays retracted
         stat_xCmdBExt := i_xCylA_RetEnd;             // only allow B after A is confirmed retracted
         stat_tPush(IN := stat_xCmdBExt, PT := i_tPushHold);
         IF i_xCylB_ExtEnd AND stat_tPush.Q THEN
            stat_xCmdBExt := FALSE;
            stat_wState   := 70;
         END_IF;

      70: // RETRACT confirm retraction
         stat_xCmdAExt := FALSE;
         stat_xCmdBExt := FALSE;
         stat_tRetract(IN := TRUE, PT := i_tRetractTO);
         IF (stat_xQualityNG AND i_xCylB_RetEnd)
            OR ((NOT stat_xQualityNG) AND i_xCylA_RetEnd) THEN
            stat_tRetract(IN := FALSE, PT := i_tRetractTO);
            stat_wState := 80;
         END_IF;
         IF stat_tRetract.Q THEN
            stat_wFaultCode := 16#0030;               // retract timeout
            stat_xFault     := TRUE;
            stat_wState     := 90;
         END_IF;

      80: // DISCHARGE wait for the part to leave the sort position
         stat_xCmdAExt := FALSE;
         stat_xCmdBExt := FALSE;
         IF NOT i_xPartAtSort THEN
            stat_wState := 20;
         END_IF;

      90: // FAULT latched
         stat_xCmdAExt := FALSE;
         stat_xCmdBExt := FALSE;
         stat_tSortTO(IN := FALSE, PT := i_tSortTimeout);
         stat_tPush(IN := FALSE, PT := i_tPushHold);
         stat_tRetract(IN := FALSE, PT := i_tRetractTO);

      100: // STOPPED normal stop
         q_xReady    := TRUE;
         stat_xCmdAExt := FALSE;
         stat_xCmdBExt := FALSE;
         stat_xInTransit := FALSE;
         stat_tSortTO(IN := FALSE, PT := i_tSortTimeout);
         IF stat_xStartEdge THEN
            stat_wState := 20;
         END_IF;

      ELSE
         stat_wFaultCode := 16#00FF;                   // illegal state
         stat_xFault     := TRUE;
         stat_wState     := 90;
   END_CASE;

   // ---------- 7. output mapping: interlock + deterministic value each cycle ----------
   q_xCylA_Extend  := stat_xCmdAExt AND NOT stat_xCmdBExt AND i_xCylB_RetEnd;
   q_xCylB_Extend  := stat_xCmdBExt AND NOT stat_xCmdAExt AND i_xCylA_RetEnd;
   q_xCylA_Retract := NOT q_xCylA_Extend;
   q_xCylB_Retract := NOT q_xCylB_Extend;

   q_xFault := stat_xFault;
   q_wState := stat_wState;
END_FUNCTION_BLOCK

Note: this assumes double-acting cylinders where retract is the de-energized safe direction. For spring-return cylinders, the "retract output" should be forced to 0 (de-energized = retracted) rather than commanded.

The UDTs

A parameter UDT so multiple lines can reuse the same FB:

TYPE "UDT_SortParams"
VERSION : 0.1
   STRUCT
      SortTimeout : Time := T#5S;      // sort timeout
      PushHold    : Time := T#800MS;   // push hold time
      RetractTO   : Time := T#3S;      // retract timeout
   END_STRUCT;
END_TYPE

A status UDT for HMI display and online diagnostics:

TYPE "UDT_SortStatus"
VERSION : 0.1
   STRUCT
      State        : Word;             // current state
      FaultCode    : Word;             // fault code
      FaultLatched : Bool;             // fault latched
      QualityNG    : Bool;             // quality result latched
      PartSeen     : Bool;             // entry de-dup latch
      InTransit    : Bool;             // part in transit
   END_STRUCT;
END_TYPE

The 14 test cases it shipped

#	Name	Precondition	Action	Expected
TC-01	Power-on init	downloaded to sim	first scan	state 10, all outputs 0, no fault
TC-02	Normal start	state 10	press start	state 20, conveyor runs
TC-03	Good part sort	state 20	part at entry, quality OK, reaches sort pos	20→30→50→70→80→20, cylinder A extends then retracts
TC-04	Bad part sort	state 20	part at entry, quality NG	20→30→60→70→80→20, cylinder B extends then retracts
TC-05	Entry de-dup	state 20	part sits at entry for 100 scans	`PartSeen` latches once, no repeat triggering
TC-06	Sort timeout	state 20	part doesn't reach sort pos within 5 s	state 90, fault 16#0020 latched
TC-07	Fault latch + reset	state 90, conditions recovered	press start, then reset	start ignored; reset + conditions OK → state 10
TC-08	Reset refused	state 90, safety circuit still open	press reset	reset ineffective, stays in state 90
TC-09	Normal stop + resume	state 20	press stop, then start	stop → state 100 outputs safe; start → state 20
TC-10	Dual-cylinder interlock	state 20	force both extend requests = 1	fault 16#0010, neither cylinder extends
TC-11	Contradictory position sensors	any	force A ext-end and ret-end = 1 together	fault 16#0002 latched, state 90
TC-12	Safety circuit open	state 20	`i_xSafetyOK = 0`	outputs drop immediately, state 90 latched; needs reset after recovery
TC-13	Retract timeout	state 70	cylinder doesn't retract within 3 s	fault 16#0030, state 90
TC-14	Output determinism	any	single-step and watch outputs	every scan all outputs have defined values, no residue

The race conditions it flagged (the actually useful part)

Entry de-dup vs. sensor sticking — latching until the part leaves the entry photo-eye de-dupes naturally, but only if the part actually leaves; otherwise later parts get missed. The process must guarantee single-piece spacing.
When to latch the quality result — it latches at the entry, not at the sort position, because the quality system's result may not be stable by the time the part arrives, and you'd race the position signal. If quality detection is slow, use a handshake/queue instead of just delaying the read.
Arrival vs. timeout in the same scan — IEC TON sets Q = TRUE on the scan it reaches PT. It checks timeout before arrival and explicitly resets the timer on arrival. If you want "arrival wins," you must reorder.
Re-trigger after push — the part can still briefly cover the sort photo-eye. Going 70→20 directly would cause a double-sort. State 80 (DISCHARGE) waits for the eye to clear before re-arming.
Interlock layering — software only stops "logically simultaneous requests." It does not replace pneumatic/electrical hard interlocks or mechanical limits.
Button priority in the same scan — fault/safety > stop > reset > start, and this must be frozen in the requirements or implementations will diverge.
"Stop" has two meanings — immediate vs. finish-current-part. It implements immediate (state 100); a controlled finish needs a StopPending flag.
PT = 0 boundary — TON fires immediately, which can turn a timeout into a guaranteed fault. Validate the lower bound if the time is HMI-writable.
Held reset button — edge-triggered, so a long press doesn't keep masking a recurring fault.
First-scan init — state 0 does init; a proper project would also use OB100. Kept state 0 so init stays visible and testable inside the state machine.
Multiple instances — timers and edge memories live in FB statics, so never share one instance DB across lines.
Sim ≠ field — the simulator doesn't model photo-eye chatter, pneumatic delay, or safety-circuit response time. All times must be tuned on the real machine.

The three things it explicitly refused to do

This is the part I think matters most, and why I wrote this up at all:

Emergency stop must be realized by a hardware safety circuit (safety relay / safety PLC). The program only reads i_xSafetyOK.
Dual-cylinder hard interlock must be pneumatic or electrical. The software interlock is supplementary.
Time parameters and sensor tuning must be done on the real machine. The simulator can't give you real chatter or pneumatic delay.

It did the software part and handed the responsibility it can't carry back to a human. It didn't pretend to have "finished" something it hadn't.

That's the property I'd want from any code generator touching industrial control: generate the verifiable part, and be explicit about what it can't verify.

Honest caveats

The simulator passing does not mean it's field-ready.
I only checked that the code compiles, downloads, and matches the test cases at a logical level — I did not bench-test on real hardware.
The agent's self-reported step log is in the full write-up; treat model self-reports with the usual skepticism.

Full write-up with screenshots, the complete source, and the agent's step log: AI-powered PLC programming with WorkBuddy + TiaLink.

Disclosure: I work on TiaLink, the MCP bridge that drives TIA Portal, built by our team at 汇智网 (hubwiz.com). The agent used in this experiment was Tencent's WorkBuddy.