Turn control requirements into reviewable, verifiable PLC programs.

Rule layer.We once taught the fail-safe contact direction backwards — instructing the system to read a normally-closed stop button with an inverted contact (ANI), when a normally-closed contact is ON at rest and the program should use a normally-open contact (AND). This error existed simultaneously in the prompts, the example library, the checker, and four technical articles.The model isn't dumb — it writes exactly what we taught it.We've also fixed broken scoring metrics: a speculative "possibly missing latch" warning was being treated as a hard deduction, failing even programs that scored perfectly on behavior tests.When a speculative rule conflicts with a test that actually ran on a virtual PLC, the rule loses.

Compile layer.The Siemens code kept failing to compile, and the real cause wasn't the model writing nonsense — it was that the variable mapping table we gave it usedNested comment— The IEC compiler doesn't support nested comments; it ends the comment early at the first inner closing symbol and then reports the subsequent declarations as code errors. Once this was fixed,All brands benefit. We've also added brand cross-contamination detection for structured text (SCL): previously we only scanned the ladder column, but for Siemens the actual deliverable is SCL, meaning it went completely unchecked; now we scan SCL line by line too, and if instructions from another brand are detected, before shippingAutomatically converted back to correct brand syntax.

Address layer.Omron's native address CIO 100.00 (an output-region address) was at one point written as A100.00 in the shipped ladder diagram — but A is the auxiliary relay region, which iscompletely different memory from the CIO output. The trickiest part: the address-consistency check actually "passed," because the ladder diagram and the I/O table both consistently used the same wrong token —consistent, but consistently wrong. The fix: address legalization always follows each brand's region semantics (CIO/W/H/A each stay in their own region), and never blindly prepends a prefix to a leading digit.

The rules, example library, checker, scoring metrics, compiler, and address legalization were all fixed, and the benchmark was rerun.Below are the real, corrected numbers. Full details →

All four items above areTargeting "the ST deliverable"is measured on the finished ST itself: the ST is fed to a compiler, its instructions are scanned against a whitelist, and its structure is checked by rules. The denominator is the 20 cases of the latest round — one case equals 5 percentage points: compiles 18/20, brand-clean 19/20, structure 18/20, all three static checks 17/20.

⚠ How strong the evidence behind these four numbers is — we'll say it ourselves first: We can say why each case lost points (2 cases failed to compile, one of them Siemens SCL; 1 case mixed brand instructions — the same Siemens case; structure losses are mechanical issues such as duplicate coils), butthe per-case raw table has not been published— which means you cannot currently recompute 18/19/18/17 for yourself. Being able to explain the losses is not the same as having a table you can recompute.We do not conflate the two.

Why we publish a single round rather than a range: We publish the single-point figures of the latest round, and state on the same page which round it is together with the figures of earlier rounds; we do not blend different rounds into a range, and we do not pick the prettiest round. Above isthe latest round; the four earlier rounds (85/95/50/40, 95/100/70/65, the four-round range, 85/100/80/65) are all kept in the full benchmark write-up , each labelled with its round. Old rounds are never deleted — deleting the record of your own bad measurements is what pretending nothing happened looks like.

It doesn't measure cross-format consistency. On July 18, 2026, an outside PLC engineer running black-box tests found that for the same problem, the three output columns — ladder diagram, mnemonic, and ST — could disagree with each other: after the core assembled the safety circuit and overwrote the ST, the ladder diagram was still the model's original version. Since the compiler only looks at ST and the behavior tests only run ST, our entire verification pipeline never caught this. He also found Mitsubishi-style addresses (X000/Y000) in the I/O table of a Siemens problem, because our brand check at the time only scanned the code, not the I/O table.

We first added deterministic checks for both blind spots (auditing for out-of-scope addresses, checking I/O table address formatting, detecting duplicate ST assignments, and comparing addresses between the ladder diagram and ST); anything detected is flagged on screen. We later fixed the root cause: standard control blocks use the V2 pipeline by default, rendering the ladder diagram, mnemonic, and ST from one intermediate representation. Stateless Boolean logic also receives an exhaustive equivalence check; artifacts containing TON/CNT still require validation in the target PLC IDE and under field conditions by an engineer. The final ST carries a fingerprint (stHash) so you can confirm that "the ST shown on screen" is exactly "the one the compiler compiled and the virtual PLC ran." The brand check now also scans the I/O table column by column, and address legalization is handled by a single shared rule, so a Siemens problem will no longer have Mitsubishi-style addresses (X000/Y000) mixed in. The only exception: if you uncheck V2 and revert to the legacy V1 pipeline, the three columns can still diverge; and regardless of the path, any AI output must be reviewed by a qualified engineer before going live.

We compile the program into an executable and actually run it on a virtual PLC. When a test fails, the AI diagnoses and fixes it itself, then reruns verification.

Result: it judged that "the program really was wrong"10 times, the proposed fix was syntactically correct, compiled fine, and didn't touch the safety logic — but when we reran the tests,7 times "no improvement at all".

