DEV Community: tia-forge

Two Routes to Connect AI to TIA Portal: 6 Tools, and Only 4 Can Write LAD

tia-forge — Thu, 05 Nov 2026 16:17:39 +0000

Putting an LLM next to a Siemens TIA Portal project in 2026 means picking one of two routes. I picked six tools that have public pages you can actually check: four can write LAD, only three can run a test — and counting LadDoc next to TiaLink is what gets LAD to four.

How this was checked. Five of the six entries come from vendor pages read on 2026-10-02 and 10-25; the TiaLink row comes from its own product docs and hands-on use. Every cell a vendor does not state explicitly is marked "not stated" — that is not the same as "missing", and only someone who has installed the thing can tell the difference.

1. Two routes: whose model is it

Everything on this list falls on one line.

Route A — a purpose-built agent. The model is fixed, TIA knowledge is baked in, it works out of the box. You describe the job, review the result, sign off. You never pick a model and never touch MCP.

Route B — your own agent plus a tool. You choose the brain: Claude Code, Codex, Cursor, whatever. The tool layer only supplies hands — read blocks, edit blocks, compile, run a simulation. The tool can be an MCP server, an HTTP API, or a command-line program; the wiring changes, the route doesn't.

	Who supplies the model	What you have to do	The cost
A · purpose-built agent	The vendor	Describe, review, sign	Model is not swappable; offline and intranet use is the vendor's call; switching clients means starting over
B · your agent + a tool	You	Install the tool, configure the client, write prompts, define acceptance	Free choice, but you own both the tool quality and the model quality

A sells an outcome; B sells a capability. That single sentence decides everything downstream: do you want an assistant that hands back finished work, or a set of tools you can wire into your own pipeline?

2. Six tools, split by route

#	Tool	Route	Form	Versions	Model
1	Siemens Industrial Copilot	A	In-product add-in	Recent TIA Portal	Vendor, fixed, cloud
2	Siemens Eigen Engineering Agent	A	In-product add-in	V19 U5+ / V20 U4+ / V21	Vendor, fixed, cloud only
3	AnyAutomation Studio	A	Desktop IDE	V15–V21	Your own key, fully local possible
4	Coilmind	A	Desktop client	V17–V21	Included, own key optional, local supported
5	T-IA Connect	B	REST + MCP	V17–V21	Your own key or a local model
6	TiaLink	B	HTTP MCP	V19–V21	Any MCP client, local or national models

Four A, two B. The split is not accidental: A sells convenience, so it bundles model and knowledge; B sells connectivity, so it hands the model back to you.

What is not in the table, and why: the open-source side has plenty of projects, but they stop at primitives plus generation and leave verification to you; and pasting code into a browser chatbot is not a route at all — it cannot reach the project.

A1: vendor agents — deepest, least free

Eigen is the April 2026 generation: an add-in that talks to the project directly, emits SCL and LAD, generates test and validation logic, and also covers HMI scripting, drives and axes, PROFINET topology, and bulk hardware import from a spreadsheet. It coexists with the 2023 chat-style Industrial Copilot rather than replacing it — one answers a question inside TIA Portal, the other finishes the job.

Its boundaries are all in Siemens' own documentation: fixed model, cloud only, S7-1200 and S7-1500 only, no older TIA versions, not approved for fail-safe programming, and no documented source-control integration. Those are not defects; they are the product definition — it guarantees behaviour Siemens has certified, not whatever model you want.

Locking the model has a rationale: in industrial software the hard part is not getting an LLM to write code, it is making the result accountable — who verified it, on which version, against which test cases. Fixed model plus a certified behaviour envelope is the shortest path to a closed responsibility chain. The price is that you cannot swap in a model you fine-tuned, and cannot wire generation into your own pipeline.

Deepest integration and least freedom, in the same product. If your work is standard TIA Portal, it is the cheapest path; if you need your own agent, your own model, or your own CI, it was never designed to leave you a door.

Siemens' own launch visual for Eigen (April 2026). The form factor of this generation: a plug-in plus cloud, with the engineer still at the desk.

A2: third-party purpose-built clients

This group is not tied to a vendor. It ships its own model and its own TIA knowledge, and sells "install it and work".

AnyAutomation combines an engineering IDE with an agent: versions all the way back to V15, local models (Ollama, LM Studio) as first-class options, SCL unit tests on PLCSIM Advanced, and a diff you approve before anything is imported. Coilmind covers every block type except F-blocks, documents its simulation testing down to PLCSIM Advanced V3–V6, and also lets you swap in your own key.

AnyAutomation Studio. The line on the right says what this category sells: 12 of 12 test cases passed on PLCSIM Advanced — the verification result is on screen, not in the marketing copy.

The smart part of this group is that it separates the two choices: the model can be yours, the client and the engineering surface stay theirs. You swap the brain, not the hands.

A category-wide trait: these tools are thick by construction — context, generation and verification arrive bundled, and you have no thinner option. Thin-versus-thick only becomes a real choice on route B.

B1: three ways to wire a tool, not one

"Does it support MCP?" answers nothing. MCP is only one of the wirings.

Wiring	Who works out what tools exist and what arguments they take	What comes back	Fits
MCP (local process)	The protocol describes itself; the client reads the tool list and schemas	Structured results	One person, one machine, one client
MCP (HTTP endpoint)	Same, but the service lives independently of the client	Structured results	Several clients, scripts, CI sharing one service
HTTP API / CLI	You, or the agent reading documentation	Usually text or a JSON string	Gluing onto existing systems, throwaway scripts

The difference is who is responsible for explaining the tool list and its parameters: with MCP the model reads it, with HTTP and CLI somebody has to write it down, otherwise the model guesses arguments — which is where hallucinations usually start. CLI has an underrated advantage: no service to install, no client config to edit, any agent with a shell can use it. The price is that arguments have to be assembled correctly every single time, and there is no state to carry between calls.

Verification splits into two levels, and they get conflated constantly. Unit verification checks what one block or one stretch of logic does for a given set of inputs — fast, no full hardware configuration, a hundred scenarios in a row. Whole-machine verification checks whether the entire project comes up on a virtual CPU: how OBs are scheduled, how the I/O image updates, how blocks call each other, how the HMI behaves. The first is cheap, the second is real. They are not alternatives; they are two rungs of the same ladder.

