Per-connection trace widths are ignored: 1.0 mm motor traces emit as 0.15 mm

[seveibar]

Bug

The autorouter silently emits default-width PCB traces even when each SimpleRouteConnection carries a larger width and nominalTraceWidth. This is visible on an RP2040 + DRV8833 motor-controller board, where the high-current outputs become 0.15 mm traces.

Public reproduction data and PCB snapshot: https://gist.github.com/seveibar/67a25d17202a343a1c8f3d4c47cd06d2

Exact mismatch

The four motor-output source traces specify min_trace_thickness: 1. The generated SimpleRouteJson correctly preserves this on connections source_trace_122 through source_trace_125:

{
  "name": "source_trace_122",
  "source_trace_id": "source_trace_122",
  "nominalTraceWidth": 1,
  "width": 1
}

All four corresponding output pcb_trace routes contain only:

"wire_widths": [0.15]

The same issue occurs selectively on the power nets:

• VM terminal branch requests 0.8 mm but outputs 0.15 mm.
• Some merged ground branches request 0.8 mm but output 0.10-0.15 mm.
• Other nearby VM/ground branches do retain 0.8 mm, so the loss appears branch/merge dependent rather than a global parsing failure.

The public gist JSON contains the complete unrouted simple_route_json, source constraints, and observed PCB widths.

Expected behavior

Every wire segment for a connection with width: 1 / nominalTraceWidth: 1 should remain 1.0 mm wide. A requested minimum must not silently fall back to the global 0.15 mm width. If the requested width cannot be routed, the route should fail or return an explicit width-degradation error instead.

Steps to reproduce

1. Download rp2040-trace-width-bug.json from the linked public gist.
2. Pass its simple_route_json field to the default local autorouting pipeline.
3. Inspect the output routes for source_trace_122, source_trace_123, source_trace_124, and source_trace_125.
4. Observe that each wire segment is 0.15 mm instead of the requested 1.0 mm.

Versions

• tscircuit@0.0.2116
• @tscircuit/core@0.0.1470
• @tscircuit/capacity-autorouter@0.0.696
• preset: auto_local
• effort: 10x

This looks like a regression or incomplete path following #66, since the connection-level width metadata reaches SimpleRouteJson correctly but is not consistently represented in the routed output.

[Hero988]

Reproduced on current main (1adc9ca / v0.0.705) with the gist's simple_route_json — the four motor connections request 1.0 mm and emit 0.1 mm (current minTraceWidth; 0.15 in the gist's capacity-autorouter 0.0.696 is the same fallback path). Three stacked causes:

1. Silent min-width fallback on an all-or-nothing width schedule (lib/solvers/TraceWidthSolver/TraceWidthSolver.ts). The width schedule is [nominal, (nominal+min)/2]; the cursor walk requires width/2 + obstacleMargin clearance at every point; on exhaustion it silently emits minTraceWidth. Instrumenting the clearance check shows each ~25 mm motor trace fails at a single pinch 0.7–4 mm from the destination pad (e.g. source_trace_124 @ 1.0 mm: clearance 0.5225 vs required 0.6 against a neighbouring not-same-net pad on 0.65 mm pitch), so the entire route collapses to minimum width instead of necking locally. The terminal-taper machinery (getTerminalPadWidthLimit / createTerminalTaperedRoute) doesn't rescue this: it only necks down to own-pad width, and returns undefined for 3 of the 4 motors because the diagonal exit tangent projects a pad-width limit wider than the trace. I prototyped a taper-aware clearance check and verified it changes nothing on this board — the pinches are mid-route against other nets, not at the terminal.

2. Merged nets collapse to one arbitrary width — this is the "branch/merge dependent" 0.8/0.25 behaviour. lib/solvers/NetToPointPairsSolver/mergeConnections.ts (~L128-135) takes the first-found nominalTraceWidth for the merged group (the comment says "Take the nominalTraceWidth from the first connection for now"), and the MST pair connections built in NetToPointPairsSolver.ts (~L181-188) and NetToPointPairsSolver2_OffBoardConnection.ts (~L172-180) drop nominalTraceWidth entirely. Width is later recovered only via a single __rootConnectionNames[0] per merged net, looked up against the pre-merge connection list. Concretely: group source_trace_47 (0.1) + source_trace_132 (0.25) + source_net_3 (0.25) → all 25 branch routes emitted at 0.1.

3. Reporting masks it — convertPipeline7HdRoutesToSimplifiedPcbTraces.ts (~L60-63) emits connection_name = __netConnectionName ?? __rootConnectionNames[0], so source_net_3's traces are attributed to source_trace_47 in the output.

Fix directions — happy to PR, but would like a maintainer steer first given the issue's "Expected behavior" offers two options:

• (2) is mechanical: plumb per-MST-edge width through mergeConnections / pair connections (point→width map) and pass the post-merge connection list to TraceWidthSolver. Fixes the 0.8/0.25 branch class; red→green testable (I have the serialized TraceWidthSolver stage input from this board for fast iteration).
• (1) needs a design call: variable-width emission (walk once, clamp width locally at pinches with taper transitions — per-point traceThickness support already exists in the route format) vs a loud width-degradation error replacing the silent fallback. Note that full 1.0 mm fidelity isn't reachable post-hoc where the HD router laid the path 0.52 mm from another net's via — that would need width-aware routing upstream.

If that split sounds right I'll start with (2).

[Hero988]

Opened #1736 for the D2 portion (merge-plumbing width loss) — red→green tests included; on the rp2040 repro it fixes the branch/merge-dependent 0.8/0.25 losses (24 routes corrected, zero decreases). The 1.0mm→0.1mm collapse on the pinched motor traces is D1 (the silent minTraceWidth fallback) and still needs a design call — happy to implement whichever direction you prefer (variable-width emission vs loud error).

[DPS0340]

Found a concrete root cause for at least part of this — opened #1773.

mergeConnections (lib/solvers/NetToPointPairsSolver/mergeConnections.ts) unions every SimpleRouteConnection that shares a point, but kept only the first nominalTraceWidth it encountered:

// Take the nominalTraceWidth from the first connection for now
if (nominalTraceWidth === undefined && conn.nominalTraceWidth !== undefined) {
  nominalTraceWidth = conn.nominalTraceWidth
}

Since these widths are minimum requirements, a 1 mm motor output merging with a thinner branch on the same net loses its requirement entirely whenever the thin branch is visited first.

That matches the detail in your report that the loss is branch/merge dependent rather than a global parsing failure — VM/ground branches that kept 0.8 mm were the ones whose wide connection happened to come first. It was connection order, not the value itself.

Demonstrated with a direct unit test on main:

merging keeps the widest requested nominalTraceWidth
  Expected: 1
  Received: 0.15

The PR takes the max across the merged group instead, so merging can never narrow a trace below what any member requested. Full suite: 411 pass / 13 fail vs 406 / 13 on unmodified main (same pre-existing timeout failures).

One caveat: this fixes width preservation through merging. If the gist data also shows loss further downstream (TraceWidthSolver, HD route conversion), that's a separate fix — happy to chase it if you'd like.