Rats nest wire not going away between two connected GND pads via copper fill

Layout
1

I’m seeing a persistent rats nest wire between two GND pads. To my eyes it looks like they should be properly connected.

I have two GND copper fills (one on top and one on the bottom).

I’ve attached screenshots of where this happening. One of the screenshots shows the top copper layer (red), the other shows the bottom (green).

I’ve placed two vias to connect the top and bottom GND copper fills. If you trace the path starting at the bottom layer you can see that the bottom copper fill connects the pad to the via, the vias are then connect to each other on the top layer. Finally, the second via is connect to the other GND pad on the bottom layer.

To me it looks like both pads are connected to the same net (GND). Am I missing something obvious here?

Thanks.

314×968 8.87 KB

385×977 11.3 KB

2

Are they listed as unconnected when you run DRC?

3

These appear every once in a while. You can file a bug report and attach the board if you would like to see it fixed. I think it has to do with KiCad’s DRC not being very robust. It is more or less a graphical error.

5

Is it possible to post the design here ?

If not, some things to try…

I have posted a bug, where
DRC Connect Trace-Pad = ok,
DRC Connect Trace-Fill.Polyline = ok
but
DRC Connect Pad-FillPolyline = not ok, in some cases.

To check for this, start a short trace, from every rats-pad to just into the pour area.
(PcbNew uses the co-ords to check so you need trace-centre >= Fill.polyline centre, which is visually a radius overlap, due to rounded ends)
Try vertical/horiz/45’ exits for a little variety.
When all rats-lines goes away, try shorten of one trace back toward the centre, until rats nest re-appears.
Repeat for various pads.
You can precisely adjust trace end via edit co-ordinate, as mouse route snaps differently inside a pad.

One you have a collection of ‘just-ok’ cases, look around for the common denominator/trigger.

If the rats nest does not go away, check for more macro issues, like larger scale breaks in Flood areas.

6

Thanks for all your suggestions.

It was indeed listed as unconnected in DRC checks.

I ended up adding a trace by hand from one pad to the other and placed 2 vias along the way and now the air wire is gone. It’s very strange because it looks almost identical to what I had before. The only difference is that before I placed standalone vias in those two spots whereas this time I placed the vias while routing the trace.

I’m not exactly sure what was going on before, probably some kind of bug in kicad.

It’s almost as if kicad doesn’t detect two pads being on the same net when you place vias to connect top and bottom copper fills in some cases. Maybe it’s just a matter of it not refreshing state? Who knows.

8

Can you try to define the trigger case, as that can help this type of thing get fixed, if it is a bug.

Freely-placed vias I would not expect KiCad to always see, as a trace that has a via ‘dropped onto it’, may not have trace corners near the Via.
If you have a Pad-Trace-Via-(Pour+Trace)-Via-Trace-Pad that passes, I’d suggest a careful unravel of that, like

a) remove trace on Pour Side.
b) Shift trace end away from Via centre, checking for DRC unconnect.

Addit:
I did some quick ckecks -
It seems add-via done on the same grid, will add a corner, and the rats-nest display seem to be valid/intelligent.
(ie as I move to overlap and move via/trace)
The via picks ups a NET name when it connects, and if you move the trace-corner/Via overlap so it is outside the Via, the Via can disconnect and drop the net name.

However, DRC reports Connect errors when visually, there are none ?
I think what confuses the DRC report, is it seems to pick a random Pin-Pair to report.

One of those pins is genuinely not connected, however the other reported pin seems chosen by ?? (nearest Pin?)

DRC also seems to do a more comprehensive ‘rebuild/reflood’ than a simple B command.
ie B will never drop a via-net-name, but DRC run will. (if there is no same-net trace corner inside via radius)

Perhaps DRC needs a rename, as it includes some rebuild operations ?
(DRRC for Design Rebuild and Rules Check)

9

This is something I have come across frequently. I just accepted it as part of using alpha software.

1430×791 12 KB

10

Unfortunately I don’t know how to reproduce this issue accurately, it just sort of happened after I applied copper fills.

I did notice however that running DRC checks changes the output of the “show unconnected traces” button. So it does seem to indicate that running a DRC check has some kind of effect on connection information. I hadn’t run DRC checks prior. So if anyone else finds themselves in a similar situation maybe try running DRC checks periodically.

I just noticed 4.0.3 is out so I’m going to download that now. It seems to have fixed quite a few bugs.

11

Can you post a minimal .kicad_pcb example with this effect ?
ie save the above, with delete texts and delete parts not GND related, should have no effect
removal of some distant GND parts may have no effect.

I tried a similar geometry to that shown (1 finger to 3 fingers), and it is ok for me.

12

Apparently, as a new poster, I can’t upload an attachment. I will find somewhere else to put it.

There is another post here somewhere about stunted thermal pads with copper fills not reaching them, and I have also experienced this, but it is easy to fix by adjusting the thermal spoke widths and clearance values. I thought this could maybe fixed the same way but I have not tried it yet.