How the two B-route tools split across those rungs:

	Unit verification	Whole-machine verification	Where context comes from
T-IA Connect	Test harness (running on PLCSIM)	Not stated	Project reports and dependencies
TiaLink	Its own engine, no TIA Portal required	PLCSIM	Built-in project knowledge graph

Same task, different rung and different data source — which decides what the tool can answer for you.

B2: the two thick ones

T-IA Connect is the broadest in surface area: blocks and snapshots, project reports, a test harness, version management, several hundred tools exposed to an agent, V17 through V21, both REST and MCP. Its approach is to build the engineering platform first, then let an agent connect to it.

T-IA Connect's first screen. "100% on-premise" is a deliberate first-screen claim — that is the first dividing line between this class and cloud offerings.

TiaLink takes the other path: primitives, generation and whole-machine verification in one endpoint on the same machine — bulk import/export, generate SCL and compile, bulk HMI screen generation, start PLCSIM and run a test, then read the project back. Project-level context lives in the gateway as a knowledge graph; LAD generation is handled by another endpoint in the same product line, on purpose. Section B3 explains why.

Wiring matters a second time here: a local-process gateway lives inside the client process, so closing the client kills the connection and switching clients means reinstalling; an HTTP endpoint runs on the same machine as TIA Portal and can serve Claude Code, Codex, your own scripts and a CI job at once, without fighting each other; a CLI is the lightest, but stateless — every call reconnects to the project.

A gateway is a hand. The capability layer is an eye. With only a hand you have to trust what the AI says; with an eye you can look.

B3: why three endpoints instead of one program

Compressing each vendor into one table row creates a false impression: that "thick" means "everything stuffed into one binary".

Split, it is clearer. Producing a LAD block that TIA Portal will import, and running that logic to see if it behaves, are two different jobs: the first is deterministic generation (the same description always produces the same XML, identifiers and wiring assigned automatically, no output at all if validation fails), the second is deterministic execution (same program, same inputs, same result, every time). Written as one program, both get worse.

So the line is three endpoints, not one program:

Endpoint	What it does	When you reach for it
Engineering operations (TiaLink, with the project knowledge graph inside)	Read the project, create and edit blocks, bulk import/export, compile, run PLCSIM, read back after writing; the graph answers "who calls whom, what breaks if I change this"	TIA Portal is installed and you are changing a real project
LAD generation (LadDoc Cloud)	JSON ladder description → validation → SimaticML block, importable as-is	A description has to become an importable block
Unit verification (cloud simulation)	Executes one block or one stretch of logic scan by scan — scripted cases, exhaustive matrices, seeded fuzzing, invariants	Behaviour check right after a change; no TIA Portal on the machine; batch regression

All three are MCP, all three are callable by the same agent, and each works alone.

The graph deserves its own paragraph. In most tools "context" means the project tree plus a block list — the AI knows which blocks exist, not how they interlock. The project knowledge graph parses an exported project into a queryable model: who calls whom, which network reads or writes which tag, how a signal flows from a physical input to its consumers, which call sites an interface change reaches (transitive, not one hop), dead code, and the classic hazard of several places writing the same signal, plus fan-in, fan-out and call depth. Ask in natural language; the answer carries exact locations.

One impact graph from the knowledge graph. The question is "what does changing this block touch"; the answer is a transitive closure — call sites, instance DB, the enclosing network and OB, all the way to the block file.

It is a read-only analysis layer; edits happen on the engineering side. Analysis and execution being separate is itself a safety boundary: the thing that can tell you what a change would do has no permission to make it. It has limits, too — it works from an exported snapshot rather than a live controller, covers LAD, SCL and FBD (older languages are recognised but not analysed in depth), and excludes hardware configuration and HMI content.

One pleasant side effect of the split: people without TIA Portal can see results first. An unfinished block goes to the cloud engine, comes back passing, and only then travels to the machine that has TIA Portal. The reverse holds as well: when an import fails, go back to the generator and read the validation report instead of poking at TIA Portal.

The cloud engine verifies the unit, not the machine: it executes one ladder rung or one SCL program scan by scan — contacts, coils, timers, counters, edges, block calls, jumps — with scenarios that can be scripted cases, exhaustive matrices, seeded fuzzing, or invariants, returning PASS/FAIL in one call. It does not replace PLCSIM: PLCSIM checks whether the whole project comes up on a virtual CPU (OB scheduling, I/O image, inter-block calls, HMI), and that step still needs TIA Portal.

Once separated, the value is obvious: unit verification is cheap enough to run after every block edit; whole-machine verification is expensive enough that it only happens at milestones. Without the cheap rung, every AI edit waits until you have time to open TIA Portal.

What each route struggles with

A's problem in China's plant networks is connectivity: the model lives in a vendor cloud, and the internal network either has no route or needs an approval. That is compliance, not capability, and the bigger the plant the harder it gets. B's problem is scaffolding: a thin wrapper gives you a hand and nothing else — context and acceptance criteria are yours to build. The same route can go smoothly or end in "the AI writes worse code than I do"; the difference is usually not the tool but whether you have an acceptance process (section 6).

3. Of six, four can write LAD and three can run a test

The two numbers are not ratings; they are structural. LAD requires a structured description — element identifiers, wiring, branches, ordering — so one wrong identifier kills the whole import. Plenty of tools write SCL; only four write LAD, and LadDoc makes five. Testing requires an interface to a simulator, downloading the block, feeding inputs and reading results; three tools have that whole chain (AnyAutomation, T-IA Connect, Coilmind), and TiaLink makes four.

Siemens' Eigen says it "generates test and validation logic"; whether that executes on a simulator disagrees across two public sources, so it is not counted.

All three of those run PLCSIM Advanced, which means whole-machine verification and a Windows box with TIA Portal installed. Exactly one tool here can do unit verification of a single block without TIA Portal: TiaLink. Why that rung deserves its own column is in B3.

Generating is the entry ticket; verifying behaviour is what counts as integration.

4. "Wiring AI up" and "integrating AI" are two different things

There is a near-miss worth naming: OPC UA or Modbus can also "connect AI to TIA Portal" — but that path only exposes runtime data: tag values, registers, alarm bits. An AI that sees tag values still cannot see program blocks, cross-references, or compile errors, so it cannot change a program.