AI review helps surface suspicious points, but its findings must be corrected against the rule layer, composer facts and test results — they can't be treated as a delivery verdict, and it must never be allowed to auto-fix.

This isn't a prompting problem, and running more rounds won't fix it — we doubled its output limit and tried again,No help at all. That's the capability limit of today's generation of models.

So "must be reviewed by a qualified engineer" isn't a line we wrote to cover ourselves. It's a fact we measured ourselves.

The most common one used to be the contact direction of safety signals.The AI would write "overload protection, normally-closed wiring" in the I/O table, but then read it with an inverted contact in the program — the result: if the overload wire breaks, you'd never detect the overload.

For this one, we now apply a deterministic correction — and flag it. When the I/O table already declares a point as a stop/overload/E-stop type wired normally-closed, reading it with a normally-open contact is the only fail-safe answer — this isn't guessing the physical wiring, it's applying the convention you yourself declared. So we automatically change inverted contacts (ANI/ORI) back to normally-open (AND/OR),But every one is flagged with a ⚠ mark on that line, asking you to verify the physical wiring — we never change it silently. We still won't guess at things that genuinely depend on your field conditions:Whether to add an interlock, whether latching should be done in software, how the E-stop circuit should be wired— those, we only flag; the decision is yours.

Mechanical issues (double coils, duplicate timer numbers, instructions borrowed from the wrong brand) are corrected automatically too, and re-compiled and re-verified before being delivered to you.A safety issue that gets auto-fixed incorrectly is more dangerous than one that's simply flagged — so we only step in when the rule has a single unambiguous answer, and whenever we do, we tell you loudly.

Being clear about what we are, and what we're not: The model that generates the code isn't one we trained ourselves. What we built is the layer that constrains it, verifies it, and honestly tells you where not to trust it — a brand-syntax knowledge base, field rules, a four-layer verification pipeline, and this benchmark suite.
The exact same model, once wrapped with our core,Full behavioral accuracy (the strictest metric: actually running the program to test whether its behavior is correct) rose from 40% to 55–65%, brand-instruction mixing dropped to 0%. (This is a different tier of metric from the "all three static checks pass: 85%" figure above: 85% only looks at compilation/brand/structure, while 55–65% requires the behavior to be correct too.) Those twenty-some percentage points are EOT's technical value-add — and it's measurable, not just a claim.

Finally, one thing that has to be said: passing the checks does not mean the program is correct. Any PLC program produced by AI must be reviewed by a qualified engineer and verified on real hardware before going live. Safety functions (E-stop, interlocks) must be implemented with hardware safety circuits, not software logic alone. This isn't a disclaimer — it's a rule of this trade.

We measured this ourselves, and we'll say it up front: AI review does help surface suspicious points, but findings themselves can be false positives and must be corrected against the rule layer and test results — and it certainly can't reliably fix the program. (See the benchmark above: it correctly identified a real bug 10 times, and the proposed fix compiled and didn't touch the safety logic — but on 7 of those, rerunning the tests showed "no improvement at all.")

So we don't pretend it's "press a button and get a finished deliverable."What the AI gives you is a usable first draft, not a finished product. What actually turns this into a program you can run on real equipment is you and the AI refining it round by round in conversation — because there's one crucial thing only you know: your actual field wiring.

This is our approach: not "AI does it all in one shot," but "working with you, converging round by round." For simple logic, a few rounds of conversation gets you to something you can run. For a complex whole machine or line — panel design, physical safety-circuit implementation, on-site commissioning, warranty — you'll want a qualified system integrator on the ground; that part is beyond what this tool covers. AI gets you there faster; a qualified engineer makes sure it actually runs on real equipment.

It is not a fixed number every time, and it is not priced only by line count. Formal delivery is priced bystandard control-block complexity, behaviour verification vectors, delivery-document completeness, program scale, and verification levelA simple motor start/stop block and a full SBR / RO / plant-wide environmental-control system require very different engineering evidence, so they should not cost the same.
Before generation, the estimated credit charge is shown; after completion, the page lists quoteFinalReconciliation, pricingBasis / fullPriceBasis, verification level, actual credits charged, and output line count, so you can see why the estimate matched the final charge or why a discount was applied.

Before generating the program, an I/O table is produced first for you to confirm. The field sequence is control logic → IO planning → wiring → programming; panels are wired from the IO table. If IO planning needs a precharge, it is the front part of the same formal delivery cost, not a duplicate charge; it is credited back during formal generation and shown clearly in the billing details. The extra confirmation step prevents wrong field-point guesses; it is not an upsell.

Free membership: 15 credits/month · No credit card required · No credits charged if nothing is delivered or the job is blocked · When a successful delivery is not fully verified or requires engineering review, it is discounted and the reason is shown; internal reruns for our own correctionsNo charge to you— that's our quality cost, not yours