← Back to team overview

kicad-developers team mailing list archive

Re: Re: Kicad libraries for pcbnew


viking632 wrote:
--- In kicad-devel@xxxxxxxxxxxxxxx, Vesa Solonen <vsolonen@...> wrote:

On Thu, 8 Oct 2009, viking632 wrote:

I've been working on some pcbnew (physical package) libraries for kicad.

I took a brief look at them and they are fine and very needed addition. Solder mask cutouts that overlap need some consideration I think. Should they be cut open in one piece to avoid manufacturing warnings? I don't certainly know what's the practice, but this just came to my mind.

IMO the scripted method for making the land patterns is very much preferred to anyting else. Please keep up the good work.


The size of the soldermask (and the pastemask ?) seems to be hardcoded to be 6mils larger than the pad on all sides, and there is no way of specifying the masksize(s) in the component libs.

As you noticed, this causes overlapping masks on closely spaced components like QFP:

QFP packages with 0.5mm pitch have pins that are 0.22mm wide,
with 0.254mm wide pads on the recommended land pattern.
This, with the 6mil masks, causes an overlap of 0.059mm (2.32mils).
QFPs with 0.4mm pitch have 0.18mm wide pins, with 0.203mm recommended pad width, causing an even larger overlap of 0.108mm (4.25mils).

There are only two ways of changing this in kicad: Either lower the built-in default from 6mils to 3mils (4mils is too large), or enhance the pcbnew component libraries with two extra values: The masksize (relative to the pad size) in X and Y.

When doing a PCB Design Rules Check on my *QFP sample board, it doesn't complain about the overlapping masks, so are overlapping masks really a problem, or can they be ignored ?

I've searched the web for info on this, and the recommendation seems to be, that in general, pins should be NSMD (Non-Solder Mask Defined), i.e. have a soldermask that is 60-75um (2.4-3mils) _larger_ than the pad on all sides.

This seems to indicate, that the 6mil value in kicad should be lowered to 3mils, or has the 6mils been chosen to allow larger misalignment of the soldermask (for hobby production of PCBs) ?

Exposed thermal pads that are close to other pads should be SMD (Solder Mask Defined), with a mask that is 100um (4mils) _smaller_ than the pad, to reduce the risk of bridging when soldering.

Pads that are very close (or even "too close" together, as the QFP examples above), should use one big opening, as the soldermask alignment accuracy won't allow accurate enough placement, and the thin lines of the mask won't help much in prevent bridging anyway.

Overlapping masks will of course give this desired box opening result.

Pads that are a little farter apart could also benefit from a box opening as well, but achieving that would require a library change: The addition of masksize to the Pad definition.


These are important observations, Øyvind.

I am not comfortable that leaving this concern on a yahoo mailing list will ever lead to anything.

Lorenzo's solution is agreeable, this info should be part of the component's pad stack, and that would affect the file format that Wayne is currently working on.

So if we were to be diligent, we'd be gathering up these concerns, then rolling them back into the file format.

But I just don't like the infrastructure of the project, I view a yahoo mailing list as a lousy way to keep track of concerns like this.

We need better tools people. Especially if we are ever to successfully attract, retain, and organize more developers.

Has everyone had the time to review some of the tools over at Launchpad? I know that sourceforge has recently added tons of tools also, like trac, git, bazaar, but the the tools are all un-knowledgeable of each other, not integrated with one another in the way that the tools at launchpad seem to be.
This yahoo mailing list cannot be the best we can come up with, say what you want about any other suggestions, I maintain that this yahoo mailing list is pretty inadequate in my view, especially since about 50% of the traffic on it seems to be more user centric than developer centric, and I am guilty of that also.

Somebody is going to have to make some decisions if this project is ever going to get into gear. And those decisions will require volunteers to implement.


Follow ups