The test is simple: if the AI can see blocks and trigger a compile, that is integration; if it only sees values, that is data collection. You want both eventually, but never confuse them — one of them cannot fix a bug in an FB.

5. Building your own tool: five traps

Whether you install an existing tool or write your own, these five arrive within the first two days. None of them depends on your language or framework; they come from how TIA Portal is built.

One: a version upgrade splits the assemblies. The single engineering assembly of earlier versions was split — as of V21 — into base, PLC, HMI and safety assemblies in a new subfolder. A PLC-only tool must reference both base and PLC; namespaces are unchanged, but reference lists and runtime resolution paths are not.

Two: Copy Local has to be off. Copying the assemblies next to your binary fights the copy TIA Portal already has loaded — at best a load failure, at worst strange behaviour. Reference them, do not copy them.

Three: resolve assemblies by name at runtime. Since you are not copying, the program has to register a resolver before it touches any engineering type, looking assemblies up by simple name in the TIA Portal install directory.

Four: build once per major version. The binaries are not compatible across versions; one build, one version.

Five: default to a preview mode and return structured results. Writes should simulate first and only commit when explicitly allowed; and what comes back to the model should be structured data, not log text — logs invite the model to guess what happened.

Each of these costs half a day to two days. Together they are the real price of "build it yourself": not the install, but redoing it every time a version ships.

6. Acceptance: zero compile errors is only layer one

The most misleading sentence after an AI writes code is "it compiles". Five layers, each proving something different:

Layer	Proves	Cannot prove
Structural validation (pre-import)	Syntax is valid, names do not collide	Whether the logic is right
Compile	Types, references, addresses, instruction usage	Behaviour across scan cycles
Unit verification (one block / one stretch)	Behaviour for given inputs, edges, counting, interlocks	How blocks interlock, how OBs schedule, how the I/O image updates
Whole-machine verification (PLCSIM)	The project comes up on a virtual CPU; scheduling and I/O image hold	Real I/O and field disturbances
Read-back comparison	What is in the project equals what you think you wrote	Whether the requirement itself is right

The middle layers are the ones people skip, and they are the valuable ones.

A real example: during a refactor an impulse timer became an on-delay timer. Compile: 0 errors, 0 warnings. The code looked entirely normal. Under unit verification the motor simply would not turn — the difference was one instruction name, and the compiler cannot object because both are type-correct. After reverting, the same program passed 5,735 scans.

That is why "it compiles" is not a delivery criterion. It catches wrong types and wrong addresses; it cannot catch wrong semantics — and in control engineering the errors that hurt are almost always semantic.

Zero compile errors proves it looks like a program. Unit verification proves it means what you think. Whole-machine verification proves it still works once installed.

7. Choose by the work in front of you

Your situation	Route	Why
Standard TIA Portal workflow, want vendor backing	A1 (Eigen)	Deepest integration, vendor support when it breaks
Want out-of-the-box, but your own model	A2 (AnyAutomation / Coilmind)	The client is theirs, the model can be yours
Need Git, CI, test reports	B (T-IA Connect)	Version management and a test harness are part of the product
Already have an agent, just need hands	Build your own (section 5)	Light, hackable, no network needed
Need to know "will this change break another block"	The thick B side (with a knowledge graph)	A thin wrapper has no call graph or data flow to query
On-site network cannot reach a cloud	A2 with local models, or the thick B side	Model runs on the machine, the project never leaves it
Projects on V17 / V18	A2 (goes back to V15) or the B side	The vendor agents do not cover older versions
Want to verify logic before TIA Portal is installed	Unit verification (cloud)	A single block can return PASS/FAIL without an engineering box

8. Three boundaries

Fail-safe programs are off limits. Siemens' own documentation excludes F-programs; third-party tools should not go further. Responsibility for F-program validation sits with people and the certification process.

Versions are hard-bound. A tool supports the versions it says it supports. Older projects either get their logic verified in simulation first, or need a route with a wider version range.

Write protection belongs in the process, not in a warning. Preview before write, read back after write, snapshot before bulk changes — those three do more than any "please be careful" notice.

9. Four questions that come up

Does TIA Portal need anything extra enabled? Yes. Openness — the interface that can read and write the project — is not on by default. It must be selected during installation, and the Windows account running the tool has to be in the Siemens TIA Openness group. Without both, nothing connects, and the error will not tell you why.

Does it need internet access? Depends which part. Engineering operations do not: the model can run locally and the gateway sits on the same machine as TIA Portal, so the project never leaves it. LAD generation and cloud simulation are online services — useful when there is no TIA Portal yet, or when a batch needs regression. Vendor agents are cloud inference, so connectivity is a hard requirement.

Once a gateway is installed, can the AI change programs? It can — but do not start there. Let it read only for a week: read blocks, read cross-references, read compile errors, answer questions. When its understanding survives your spot checks, enable writing, and make preview and read-back part of the process.

Can AI-written ladder logic be downloaded to a real machine? Not directly. Even after all five layers, on-site work is only the first small step of the last one: simulate, dry-run, single machine, then commissioning. That order has nothing to do with whether AI wrote the code.

Sources

AI tools for TIA Portal compared: who writes LAD, who tests, who runs offline, svghmi.pro, checked 2026-10-02
Best AI for PLC Programming 2026: 9 Tools Compared, anyautomation.ch, 2026-10-25
Building a Siemens TIA Portal MCP Server on Openness V21: A Hands-On Guide, controlbyte.tech, updated 2026-10-29
Siemens Eigen Engineering Agent launch and product pages (version range, cloud-only constraint, fail-safe boundary)

Vendor pricing and licensing change fast, so this piece lists billing models rather than amounts. "Not stated" means the vendor's public pages do not say; it does not mean the capability is absent.

What this comparison adds

The two routes are not "new tool versus old tool"; they are two ways of selling. A sells an outcome, B sells a capability — and inside B, thickness varies by an order of magnitude. The open-source projects stop at primitives or generation: light, fast, offline-friendly, but with no cross-reference data and no verifier, so they can change things without being able to tell you what the change breaks.