13

Yes, that is my post :slight_smile:
I have a bug report in on Pad-To-FillPolyline in that, but I think the coders need more examples, so I was going to explore more trigger cases.

Not sure of the new-poster rules, it may be some small post-count, or it may be a time-delay, or both.
You could maybe try a PM ?

14

Example pcb should be here below. I don’t know anything about the file sharing service, I just found it on google. The link should be active for 7 days.

Download link:
http://wikisend.com/download/324944/test.kicad_pcb

Edit: forgot to add, some of the trace sizes are a bit odd on this board, it was fattened up a bit here and there to be produced on a router

15

Thanks, that was most helpful - I have analyzed that, and add it to the bug report.

1070×400 33.4 KB

Turns out the PcbNew does have a bug where
Trace-FillPolyline-Connect is OK
Trace-Pad Connect is OK
but PAD-FillPolyline Connect is not using the PAD Outline, instead it uses the Pad-Centre.

As a result, there are many false-connect errors.

Suggested Fix:
Have PAD-FillPolyline Connect, changed to properly use the PAD outline.

LHS is your close to your default rules, and a trace added and tuned until it just connects, via Trace-FillPolyline-Connect Code.

RHS is rules made smaller on Width & Clearance, so that two spokes generate, but still Connect fails.

If I make even smaller again, ie lower width, and lower clearance, then when the FillPolyline CentreLine includes the PAD centre, the PAD-FillPolyline Connect now passes.

FillPolyline CentreLine is not visible, but if you switch to fill outlines mode, you can estimate it.

eg in the case here, reducing to
A clearance of 0.35mm and FillLineWidth of 0.15 just fails Pad-Centre check
A clearance of 0.35mm and FillLineWidth of 0.125 just passes Pad-Centre check

In this last case, DRC gives no errors and no not-Connects.

Smaller FillLineWidths used to be avoided to keep Gerber sizes from ballooning, but KiCad has option for Polygon fill, which drops file size.
Also FillLineWidth defines the sliver-size in Gerber, so should not go too low (> 5 mil?)

Checking on this design for fill modes vs file size @ 0.125mm LineWidth
Segment-fill -> 502k
Polygon Fill -> 108k
So the cost for a segment fill is not too bad.

Personally, I’m wary of Polygon fill, as that uses / assumes a smarter Gerber post process, and we had a file badly broken a couple of years back, when the PCB house edited it using CAM 350, and the saved file changed the Fill-Orders. They gave us new boards, but it did cause a delay.

GerbView seems fine with both modes.

1 Like
16

Thanks for analyzing that. What you say makes sense because it is on the fine pitch components, 0.8mm and below where the problems seem to occur most.
Fortunately this sort of thing is not a problem for me, I don’t use the software for anything important, just testing microprocessor code before everything is redesigned more carefully for manufacture.

17

Since when do standalone vias work and stay with the net?
I thought they always needed a track that connects them to the correct net?

18

That one is easy… the pour looks alright, but as @PCB_Wiz already pointed out the pour won’t overlap the center of the pad 28 so it isn’t connected… just check the boundary of the pour to it’s right for getting the idea:

IT will probably sit even further inwards as pad 27 is thicker than the track to the right… check this with ‘pad fill visible OFF’, ‘tracks visible OFF’ and ‘filled zones visible ON’:

1 Like
19

Oh is that true? That would explain why it didn’t work haha.

I just assumed it would work because I’ve seen Eagle tutorials where Jeremy Blum adds a bunch of vias throughout the board to connect the top and bottom GND copper fills to ensure they are connected throughout the board. You can see it at 19:52 in https://youtu.be/CCTs0mNXY24?t=19m52s

I guess KiCad doesn’t behave this way. Thanks for clarifying that.

1 Like
20

Yeah, there was talk/work to be able to have more simple stitching vias in future… but I’m pretty sure that is not possible yet.

21

Stitching is one of KiCads greatest weaknesses at the moment. Messy and hard to move around

22

KiCad is what I’d call 'Lone Via Averse’

Rule: if there is a Trace-Corner anywhere under the via, it will attach it to that net.

That means a Moved-too-far-Via, or one simply copied onto a trace segment clear of any corner, will not connect.

Also, you do need to re-run DRC, not just ‘B’/Reflood to check this, as DRC is really DRRC, and it will rebuild the net-trees, and thus isolate any vias that now violate the rule. A simple re-flood does not do this.

If you are in Route-Mode and add a via, then it will add a corner to the segment when placing Via.
( ie you can add a via to an already routed trace, just take care to do it in Route Mode, or pick an existing corner)

It is a pity Copy-Via does not have the same auto-corner-add, as it knows it has a (eg) GND Via on the Cursor.

In route mode, you can use D to Drag a via, and keep the important Trace-corner inside the via.

1 Like