5.99 DRC bug? Hole-to-copper not correctly checked/enforced

I notice what looks like a bug in the DRC in v5.99

The “Hole to copper” clearance does not seem to be respected (or considered) for copper zones. I specify a “Copper to hole” clearance of 0.3mm, and set up a copper zone with 0.15mm clearance. (minor complaint here: the text / phrasing there is poor quality — it says “Copper hole clearance”; what is “copper hole clearance”? The clearance of a hole in the copper? Shouldn’t it be “Hole to copper clearance”? Or “Copper to hole” … but not “copper hole”)

The zone does get filled up to 0.15mm from the edge of the via; yet the DRC does not flag a “copper to hole” violation. (it does flag it for a trace that passes too close, but not for the copper zone)

I expect one of the following two behaviours:

  • The zone gets “clipped” to leave a 0.3mm clearance from the hole.
  • The DRC flags an error that the design rule constraint is violated.

See attached “minimal” demo (I just took my board file — which I’m not allowed to share here, since it is a work-related project — and removed as much as I could to leave a board that exhibits the problem).

DRC-bug.kicad_pcb (10.2 KB)

Notice: this board was created with KiCAD 5.1, and I opened it with 5.99 just for the purpose of running the DRC (since the DRC in 5.99 has additional features). The flawed behaviour was present on the original/whole board; in this minimal demo, I actually modified a trace to make it violate the copper to hole clearance, to show how the rule is indeed being applied, but only for traces and not for zones.

Please log that on https://gitlab.com/kicad/code/kicad/-/issues.

Done!

:non-emoji-filler:

… and fixed. :hammer_and_wrench:

5 Likes

Nice! :beer:

I guess I’ll upgrade tomorrow and see (I’m curious about which of the two options is what’s supposed to be — I tend to believe that the first option I mentioned is the one that makes more sense; however, either one is good enough: no-one should consider a design finalized without having run the DRC and gotten a clean report)

I thought the “nightly” in the denomination of the experimental download version implied the literal meaning of that.

What I’m trying to say is: I just upgraded my kicad-nightly version; it changed, from 5.99.0-unknown-c5e195bdff~131~ubuntu20.04.1 yesterday, to 5.99.0-unknown-1332208ab1~131~ubuntu20.04.1 now, after the upgrade.

However, the behaviour of the DRC for hole-to-copper did not change. Is it that there is a delay for the committed fixes to propagate up to the nightly release?

Sometimes there’s a delay. Building a nightly build starts at some time and uses the latest state of the source code at that moment. Building takes some time. If a new commit comes after that it’s not taken in but will be in the next successful nightly build.

You can find the last used commit in the version string, the part which starts with g and has numbers and letters a…f (it’s a hexadecimal number). You can compare it with the source tree history in https://gitlab.com/kicad/code/kicad/-/commits/master/. (The commit hashes in the version string and in the gitlab history page are partial, the actual hash is much longer in git.)

Two notes:

The hash part in the Ubuntu package version number doesn’t start with the letter g.

Commit 1332208ab1 is newer than Jeff’s fix for this bug, so the fix should be included in your “after upgrade” version.

It would seem like the bug depends on additional conditions that Jeff didn’t consider? Or maybe I’m missing something? This is a screenshot illustrating that the bug is still present — same layout file I posted, opened with the newer version of the nightly:

Immediately after taking that screenshot, I took this one:

Someone shed some light?

Hole clearance runs only on NPTH holes. It’s not run against vias (or pads with copper annular rings).

Well, that is a bug, isn’t it?

I mean, technically, it is a bug if the program advertises that it is going to do something but does not do it, or does something else. I’d say that the program indirectly does state that it will enforce or check clearance against all holes, since the parameter is labeled “Copper to hole clearance” (although as I pointed out, it is phrased as “Copper hole clearance”, which is a very poor phrasing). Moreover, it makes sense for a user to expect that the clearance to plated holes shall be checked.

At the very least it’s a gross misfeature — manufacturers do specify this clearance separately; I remember seeing this in Seeed’s capabilities page; also, I recently got a request-for-quote returned from a manufacturer, simply telling me that they cannot do less than 0.21mm distance from any copper to a hole (copper from a different net, that is).

If for whatever reason my request is dismissed (e.g., you decide that I am mistaken in claiming that the functionality is wrong, or even if you agree but simply do not have time to do this for v6 given the importance of this bug/misfeature), at the very least, the text in the Design Rules dialog should say “NPTH to copper clearance”, and not “copper to hole”. That is, the dialog should say what the program actually does.

If it’s a plated hole, then it’s a copper-to-copper clearance issue. And those actually know about different nets. Hole clearance rules don’t, because holes can’t have nets.

Is there a reason you can’t use the copper-to-copper clearance for things like Seeed?

Like I mentioned, Seeed specifies (plated) hole-to-copper separately; so does the local (Canadian) PCB manufacturer that I dealt with recently; they were ok with 4 mils (0.1mm) copper-to-copper, but at least for an 8-layer board, they cannot produce boards with any copper closer than 0.21mm from a (plated) hole.

For Seeed, see http://support.seeedstudio.com/knowledgebase/articles/447362-fusion-pcb-specification (fourth image from top — Minimum distance between plated holes and traces).

Although hey phrase it as “distance to traces”, given the note “to prevent ion migration”, I would assume that there is no difference whether it is plated hole to a trace or plated hole to a copper zone.

The local manufacturer initially also phrased it as “distance between holes and traces”; when I asked him whether the requirement was specifically holes to traces or in general holes to to any copper (including copper pours), he clarified that it is the distance to any copper.

Additionally to this: there is an inconsistency between the actual functionality I’m observing in 5.99 and your clarification above: the copper-to-hole is applied for plated-holes to traces separately from the general “Minimum clearance” (which the icon shows as distance between two traces). You can see the DRC message, specifying that the distance from the hole to the trace is 0.22mm while the requirement is 0.3mm; I set the “Minimum clearance” to 0.1mm, so that one is not being violated (yet the DRC is still flagging the via-to-trace < 0.3mm).

To further clarify: this is normally not an issue when you only use vias with a “proper” annular ring, typically matching the minimum trace width (which typically is equal, or in the same order of, the copper-to-copper requirement).

Usually, the required minimum hole-to-copper is no more than around twice the copper-to-copper requirement; so, one defines a via where the outer ring goes X distance outwards from the hole, and then leave another X due to the copper-to-copper clearance; you naturally end up with 2*X hole-to-copper clearance, so you’re likely to be ok.

So, that’s a reason why normally, with the copper-to-copper clearance we’re typically ok. But as soon as you try to achieve stubless holes (holes with no outer ring in the inner layers where there is no connection to that hole), then the DRC does not help you (you can still do it, but you have to manually make sure that you’re respecting that hole-to-copper distance). And yes, I should clarify that 5.99’s DRC does help you with the part of hole-to-traces, but not with the copper zones.

The lead dev team discussed this and concluded that testing all holes was more likely to meet expectations.

New bits are up.

2 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.