The thicker approach is to split the work into three callable endpoints: engineering operations (with the project knowledge graph inside), LAD generation, and unit verification. Each has its own determinism — the same description always produces the same XML, the same project parses to the same graph, the same program with the same inputs always gives the same result — so each can be accepted on its own and still be chained by one agent.

Context is where the spread is widest: exactly one of the six offers a program-level graph instead of a project tree and a block list. And that graph is read-only, with edits happening on the engineering side: the thing that can tell you what a change would do has no permission to make it.

Selection advice, in reverse order of how people usually ask: first ask whether your model can stay on your machine, then whether you can see and verify what the AI changed, and only then how good its generated code looks. The first two decide whether you can deploy at all; the last one only decides how pleasant it is.

Three entry points: TiaLink (engineering operations, V19 / V20 / V21, same machine as TIA Portal); LadDoc Cloud (LAD generation, produces importable blocks); cloud simulation (run ladder and SCL scan by scan without TIA Portal). Cross-references and call relationships are queried inside the engineering endpoint.

AI + PLC Programming: The Missing Layer Is Project Context, Not Model Quality

tia-forge — Wed, 04 Nov 2026 13:41:17 +0000

Ask an AI agent "who reads and who writes additional_variables.tag3?" in a real TIA Portal project, and you can tell within one reply whether it is guessing.

A grounded answer is four rows: two contacts reading it at lines 152 and 222, two coils writing it at lines 217 and 262, all inside Auto_mode, network 1. An ungrounded answer is a paragraph that sounds right.

That gap — four rows versus a paragraph — is not a model-quality problem. Current models write SCL fine. It is a project-context problem: a PLC project is a graph, and we keep handing the model a stack of files.

Three ways agents get project context today, and what each one loses

Approach	Answers well	Silently loses
Paste the export into the prompt	"What does this network do?"	Anything over the window; all cross-block coupling once you truncate
Global search / grep	"Where does this string appear?"	Direction (read vs. write, call vs. instance), and the absence of an expected relation
Let the agent browse and remember	Short sessions, one block at a time	Freshness — it may be reasoning over what it read 40 turns ago, and it will not say so

Chunking is the worst of the three, because the relationships you most need are exactly the ones that cross the chunk boundary. In a ladder program that boundary is everywhere: a coil in network N3 writes a tag that a contact in network N7 reads, and the tag itself is defined in a tag table that is a third file.

What a project graph actually holds

The graph we used has four kinds of content, and you need all four:

Part	What's in it	What it answers
Nodes	Blocks, networks, interface members, tags, LAD parts (contacts/coils/boxes), SCL statements	"What is in this project?"
Edges	Call, instantiate, type, read, write, wire	"Who calls whom, who writes this tag?"
Provenance	A label on every edge: parsed from a call / parsed from an operand / structural containment / tag-table membership / wire	"Is this claim evidence, or an inference?"
Unresolved references	Names that are referenced but defined nowhere in the project; deliberately not forced into an edge	"What is missing?" — the most valuable list before a handover or a migration

That third row is the part people skip. In a graph built from a real project, "tag3 is written by a coil in Auto_mode" and "tag3 is written by a coil in Auto_mode, per an operand parse, line 217" are different claims with different trust levels. If your agent cannot separate them, you are back to prose.

The run, with numbers

Target: PLC_SCADA_HMI, an MIT-licensed open-source project (rassulz/multirobot_painting_control_system), opened in TIA Portal V19 on an S7-1500 / ET200MP station, CPU 1513F-1 PN (6ES7 513-1FL02-0AB0, firmware V2.9). Read-only the whole way: no imports, no block edits, no save, project dirty flag unchanged.

Metric	Measured
Build time, from scratch	1.2 s (one sentence to the agent; no further project access after that)
Nodes	227
Edges	517 — containment 220, calls 2, instantiation 2, reads 87, writes 52, wires 154
Unresolved references	8 (7 "pending", 1 "external")
Project size	OB1 (4 networks), 2 FBs, 2 instance DBs, 2 tag tables (51 tags), 0 UDTs, 0 duplicate names

1.2 seconds is not the interesting number. The interesting number is 517 edges against 227 nodes — the relationship layer is twice the size of the object layer. That ratio is the reason a context window is the wrong container: you don't have a document of 227 things, you have a network of 517 claims about them.

Three checks before you believe any answer

Any graph-derived answer is only as good as its freshness, and the failure here is silent. Before asking your first real question, get three facts:

