Avoid overlaps from generated net-label traces - #727
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
29f62ed to
87ab200
Compare
87ab200 to
2930aa7
Compare
|
@imrishabh18 — #727 looks like it improved one board and regressed another. Reporting with numbers since the regression isn't visible from the snapshots it updated. Counting different-net trace crossings across all imported bug reports, immediately before and after #727: The change is on one board: Every other board is unchanged, and I found it because #718 (open, measurement-only) pins these counts per board, and it now fails on exactly this one. That PR is just a counter plus a table of current values — no behaviour change — and its whole purpose is to make this class of regression fail a named assertion instead of disappearing into a regenerated SVG. It would have caught this at review time. Reproduce: git checkout be20aa7
git checkout <718-branch> -- tests/fixtures/traceCrossings.ts
# then count getTraceCrossings() per board in tests/bug-reports/Not asking you to revert — one crossing traded for a fixed overlap may well be the right call, and you have context I don't. But if the trade was unintentional, |
tscircuit#727 (TraceOverlapShiftSolver) fixed the RP2040 USB-C overlap and moved bug-report-20260707T092615Z from 2 different-net crossings to 3. Measured either side of that merge: ca7e80c (before) TOTAL 40, this board 2 be20aa7 (tscircuit#727) TOTAL 41, this board 3 Pinned at the current value with a comment recording the change, and reported it on tscircuit#727 so the trade is visible rather than absorbed.
The collinear-overlap check rejected every candidate orientation for the RP2040 CC2 label, so no connector was generated at all — regressing tscircuit#727, which had just fixed that board by shifting the overlapping trace. Leaving a label unattached is worse than an overlap the cleanup passes can still shift, so the rejection is now a preference: try for an overlap-free orientation, and if none exists take the best available one. The fallback fires 28 times across the imported bug reports, so it is load bearing rather than defensive. repro-rp2040-usb-cc2-ground-overlap pass (was: cc2LabelConnector undefined) full suite 167 pass, 0 fail different-net crossings TOTAL 20
A crossings-only count is one-sided: two nets that cross can always be made to stop crossing by running them along each other instead, which reads as a single line and hides a connection. Counting only crossings scores that as an improvement. tscircuit#727 is the concrete case. On bug-report-20260707T092615Z it moved the board from 2 crossings / 1 overlap to 3 crossings / 0 overlaps, and both numbers involve the same pair of segments (C_SENSE.2-C1.2 and available-net-orientation-13-BAT_POS) — it separated two nets drawn on top of each other across a 0.141 span and left them crossing at a point. That is a trade in the right direction, but a crossings-only guard flags it as a regression. Pinning both quantities makes the trade visible instead of scoring it.
|
Correcting myself: I called this a regression above, and that was wrong. It is a trade, and it goes in the right direction. I had only been counting crossings. When I also counted different-net collinear overlaps — two nets drawn on top of each other along a shared span — the picture inverted: And on the one board that moved, it is the same pair of segments on both sides of the ledger: So #727 took two different nets that were being drawn as one line over a 0.141 span and separated them, leaving them crossing at a point instead. A crossing is visible and unambiguous; a collinear overlap looks like a single trace and hides that two nets are there. That is worth one crossing. The mistake is instructive, so I fixed it in the measurement rather than just retracting the comment. A crossings-only guard is gameable in exactly this direction: any crossing can be "removed" by making the two nets run along each other instead, and a one-sided counter scores that as an improvement. #718 now pins both quantities per board, so a change that trades one for the other shows up as a deliberate, visible trade instead of passing or failing by accident. Verified the new overlap counter actually detects the thing it claims to: checked out Sorry for the noise on a merged PR — the earlier comment made a claim my measurement did not support, and I would rather correct it in place than leave it standing. |
tscircuit#727 (TraceOverlapShiftSolver) fixed the RP2040 USB-C overlap and moved bug-report-20260707T092615Z from 2 different-net crossings to 3. Measured either side of that merge: ca7e80c (before) TOTAL 40, this board 2 be20aa7 (tscircuit#727) TOTAL 41, this board 3 Pinned at the current value with a comment recording the change, and reported it on tscircuit#727 so the trade is visible rather than absorbed.
A crossings-only count is one-sided: two nets that cross can always be made to stop crossing by running them along each other instead, which reads as a single line and hides a connection. Counting only crossings scores that as an improvement. tscircuit#727 is the concrete case. On bug-report-20260707T092615Z it moved the board from 2 crossings / 1 overlap to 3 crossings / 0 overlaps, and both numbers involve the same pair of segments (C_SENSE.2-C1.2 and available-net-orientation-13-BAT_POS) — it separated two nets drawn on top of each other across a 0.141 span and left them crossing at a point. That is a trade in the right direction, but a crossings-only guard flags it as a regression. Pinning both quantities makes the trade visible instead of scoring it.
|
Thank you for your contribution! 🎉 PR Rating: ⭐⭐ Track your contributions and see the leaderboard at: tscircuit Contribution Tracker |
4 participants
ISSUE
Summary
AvailableNetOrientationSolvercreates connector tracesavailable-net-orientation-*traces may moveRoot cause
The pipeline resolved cross-net trace overlaps before net-label orientation correction.
AvailableNetOrientationSolverthen added the CC2 connector later, so that generated connector never went through overlap resolution and landed directly on two GND traces.The long U-shaped trace highlighted in the repro is legitimate: it is
schematic_port_94-schematic_port_92, the GND connection from R9’s downward-facing bottom pin to R8’s downward-facing bottom pin. A straight segment would cross both resistor bodies, so the line solver routes below R9, along the component-clearance boundary, and back into R8 from below.The revised fix preserves that established GND route and shifts only the generated CC2 connector with endpoint-preserving terminal jogs.
Tests
No additional repro test is added by this branch; it modifies the merged #728 test and snapshot. Two existing snapshots containing the same generated-label overlap behavior are refreshed.
Related
Complements tscircuit/core#2878, which prevents different-net trace contacts from being rendered as electrical junctions.
Validation
bun test— 147 passed, 4 skippedbunx tsc --noEmitbun run format:check