New DRC flags zero-clearance pads

I can confirm. The DRC of pcb 4.2.0 treats zero clearance of pads as a design rule violation.

Zero clearance can be intentional to make the pad connect with the polygon. If zero clearance was set by accident, the resulting shorts get caught by the connection check. I agree with Joseph that DRC should not complain about zero clearance.

Zero clearance is a bit of a dirty hack though. It totally dissolves the pad in the polygon. Depending on the soldering technique this might not be desirable because the polygon may dissipate heat faster than the solder tip can deliver. For thru hole pins the thermal tool can be used to make the proper amount of connection. I would be nice if the thermal tool would work on pads, too.

---<)kaimartin(>---

Hi guys-

Sorry, I just noticed this. It didn't get prioritized in my inbox. I'll try to take a deeper look at it this coming weekend.

I fixed a lot of DRC issues in 4.2.0, and this may have been one of them. I believe it will flag any object with a clearance less than the global minimum copper clearance as an error.

I believe the "correct" way to connect a surface mount pads to a plane is to set an appropriate clearance for the pad and then use a line without the "clearline" flag set. This can be done by changing a setting in the Settings menu: "New lines, arcs clear polygons". I don't remember off the top of my head if there is a hotkey for this.

I agree that the thermal tool should work for pads. I actually started looking at implementing this a couple months ago. It turns out that it's not as trivial as one might hope. There is a branch you can try if you're interested: LP699495. However, in my opinion it's not ready for prime time. I think it works for pads that are horizontally or vertically aligned, but non-90-degree rotations will cause seg-faults.

This problem first appeared for me in 4.2.0. In previous versions, zero clearance pads passed DRC.

I don't like the "correct" way because it would mean fitting in 176 hidden lines in my design just to remove DRC warnings. The lines might need to be off grid or sized just right to avoid neighboring elements.

I've been thinking about this some.

Your original assertion that they should be ignored because such errors would violate the netlist, is a little bit problematic, because the netlist check isn't done by the DRC; it's done by the rat-optimizer. Additionally, the errors show up in the message window, not the DRC window. So, if you've finished your layout, you're probably not thinking about optimizing rats anymore, and you many not even have the message window open. Then you run the DRC and such an error would be easily overlooked with catastrophic consequences. The DRC does explicitly tell you do open the log and use the rat-optimizer, but I think most people read that text once, and then never look at it again. They probably just see it as a "cover-our-butts" message from the developers (which, to be fair, it kind of is), and pay it no mind.

Yes, yes, it's fairly clear that this is a test that the DRC *should* do. I'm not sure why it doesn't. That could be called a bug in the DRC. My previous efforts were primarily focused of fixing what it already did, as opposed to adding new tests. So it didn't occur to me to do this.

The other reason that I'm very reluctant to revert this behavior is that it creates a special case in the code. I've been trying to eliminate special cases, to the extent possible, as they generally make things less predictable and the code base harder to work with. If the code base were less convoluted, I'd be less reluctant, but in its current state, special cases are just waiting to cause trouble.

The two actual solutions that I see to this are:

1) as Kaimartin suggested, to make the thermal tool work for pads.

2) extend the DRC so that you can specify different parameters for different kinds of objects. That would let you specify 0 for the minimum clearance on pads.

Neither solution is trivial. Seeing as how I've actually started the first already, I suppose I will try to prioritize that.

If you want, I can create a special branch for you in the git repo that reverts this behavior in the interim, however, I don't want to do this in the master branch as I don't think it's a good long term solution.

--Chad

Chad,

As a developer of many large code bases, I appreciate your concern for the purity of the code. As a user, I just want it to work. Allowing thermals on pads would solve the problem. A separate clearance parameter for pads might be useful for other reasons but would not work well for my use case because I still want the DRC to catch other non-zero pad clearance violations.

Still, adding back the exception for zero clearance pads in the DRC seems like the simplest solution. I checked out the code and this change was all I needed:

    @@ -637,7 +637,7 @@ drc_callback (DataType *data, LayerType *layer, PolygonType *polygon,
         /* fall-through */
       case PAD_TYPE:
       case PIN_TYPE:
    - if (clearance < 2 * PCB->Bloat)
    + if (clearance && clearance < 2 * PCB->Bloat)
         {
           /* The clearance is too small, but it could be cleared by other
            * objects.

You could add a checkbox in the DRC config to toggle this behavior.

Thanks for all your hard work.

Joseph