Which project is the graph attached to? (should be the one you're analyzing — here, PLC_SCADA_HMI)
When was it built? If you edited a block after the build, the graph is stale and nothing will tell you.
Was it built from the currently open project, or is it a leftover graph from last week? A stale graph looks completely healthy. It just describes a project that no longer exists.

If any of the three is unclear: rebuild, then ask. Two related traps: an empty graph gets rejected outright (the previous graph is kept, so you may be looking at yesterday's), and a graph query that hits its result cap says so — "there's more" — which means you have not seen the project, you have seen a page of it.

One probe at a time

The single most repeated mistake in this kind of analysis is batching six questions into one prompt, getting a long answer, and not noticing that section four was truncated. Six probes, six turns, each verifiable on its own:

#	Probe	Question	What a good answer looks like
1	Inventory	What's in this project: blocks (type/number/language/network count), instance DBs, tag tables, UDTs, CPU and order number? List duplicates separately, write 0 where empty	A table that reconciles against the TIA project tree, with explicit zeros
2	Find	Find `Auto_mode` (or `CV-101`, or `Conveyor`), widening exact → prefix → comment word → contains; tell me which tier matched and whether results were truncated	The match tier named, plus "there is more" if there is
3	Dissect	Open `OB1::Main` once: interface, each network, what it calls, read/write list, unresolved refs inside the block; say which part was truncated	One block, one page, complete
4	Relations	Who reads and who writes `additional_variables.tag3`? Reads and writes separately, each with block + network + line + provenance	Rows, not sentences
5	Impact	If I change or delete `FB::Auto_mode`, what is affected? By depth, and through which relation?	Depth-numbered hits
6	Gaps	List every unresolved reference with file and line, mark pending/external, classify truly-missing / external-library / to-be-added; do not guess	A table you can act on

Probe 2 is worth its own paragraph. On this project, Auto_mode matched four things — the FB, a call site Main::N1::I1, its file, and its network — and the answer came back with "there is more". Without the "was it truncated" question you would have concluded "four references" and been wrong. Ask about truncation every single time. It costs one sentence and it is the difference between an inventory and a sample.

The payoff: four rows you can take to a review

Probe 4, verbatim result for additional_variables.tag3. First the shape, then the table — because the shape is the part prose loses:

Sample subgraph — the full graph is 227 objects / 517 relations. Green = call, blue = read, orange = write, grey dashed = containment and LAD wiring, purple dash-dot = tag-table membership. Figure labels are Chinese; every identifier in it is the one used in the text, and every arrow can be traced back to a line number.

Relation	Source	Line	Provenance
member of tag table	`additional_variables`	—	tag-table containment
read	`Auto_mode::N1::L13` (contact)	152	operand parse
write	`Auto_mode::N1::L26` (coil)	217	operand parse
read	`Auto_mode::N1::L27` (contact)	222	operand parse
write	`Auto_mode::N1::L35` (coil)	262	operand parse

Two things to notice. First, reads and writes are separate columns of truth: 2 reads + 2 writes means a change to this tag touches four ladder positions, all between lines 152 and 262 — that is the entire software blast radius of the change, stated as a list of places. "This tag is used in the auto mode block" is not that; it cannot be checked and it cannot be assigned.

Second, the line numbers make the claim auditable. Not "trust me, the graph says so" — open the XML, go to line 217, look at the coil. If an audit finds the graph wrong at line 217, you now know something about the graph for every subsequent answer. This is the whole reason to prefer a graph over a summary: it gives reviewers a way to be lazy safely.

Impact analysis: the default edges answer a different question

For FB::Auto_mode, the default relation set (call / instantiate / read / write) gives:

Depth	Through	Hit
1	call	call site `Main::N1::I1`
1	instantiation	instance DB `InstanceDB::Block_1_DB`

Which reads as one honest sentence: Auto_mode is called from network 1 of the main program and its instance DB is Block_1_DB; change the interface and both need a look.

But "which block does it live inside?" is not in that answer, because containment is not part of the default set. Add containment and walk up — the two layers are drawn on the same figure below: the green/violet edges are what the default relation set can answer, and ①–④ are the containment chain that only appears once you add it.

Arrows are drawn in the normal containment direction (outer source file → block → network → inner file). Impact analysis walks them **backwards, which is why the node nearest FB::Auto_mode is depth 1, not depth 4.

Above, in table form:

Depth	Through	Hit
1	containment	its source file
2	containment	the network it sits in (`Main::N1`)
3	containment	`OB1::Main`
4	containment	the main program's source file

These are two different questions, and conflating them is the fastest way to a wrong edit plan: the first says who is affected (callers, instance DBs, tag readers), the second says where it is nested (file → network → block → file). Keep them as two probes.

The most useful output is the list of things that don't exist

Eight references in this project point at objects the project does not define. The graph does not invent edges for them; it puts them in a table:

Status	Reference (written)	File	Line
pending	`IEC_Timer_0_DB_3`	`blocks/Auto_mode.xml`	332
pending	`IEC_Timer_0_DB_4`	`blocks/Auto_mode.xml`	337
pending	`IEC_Timer_0_DB_1`	`blocks/Auto_mode.xml`	483
pending	`IEC_Timer_0_DB_2`	`blocks/Auto_mode.xml`	488
external	`IEC_Timer_0_DB`	`blocks/Auto_mode.xml`	493
pending	`IEC_Timer_0_DB_3`	`blocks/Manu_mode.xml`	232
pending	`IEC_Timer_0_DB_4`	`blocks/Manu_mode.xml`	237
pending	`IEC_Timer_0_DB_2`	`blocks/Manu_mode.xml`	323

Cross-check: all eight are timer coils writing an instance — and both of these FBs have empty interfaces, and no global DB with those names exists. So this is not a parser miss. The blocks reference timer instance DB names that were never created in this project. A search finds the name; only a project-wide graph can tell you the name resolves to nothing.

Then the compile: No block was compiled. All blocks are up-to-date.

Read that sentence carefully before you put it in a report. It does not mean "the program is fine." It means "nothing needed compiling." A green compile is evidence about the compiler's queue, not about the program — and it is exactly how a dangling timer instance survives to commissioning.

The last step of the probe is the one only a human can do: classify each row as truly missing (add the object), external library (this project cannot define it; import something), or to be added later. The agent assembles the evidence; the judgment stays with the engineer who owns the machine.

What this cannot do

It reports what is, never what should be. An empty FB interface and two empty OB networks are facts; whether that is intentional design or a half-finished migration is a conversation with whoever built it.
It knows nothing about wiring, channels, or hardware. A tag addressed to %I29.4 is a string in a table until someone checks the terminal strip.
It does not replace a compile, a simulation, or a safety review. Those prove different things, and one never substitutes for another.
Unresolved ≠ broken code. "Pending" often just means the object never entered this copy of the project.

Do it on your own project in 30 minutes

Pick one project you inherited, not one you wrote. The point is to be surprised.
Build the graph, then immediately confirm the three checks (project name, build time, current-project origin). Write the build time into your notes — you will need it to know when the graph went stale.
Inventory probe. Reconcile against the TIA project tree by hand, once. If they disagree, stop; the graph is not trustworthy yet.
Pick one tag that matters — an output enable, an interlock, a handshake bit — and ask probe 4. Read the four (or forty) rows.
Sample two or three line numbers back into the XML or the TIA editor. Verify. This is the step everyone skips and the only one that calibrates trust.
Ask probe 5 twice: default relations, then with containment.
Ask probe 6, then classify every row yourself. Put the classification in the report, not in your head.

Expect the surprises to come from steps 4 and 6. Impact analysis on a block you "know" is where the containment layers show you the file you forgot, and the tag probes routinely find a writer in a block nobody wanted to touch.

Our take: project context is a data structure, not a longer prompt

The industry conversation about AI and PLC programming is mostly about generation — better SCL, better ladder, better conversions. That is the part that got solved first, because it only needs the spec.

The part that did not get solved is context, and prompt engineering cannot fix it, for a structural reason: a graph does not fit in a sequence. You can always paste more text, but pasting more text makes the coupling you need less visible, not more, because the relationships are spread across the very boundaries you are introducing.

Three things are worth taking from this even if you never build a graph:

Ask for provenance on every claim. "Parsed from an operand, line 217" versus "the block seems to use this tag" — one is evidence, one is a sentence. AI-assisted engineering fails quietly when the two are formatted the same way.
Proofread for truncation, not for tone. Long outputs from agents are persuasive at the paragraph level and unreliable at the inventory level. The question "did you see all of it?" should be muscle memory.
Treat absence as a finding. The eight dangling timer references are worth more than the 87 read edges, because a compile will never tell you about them and a human search will only confirm the name appears somewhere. Missing relations are only visible against a complete model of the project.

The lesson this came from is Lesson 6 of PLC AI in Practice — a free, text-based course (no video) that walks the same project through six probes with copy-paste prompts, ~30 minutes. The tool behind it is TiaLink, an MCP gateway that connects TIA Portal to an agent and runs locally, so project data stays in the plant.

If you'd rather start from the human problem than the tooling:

Taking over a legacy PLC program: a 4-step forensics routine (in Chinese) — what to do in the first 48 hours, before any analysis;
AI PLC programming: 7 hands-on lessons, each with a verifiable gate (in Chinese) — how this lesson fits the series;
Write protection in TIA Openness MCP tools (in Chinese) — why "read-only" has to be designed, not promised.

Disclosure: every measured number above — 227 nodes, 517 edges (220/2/2/87/52/154), 8 unresolved references, 1.2 s build, lines 152–262, the `IEC_Timer_0_DB` rows — comes from the course's own published run on 2026-10-27 (TIA Portal V19, TiaLink 1.4.0.0). I did not re-run the measurement independently for this post. Prompt examples were written in Chinese in the lesson and are translated here.*

Why AI Writes SCL But Rarely Ladder Logic: Text Is Cheap, Diagrams Need an IR

tia-forge — Wed, 04 Nov 2026 08:45:22 +0000

Ask an AI assistant for a PLC program that runs a conveyor — start button, stop button, e-stop, overload, contactor feedback, and a fault that latches unless you reset it.

You get SCL. Or ST. It looks plausible: a TON, an SR, a few IFs, sensible variable names.

Now ask for the same thing as a ladder diagram. You get an ASCII sketch, or a sentence telling you to put Start in parallel with Run and then in series with the NC contact of Stop.

This is not laziness. Text languages and graphical languages sit at different costs for a token-predicting model, and ladder logic is on the expensive side of that gap.

The gap is three layers, not a matter of drawing skill

Layer	SCL / ST	Ladder (LD)
Model output	The token sequence is the source file	Must be a graph: networks, series/parallel, branches, joins, element UIds
Intermediate representation	None needed	Required. Something has to record the topology before anything can be generated
Generation	Write to disk, compile, fix a line, retry	A deterministic generator assigns UIds and wires and emits strict SimaticML XML
Gate	Compile errors are still fixable	One validation issue and no XML is produced at all

A model emits tokens. SCL is tokens. The path from "model output" to "compilable source" is essentially zero-length, and when it fails you get a line number.

Ladder logic isn't text. What a rung actually encodes is topology: which contacts are in parallel, where the branch rejoins, which network a timer belongs to, which element feeds which. Natural language can't carry that, so an AI that "writes ladder" has to first write down the diagram as data.

That's the whole trick, and it's why so few tools do it: you don't ask the model to draw the diagram, you ask it to emit the diagram as a data structure, and a deterministic program does the drawing.

Somebody has to define a ladder IR and write a generator that turns it into SimaticML. SCL reuses a compiler that already exists. Ladder doesn't have that path for free.

What the pipeline looks like when it exists

IR — the ladder document is JSON: networks, elements, operands, connections.
Validation gate — before generation, the document is checked layer by layer: document shape, block interface, networks and parallel branches, operands, block calls. One issue and no XML is emitted, so you never hand TIA Portal a block that cannot be imported.
Deterministic generation — the same document always produces byte-identical SimaticML; UIds and wire connections are assigned by the generator, output targeting V19 <SW.Blocks.FC|FB|OB>.
Into the project — TiaLink imports the XML into the TIA Portal project you have open, compiles the whole software, and reads back objects and call relationships. Same-named objects are not overwritten by default, and the project is not saved automatically.

The last two points matter more than they look: "generated" and "imported" are not the same as "the application compiles". The validation-and-generation half is LadDoc Cloud; the import-and-compile half is TiaLink.

A real run: one message in, four objects out, whole-software compile 0 errors / 0 warnings

Environment: TIA Portal V19, S7-1500 (CPU 1516-3 PN/DP), gateway on the same machine, empty project.

One message, and no follow-up message after it:

We have a conveyor that has to run on a PLC. On the field side there is a start button, a stop button, an e-stop, an overload relay, a contactor feedback signal, and a reset button; on the output side the motor contactor plus two fault indicators.

Press start: the motor runs and stays running. Press stop, trip the e-stop, or trip the overload: the motor stops.

If the motor is running and no contactor feedback arrives within 2 seconds, raise a feedback fault, stop the motor, and latch it. Once the protection has recovered, the reset button clears the fault.

The main program has to call it every scan cycle. The e-stop and the safety circuit are handled by hardware; the program only does interlocking and annunciation.

Nothing was specified about block decomposition, block numbers, DB versus tags, or how the instance DB should be created. That was the agent's call; the operator's job is to state the requirement and verify the result.

What it delivered:

Object	Type	Number	Purpose
`DB_Conveyor`	global DB	DB10	Field signals: 6 inputs + 3 outputs
`ConveyorControl`	FB	FB1000	Control logic, 4 networks
`ConveyorControl_DB`	instance DB	DB1	The FB instance: timer and latch state
`Main`	OB	OB1	Calls the FB every scan cycle

Miss any one of the four and it isn't an application: without the OB call the logic never runs, without the instance DB the call doesn't even compile.

Network 1 — run seal-in. Start in parallel with Run for self-holding, then in series with four NC contacts (Stop, EStop, Overload, Fault), driving the Run coil.

Network 2 — feedback timer. While Run is true, start a TON with PT bound to a constant DELAY (2 s).

Network 3 — feedback fault. RunTimer.Q reached while RunFeedback is still FALSE sets RunFeedbackFault.

Network 4 — fault latch. Overload, RunFeedbackFault and Fault in parallel, self-holding, cleared through the NC contact of Reset.

The timer is a multi-instance inside the FB (RunTimer declared in Static), so its state lives in the instance DB. That's part of "the application runs", not decoration.

The first whole-software compile failed:

Compiling: Main (OB1)  Network 1: Missing instance DB.

The OB called the FB, but the FB's instance DB did not exist yet. After creating ConveyorControl_DB, re-importing and recompiling:

Compiling: Main (OB1): Block was successfully compiled.
DB_Conveyor (DB10): Block was successfully compiled.
ConveyorControl (FB1000): Block was successfully compiled.
ConveyorControl_DB (DB1): Block was successfully compiled.
Compiling finished (errors: 0; warnings: 0)

That's the difference between "a block" and "an application": a legal block doesn't mean the application runs.

Two more failures, from the same class of block

A counter without a data type. TIA's import reported CTU 缺少 value_type ("missing value_type"). Fix: have the generator declare the counter's data type, regenerate, re-import.

A temp variable with an initial value. Import reported Scratch: The Openness import failed: 该值无法更改。 ("this value cannot be changed"). Temp variables can't carry initial values; remove it and regenerate.

All three failures point at the same division of labour:

The agent's self-check owns semantics; TIA's import and compile own TIA's rules, and those are stricter.

"Validation passed" does not mean "TIA accepts it". Paste the raw error text back to the agent, let it fix against TIA's rules and regenerate. Don't hand-edit the generated file, and don't argue with the validator. Three rounds max; if it still fails, re-read the requirement.

Boundaries worth stating before anyone copies this

Compile 0/0 does not mean the behaviour is correct. Compiling only proves the block fits a CPU. A TON written where a TP belonged also compiles 0 errors / 0 warnings and no motor ever starts. Verify behaviour separately (simulation, or a real machine).
Outputs need mapping to your hardware. In the reference application many signals live in %M bits; map them to %Q before wiring anything.
Safety does not go to an AI. E-stop, safety gates, hardware interlocking belong to functional safety. The program only interlocks and annunciates; the final implementation must be reviewed by a person.
There are environment prerequisites. The gateway runs on the same machine as TIA Portal and currently targets V19. Without TIA Portal installed you can read, but not import.

Reproducing it

Two MCP servers, configured once:

{
  "mcpServers": {
    "tialink": {
      "type": "http",
      "url": "http://localhost:8080/mcp",
      "headers": { "Authorization": "Bearer <your TiaLink API token>" }
    },
    "lad": {
      "type": "http",
      "url": "https://tia.hubwiz.com/lad/mcp",
      "headers": { "Authorization": "Bearer <your LadDoc API key>" }
    }
  }
}

http://localhost:8080/mcp is the on-machine gateway — TiaLink, use whatever address your install listens on; https://tia.hubwiz.com/lad/mcp is the hosted ladder service, LadDoc Cloud. Any Streamable HTTP MCP client works — Claude Code, Cursor, VS Code.

Billing: handshake requests and lad_version are free; each validate/generate call consumes one credit. New accounts get a free allowance, then credits are bought in packs — no subscription.

Keep the keys out of repositories, screenshots and tickets.

How to tell whether "AI generates ladder logic" is real

Don't ask whether it can generate ladder. Ask for three numbers:

Are all the objects there? Global DB / FB / instance DB / OB — all four, or just a block?
Does the main program call it every cycle? Or was a lone FB handed over with no OB call?
What did the whole software compile report? Not "the block compiled" — the whole software, plus a read-back of the object list and call relationships that matches what the agent claims.

If it can produce those three, "it generates ladder" is a fact. If it can only produce a diagram that looks like ladder, it's a picture.

Disclosure: LadDoc Cloud and TiaLink are our products. The error messages, the compile output and the four networks above come from a single real run (TIA Portal V19, S7-1500); one run does not generalise to every project.

Earlier in this series: 60 ladder exercises you can import into TIA Portal, 113 ladder instructions, one page each, three kinds of LAD→SCL tooling.

The full walkthrough — signal table, workflow, network-by-network commentary, verification checklist — is lesson 3 of PLC AI in Practice.

Your Product Is Copyable. Your Distribution Isn't: A 24-Channel Map for Solo Builders

tia-forge — Mon, 02 Nov 2026 19:23:21 +0000

The uncomfortable fact first. A competitor with an agent can now rebuild most of your feature set faster than you shipped it. What they can't rebuild is the list of people who chose to follow you, opted into your emails, or bookmarked the page that answers their question.

That's the whole argument for treating distribution as the product. Below is the map I use: 24 channels, four funnel stages, four ways to acquire any one of them — plus the part most of these lists skip, which is that a solo builder can only run about ten of the 24.

Attribution. This is a rework of Shann³'s X longread How to Build Distribution When Anyone Can Clone Your Product (2026-11-02). The 24-channel matrix and the acquisition due-diligence questions are his; the solo-operator regrouping, the three tests, and the boundaries are mine. Case numbers below are his, quoted from primary posts; I did not re-audit them.

1. What counts as a channel

A channel is a repeatable route to people who could buy from you: a ranking page, a newsletter, a creator partnership, a listing in an app store.

"Repeatable" is the load-bearing word. One viral post is not a channel. A page that brings search traffic every month is.

Three things make a channel hard to copy with code:

people who chose to follow you, and would notice if you stopped posting
subscribers who actively opted in (and whose consent you can prove)
pages that rank and get cited by AI assistants
partners who stake their reputation on you
customers who answer "who else does this?" with your name

None of that lives in a repo. A competitor can fork your code; they can't fork three thousand people choosing not to unsubscribe.

2. The map: 24 channels × 4 funnel stages

The channels are grouped by where the customer is, not by which platform is hot this quarter — the first is structure, the second expires.

#	Channel	Funnel stage	How to get it
1	Founder & team audiences	Before they know they need you	build, partner
2	YouTube channels	Before they know they need you	build, pay, acquire
3	Newsletters & email lists	Before they know they need you	build, pay, acquire
4	Creators & industry experts	Before they know they need you	partner, pay
5	Press, podcasts, publications	Before they know they need you	build, partner, pay, acquire
6	Events, webinars, workshops	Before they know they need you	build, partner, pay
7	Free tools, templates, open source	Before they know they need you	build, acquire
8	Social, video & offline ads	Before they know they need you	pay
9	Direct outreach & sales	Before they know they need you	build
10	Education & certification	Before they know they need you	build, partner, pay
11	Your website & search visibility	While they compare options	build, acquire
12	Review & comparison sites	While they compare options	build, pay
13	Marketplaces & app stores	While they compare options	build
14	Launch & discovery platforms	While they compare options	build, pay, acquire
15	Search & AI assistant ads	While they compare options	pay
16	Integrations & technology partners	Through tools and people they trust	build, partner
17	AI agent surfaces (MCP, connectors)	Through tools and people they trust	build, partner
18	Agencies, consultants, resellers	Through tools and people they trust	partner
19	Affiliates & referral partners	Through tools and people they trust	partner
20	Communities	Through tools and people they trust	build, partner, acquire
21	Businesses with an existing customer base	Through tools and people they trust	acquire
22	Bundles, pre-installs, default placement	Through tools and people they trust	partner, pay
23	Distribution built into the product	After they buy	build
24	Customer referrals & word of mouth	After they buy	build

Use it as a checklist, not a to-do list. The useful question is never "which channel should I do" but "which of the four stages do I have zero presence in".

3. Four ways to get any channel

Same channel, four acquisition modes, and each one leaves you with something different.

	Time to results	What you keep	Failure mode
Build it	Slowest	Audience, content, data — all yours	The person who makes it leaves, the channel dies
Partner	Fast-ish	One-off reach, no asset	You mistake your partner's audience for yours
Pay	Immediate	Nothing	Counting CAC, ignoring retention
Acquire	Immediate	Existing audience and content	The audience leaves with the previous owner

Two examples from the source that make the modes concrete:

Build + audience → acquisition. Maor Shlomo built Base44 alone and documented it in public on LinkedIn and X; Wix bought it for \$80M in cash roughly six months after launch.
Pay → placement. Airtel handed 12 months of Perplexity Pro to 360 million customers in July 2025; Perplexity also ships pre-installed on Galaxy S26.

The acquisition column is where people lose money, so the source's due-diligence list is worth quoting in full. Before you treat a purchase as a channel, check:

Do the readers, viewers or members actually match your buyer?
What leaves with the seller? An audience that came for one writer can follow that writer out.
Where does the traffic come from? A search-dependent site can lose it in one update.
Subscriber consent and data-transfer rules — an acquired list is not a licence to email.
Who stays after the sale? Team, contributors, community moderators.
How do you introduce your product? A publication that starts promoting its new owner loses the trust that made it worth buying.

That last one explains why "buy distribution" so often destroys the thing it bought. Trust doesn't transfer with the asset.

4. The part the list skips: a solo builder can run ten of these

Most 24-channel posts are written by agencies for companies with a budget and a team. Eight of the 24 basically require money (ads, sponsorships, bundles, acquisitions), and seven more require someone to negotiate with. Recut by "can one person actually keep this running":

Group	Channels	Why
Run alone	1 founder/team audience · 7 free tools & OSS · 9 outreach · 11 site & search · 13 marketplaces · 14 launch platforms · 17 agent surfaces · 20 communities · 23 in-product distribution · 24 referrals	Build once, they keep feeding traffic
Needs a counterpart	4 creators · 5 press & podcasts · 6 events · 10 education · 16 integrations · 18 agencies · 19 affiliates	The key action is a conversation, not a draft
Not yet	8 ads · 12 paid review placements · 15 search ads · 21 acquiring a business · 22 bundles · the acquire paths of 2/3/5	Either ongoing cash or diligence capacity

Then three tests, in this order:

Can you measure it? A channel you can't measure is hard to keep funding while you wait.
Does it match how your customers buy? Self-serve signups need you to exist while they compare; demo-led sales need outreach, agencies and events.
Will you see a first paying customer inside 90 days? If not, park it — regardless of how good the channel looks on paper.

Fail any one and the channel waits. That is the whole prioritisation method; there is no fourth test.

One disagreement with the source, for the record: it recommends starting with "one channel you build, one you partner with or pay for." For a solo builder I'd replace pay with partner. Paid reach consumes cash continuously; partnering consumes communication, and you're already paying that cost.

5. Two channels, two stages — then measure

Pick two channels at different funnel stages. Two channels in the same stage means you cover the same moment twice and stay invisible everywhere else. Two different stages means one catches people who don't know they have the problem, and one catches people choosing between options.

Track four numbers per channel, and nothing else:

how many people it reached
how many of those became customers
what it cost, including your own hours
whether those customers stay, and what they spend over time

Two rules that save months:

Keep engagement separate from sales. A post can pull huge engagement and zero customers; mixing them produces a channel that looks like it works and doesn't.
Ask new customers how they found you. Podcasts, word of mouth and creator posts mostly never show up in click tracking.

For affiliates and referrals, check that the referred customers are good customers before you raise the payout.

6. Where the argument breaks

Four limits, because a 24-cell table invites false confidence:

Specific numbers here are second-hand. \$80M, 360M, 77.5% of Klaviyo's ARR, Dropbox's +60% — I'm repeating figures the source attributes to primary posts. Treat them as claims, not audit results.
Channels are not uncopyable, only harder to copy. Platform rules change overnight: a search update, a store delisting, a feed algorithm. That's exactly why the three tests reward measurability and a 90-day horizon over channel count.
Scale isn't transferable. Base44, Supabase and Lovable all had someone pushing full-time. Doing the same actions alone gets you the actions, not the numbers.
The framework is not new. Grouping channels by funnel stage is a re-skin of the channel list in Traction (Weinberg & Mares). What's new here is the fourth dimension — acquisition mode — and the admission that most of it isn't for you.

The one action worth taking today

List every channel you currently have traffic from, tag each with one of four stages, and find the stage with nothing in it. That empty stage is where a competitor is winning customers you never get to meet. Then pick one channel from the "run alone" group, give it a 90-day test, and stop adding channels until one produces a paying customer.

Originally written in Chinese at hubwiz.com (in Chinese). Based on Shann³'s article. Cover: aerial view of the Bremerhaven container terminal, Carsten Steger, CC BY-SA 4.0, via Wikimedia Commons.

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.