Track & via cleanup option to join "near misses"

[PCB Wiz]

This bug report took a long and winding path. It might be better to start at the end, unless you want all the details....

======================================================
Original report follows:

Tested on : r7005 and all earlier builds, Win64

See attached images from test case, a picture is worth 1000 words.
This shows
a) approaching shortest trace to pass Connect Test
b) Leaving shortest trace to pass Connect Test

The DRC Connect Test is fine for Trace_to_Pad, where the Trace end-point needs only be inside the Pad area = OK

Even a Leave Trace seems to find the thermal geometry ok, and it connects inside the Pad.
So Trace_to_Thermal looks Ok too.

However, the Thermal Connect test for Thermal_to_Pad is clearly using something else, as thermals that are well inside the Pad area, fail to register as Connected ?

The problem with this, is false reports are generated from thermals that _do_ connect fine.
It requires manual addition of redundant trace segments, in order to pass.

Summary:
DRC Connect of
Trace_to_Pad = OK
Trace_to_Thermal(fill polyline?) = OK
Thermal_to_Pad = Fails.

[PCB Wiz (1-pcb-wiz)]

Second file added, Trace_to_Pad boundary case (seems to allow only one attach...)

[PCB Wiz (1-pcb-wiz)]

I should clarify, this Thermal_to_Pad test case is from stacks imported from other CAD tools.
These tools create more comprehensive stack-ups than kiCad uses on average, but KiCad _does_ import the stack ok, and plots / routes ok.

It is the PcbNew DRC aspect of Connect checking, Thermal_to_Pad, that has a coverage gap.
Must be close, because 2 of 3 Connects are ok.
ie it looks to be aware of the fill polyline, for Leave-Trace connect tests, and it is aware of the Pad outline, for Enter-Trace Connect tests.

It is when Thermal_to_Pad is needed, that it seems to either skip entirely, or use a different test ?

[jean-pierre charras (jp-charras)]

PCB Wiz,

This is not the first time you are reporting your problem.
Currently (I already said that) Pcbnew does not support pad stack.
You have to live with this limitation.

[PCB Wiz (1-pcb-wiz)]

This is a quite separate bug, that I uncovered in my Pad Stack tests.

Here, the stack issue is secondary, and the nature of this bug, is that the Pad-to-Fill(thermal) connect check, is different from the Trace-To-Pad and Trace-To-Fill connect checks.
I cannot tell if it is missing entirely, or coded wrong.

The fix required is nowhere near PAD Stack handling, but is in the DRC.Connect code, run after flood.

I have seen other reports of erratic connect on Fill, so maybe this can also fix those ?

[PCB Wiz (1-pcb-wiz)]

I have another example, and turns out I was right about other cases being driven by the same bug.
I waited for another posting on Fill-Connect fail, and analyzed the failure.

See attached image.
LHS is the fix-up-trace required to connect PAD-FillPolyline.
RHS is a reduction in rules that gives two thermal spokes, but _still_ fails Connect check.

If the code can be changed so that PAD-FillPolyline check is either fixed or added, it should remove many (most) of these false errors.

Looks to me like present PAD-FillPolyline connect check, is working to the PAD-Centre only, NOT the Pad-outline.
( Trace-Pad connect check works to the PAD Outline.)

[PCB Wiz (1-pcb-wiz)]

See also expanded comments in
https://forum.kicad.info/t/rats-nest-wire-not-going-away-between-two-connected-gnd-pads-via-copper-fill/3692/15
around how to change Clearance & LineWidth, in order to shift the FillPolyline border, so it includes the Pad-Centre, and it is there that Connect flips to OK.

[Novak Tamas (novak-7)]

The forum post you linked is the best to describe the problem. I think there is the same algorithm problem when deciding if keeping a ratsnest line or deleting when connected.

See my attached image where a thicker and thinner track overlap each other, so connection is made. You still can see a short gray excrescent ratsnest line at my artistic pink arrow.

[PCB Wiz (1-pcb-wiz)]

Novak Tamas " The forum post you linked is the best to describe the
problem. I think
there is the same algorithm problem when deciding if keeping a ratsnest
line or deleting when connected."

 They are similar, but I would not quite call them the 'same algorithm
problem', as the fix needed is quite different.
Your linked issue arises because PcbNew uses the trace-polyline-points, and
ignores the real width.

The PAD-Thermal connect bug is a result of _not_ using the PAD Outline. Fix
is to change to use PAD outline, just like Trace-Pad arrival does now. ( The
geometry code must all be there already.)

When that is fixed, it will still use the Trace-polyline-points, but fill
areas tend to have minimal-end thickness, so the differences caused by not
using width, are less.

Back to the other case:
Trace-polyline-points will be faster, but including real width (& some
overlap margin?) is more precise, so I guess this is a speed/precision
trade off.

If the Trace-polyline-points are changed to include width, now you need to
worry about acute copper angles (acid traps) in cases of 'just touching' -
some overlap margin of say W/4, W/5? etc, or some smarter checks could be
needed.

Your linked trace-trace case could also be solved in other ways.
It is rare to have polyline ends miss-match, (I would simply fix the ends),
but other solutions I can think of are

* Offer a better snap - not just grid, but also nearby-end-point (LibreCAD
has this) -> user fix is easier.

* Add a "scan & join" algorithm, which looks for close-by (inside larger
radius) but not coincident traces, and adds a segment of the smaller width
to join. Run of present DRC (without Trace width) will then pass.

​

[Jeff Young (jeyjey)]

Snap to nearby point is logged elsewhere.

I'm changing this one to a feature request for "Join near misses", which would be a nice cleanup option.

[Seth Hillbrand (sethh)]

Fixed in 63a952d23