I have a simple project where I connected USB GND pin to the voltage regulator in eschema:
I am sure I (re)exported NET list in Eschema and (re)read it with Pcbnew which shows me that pads aren’t connected by a filled GND zone… But they are…
Why is rat’s nest showing me that these two pads aren’t connected? Here is the project .zip file:
There are a few options of what happens here.
First: try to restart pcb_new. Sometimes this helps it to recognize that some parts are connected.
Second: Drc might not realize that the zone connects to this pad because the center of the pad is not covered by the zone. (Drc only checks the center of pins against connection with zones.) The solution here might be to play around with the clearance settings and with the thermals settings.
This post might be a good read: (I think it is the first post in the linked topic that goes into great detail. Maybe some other posts might be a good read as well.)
I found the problem. I had to right click on the ZONE FILL and edit its clearance to a smaller number. Now this problem disappears. This should be fixed though. =)
Pretty major bug I reckon. Pretty standard to let your fills connect pads right? My fix, which avoids having to change the unrelated and side-effect prone clearance parameter, was to add short (redundant) stubs from the pad to the fill.
See screenshot:
It’s not a bug it does however need fixing but it is up to you to fix it.
It simply cannot draw the spokes of the thermal relief with the parameters you have given it. Therefore you either need to adjust the relevant parameters or use a solid connection.
Maybe I’m misunderstanding how it’s supposed to work then. As you can see in my screenshot, I’ve had to draw a track over the top of the fill to satisfy DRC. So pcbnew in fact was able to draw the necessary spoke to connect the fill to the pad. But it doesn’t consider it connected. Isn’t that a bug?
I’ve had the same issue on tracks I’ve necked down - even though the fat and thin tracks are clearly overlapping, I still have to draw redundant tracks from the centre points of the ends of each track to convince DRC that they’re connected.
It’s as if pcbnew is determining “connectedness” based on the location of the centre line of each conductor. That seems like a problem - a mere annoyance once you know the workaround to get tracks to connect, but possibly a major problem if it means DRC will miss unintended connections.
Filled zones do not use the global settings used for traces. They have their own clearance and min width settings.
If you setup the zone with the same values as you use for traces you might discover that it indeed behaves the same way as a trace.
Yes, that’s exactly how it works, and I’m sure it does that for speed reasons.
If you look carefully, the rats nest line starts from the circle centre of any trace end.
It will only fail, if the spoke has a diameter larger than the SMD PAD width, which is easy enough to avoid.
With differing sized traces, it only needs the smaller trace centre to make it inside the outline of the larger trace, to pass as connected, and the rats nest shows when this threshold is reached.
That’s also usually easy to meet, and mostly such traces are centre-centre aligned as you route them.
There could be a point to add a more precise, but slower, DRC that uses a true copper outline test.
Such a test could also be expanded to catch fill violations.
Addit: I guess the spoke generator engine could add an option to use the smaller pad XY as the spoke limit, but that might struggle on the new polygon pads ? It could do that on simple geometry pads, and this QFN looks like the most common ‘area of problem’.
Ah ha! Great explanation thanks PCB_Wiz - will certainly help rationalise what’s going on. It’s my first time routing a board in pcbnew so the behaviour was off-putting. Now I see what it’s trying to tell me.
My vote would be a copper outline test - changing spoke limits or clearances will only lead to less predictable behaviour and more edge cases for unusual geometries. From the user’s point of view, a connection exists when they can see the copper overlapping. And importantly, that’s the point of view of the electrons too - DRC missing an unintended overlap would be bad news once the board is printed. A slower DRC is probably fine, though the live rats nest might need a bit more attention.
And yet when something doesn’t work as you expect it’s a Pretty major bug even though others have been using this software for years.
DRC attempts to ensure a robust connection by requiring a certain amount of overlap and the algorithm favors performance. With an appropriate grid setting such overlap is not only easy to achieve but hard to avoid.
It is not possible to have unintended connections between differing nets without violating clearance constraints.
I’m terribly sorry. Seems I made a mistake. Hopefully this thread helps other idiotic newbies to avoid that embarrassing assumption.
