ERC coordinates appear scaled 100x relative to source mm; expose units diagnostics

Overview Files Skills Discover Packages Releases Dependencies Issues11 Breadcrumbs Pull Requests Activity

Open bug report

John Lauer · 1mo ago

KiCad 10.0.2 service ERC returns positions marked as millimetres that appear 100 times smaller than the uploaded source and its native SVG. This can mislead AI diagnosis, highlighting and cross-tool geometry checks.

Reproduction: service-kicad sch erc sensor-decoupling-r14-fixed.kicad_sch --format json. U1 is placed at source (at 80 86.59 0); the ERC footprint_link_issues item for that symbol reports {x:0.8,y:0.8659}. U1 pin 3 is at source-derived (52.06,67.54) mm and its ERC item reports (0.5206,0.6754). The native SVG visibly places the circuit in the expected sheet region. The input and original ERC JSON are attached; the circuit intentionally remains incomplete, so its ERC violations are expected and must not be hidden.

Please determine whether the scale discrepancy originates in upstream KiCad 10.0.2 or the service/CLI conversion, preserve the raw report, and expose structured units/version/provenance plus an actionable AI hint if the returned coordinates are unreliable. Do not silently rescale or mark ERC passed. An input-relative sanity check could flag this before an AI uses report coordinates to move or highlight a component.

Observed service version 1.1.0, git 08def5a76503bd78100febd697ad48cd5d61f022; upstream root cause is not yet established. Separate improvement: malformed schematic loads currently return only Failed to load schematic; native parser location/details where available would materially shorten diagnosis.

sensor-decoupling-r14-fixed.kicad_sch

schematic-r14-erc.json

1 Reply

John Lauer · 1mo ago

Root cause is upstream KiCad, not the service. In KiCad 10.0 eeschema/erc/erc_report.cpp, GetTextReport() builds UNITS_PROVIDER( schIUScale, ... ) but WriteJsonReport() builds UNITS_PROVIDER( pcbIUScale, ... ). Schematic IU is 1e4 per mm, PCB IU is 1e6 per mm, so every JSON pos is the true millimetre value divided by exactly 100. That matches your numbers (80 mm -> 0.8).

What PR 3 (merged, b2b9d53) does about it:

The CLI cross-checks ERC item positions against the symbols they name in the uploaded schematic. On your attachment 32 items land a median 3.81 mm from their symbols at 100x versus 117 mm at 1x, so it prints hint [ERC_COORDINATES_SCALED] with the factor and that evidence, above the findings. Nothing is rescaled and the raw report is preserved; --format native is byte-for-byte.
--format json adds adom_summary with kicad_version, coordinate_units, input sha256, service version + git sha, and erc_scale (status, factor, matched items, median distances). A report that checks out prints nothing; one that cannot be cross-checked says why.
Counts and exit code now come from the findings (see #3); the expected ERC errors on the incomplete circuit are not hidden.
"Failed to load": the CLI reads the file structurally before uploading and reports line/column of an unterminated list, paren balance, wrong file kind or legacy .sch under INPUT_UNLOADABLE (exit 1). The API's 400 carries the same diagnostics plus a hint. kicad-cli itself prints no parser location, so a file that parses but is still refused gets a hint saying the problem is semantic.

Still open: the API-side diagnostics need a deploy (GitHub main, which the prod watchdog tracks, is still at 08def5a7), and the upstream bug has not been filed on gitlab.com/kicad yet. Leaving this open until both are done.