land route resolves a duplicated pad key (J1.MP) to the wrong pad; route keeps custom-pad nets as unconnected clusters after their copper lands

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

Closed general

John Lauer · 21d ago ·closed by John Lauer

adom-aiflow 0.2.17, KiCad Bridge 1.0.58, KiCad 10.0.3 on arav-rog. Run: actuator-cell/output-board/aiflow-run on ut-austin-ece-364d/uta-bldc-dyno-showroom (a capencoder two-ring sensor, 2026-10-24).

1. A pad key that names two pads lands on the wrong one. The router's plan ended a GND path at "J1.MP"; a Hirose FH12-20S footprint has two pads numbered MP (93.35, 189.3) and (106.65, 189.3). gate resolved it to the near pad and passed. land route sent J1.MP to kicad_route_net, which took the first pad, so the candidate ran 9.95 mm the other way across an OUTA1 track and came back drc_rejected at trace 47 of 54 (no copper changed). Workaround: the plan point replaced by the pad's coordinates, then land route --from 47. Expected: the router writes coordinates (or an unambiguous pad id) for a pad number that occurs more than once, and gate and land resolve keys the same way.

2. route reports receiver nets unroutable after their copper is landed. Four receiver nets (RXA1 RXB1 RXA2 RXB2), each a large custom B.Cu pad (the receiver rings, (options (anchor circle)), gr_poly primitives) with a feeder segment, plus three SMD pads. Before any routing: "4 clusters, 0 routes, 3 failed ... no path" for each, every pass. After the AI landed those four nets through kicad_route_net and the board was adopted (native DRC and gate: those nets connected, 0 unconnected), route still reported the same 4 clusters and 12 failed connections. Its plan for every other net was complete and gated clean, so the run went on. It looks like the custom pads' copper is not joined with the existing tracks when clusters are built. Expected: existing copper merges a custom pad's cluster as it does for ordinary pads.

1 Reply

John Lauer · 20d ago

Fixed in adom-aiflow 0.2.19, both.

J1.MP on the wrong pad. Keys resolved through a key-to-pad map, so the gate got the last pad with that key (being the near one was a coincidence) and the bridge got the first. Now a step shared by the gate and land route replaces any ambiguous key with the coordinates of the pad nearest the path's neighbouring point, preferring pads on the entry's net, and prints a note. The router also writes such pads as coordinates.
Ring nets stuck as unconnected. The cause was not the custom pad polygons, which were read correctly. It was the same duplicate-key problem: each electrode footprint E1..E4 has two pads numbered "9", and the router stored pad cells by key, so the two ring pads collapsed into one cluster. That's why it said 4 clusters for 5 pads. Pad cells are now stored per pad. A track crossing a pad's polygon now counts, not just one ending on it, and overlapping same-net pads of one footprint count as one piece of copper. On your saved board (read only) all four RX nets now show 5 clusters each and count as already joined.

A regular board (the buck molecule) routes to an identical plan on 0.2.18 and 0.2.19.

Upgrade: adom-wiki pkg install adom/adom-aiflow, then adom-aiflow --version says 0.2.19.

John Lauer closed this · 20d ago