Why are the Kicad Library conventions non-IPC compliant?

For a “Stick Topic” or “FAQ”
Naming conventions and other design rules should sit at the top of the category topic list

The problem with rules… my experience with coding standards is that they are highly ineffective. If they are comprehensive, they are too unwieldy to use. A lot of the stuff is cosmetic, and not necessary to end performance.

Frequently, different conventions are contradictory, so clearly they are rules for the sake of it. Instead of making humans do what they are bad at, the only way to use rules effectively is to have tools that support them and do automated checking. The #1 thing for rules is that prevent errors in the final product, anything else is not that important.

In the open source case, rules are largely counter productive. You want lots of users to see and check the files, to do that you must accept them into the repo. Eating dog food can be unpleasant, but it is how to harness crowd sourcing.

KicadCloud has been around for a while (now dead?), and has a “free for all” approach. It has a few problems, e.g. awkward to find and use the parts. Often low quality, which is expected, but without efficient way to update parts, rate them etc.

snapeda.com is almost good, but possibly they try to be too comprehensive and quality suffers. eg. there are 135 matches for BSS84, but then you get http://www.snapeda.com/parts/BSS84L/Motorola/view-part/

I believe some sort of compromise would be better, user generated content with some curation by experts, more like a wiki model.

I just cobbled something together for a specific set of connectors (two 164 way connectors…). It was worth writing code just to avoid doing that in the GUI. I got the text from a PDF, and then wrote a parser.

Here is a simpler example :

#lib Nucleo
#field name Morpho_CN7
#field prefix P
#fmt %name%,%type%
#type dip horiz
#number 1 2
PC_10,BI
PC_12
+3.3V,POWER_OUT
BOOT0,BI
NC
NC
PA_13,BI
PA_14
PA_15
GND,POWER_OUT
PB_7,BI
PC_13
PC_14
PC_15
PH_0
PH_1
VBAT,POWER_OUT
PC_2,BI
PC_3
// right side
#number 2 2
PC_11
PD_2
E5V,POWER_OUT
GND,POWER_OUT
NC
IOREF,POWER_OUT
NRST,BI
+3V3,PO
+5V,PO
GND
GND
VIN,PI
NC
PA_0,BI
PA_1
PA_4
PB_0
PC_1
PC_0

I like all that except the last bit. Relying on admins is what creates the bottleneck. Get the users to verify the quality!

Actually the forum software here gives a good example. It takes many years of experience with user-generate content sites and enables features for the community to manage itself. There is also wikipedia of course. Obviously wikipedia is quite flawed, but the amount of useful info there is vast, and it is largely free.

Yes, that would be the best to make some platform where people will add their libraries and the highest rated / most downloaded will be on top of the list (I guess the first places: 1. kicad github, 2. smisioto, 3. some ipc compliant stuff, >4 other people with their own libraries).
The approach would be to group content by author (author == set of rules). The contribbutors who made more libraries of better quality, keeping one convention, will win and then users will have easy access to their good libs in one place.
Unfortunately I won’t do that - no skills :confused:

would you mind to share the scripts and the footprints?

I didn’t change that much. Attached you will find the only script I changed. Changes are documented by MBA. Use the make file to generate the scripts.

freepcb2pretty_MBA.zip (7.0 KB)

Furthermore I created some footprints with the Library Expert program using (I hope) the latest JEDEC specs and compared them with the Kicad footprint:

The Kicad pads are 0.25x1.3mm, the IPC pads are 0.25x1.37mm. Not that much of a difference.
For resistors I see larger differences. IPC uses larger pads than the Kicad library.

And of course the results depend highly on the source: I have seen different JEDEC specs, all resulting in different pad sizes. And with every IPC version (currently C), the sizes differ also (different heel/toe calculations)…

So, creating standard footprints, while the standardization committee is changing the standards might be a lot of work :rage:

I find many KiCad footprint pads are too small, often no bigger than the lead.

True. I did check the LQFP footprint again, because I made a mistake, and added a Kicad C and R together with a IPC Resistor. The IPC R footprint is much larger (1mm instead of 0.7mm) than the Kicad R, but the Kicad C is about the same size as the IPC R. These R/C footprints are 2012/0805 sizes btw.

  • Top Left: Kicad SOT23-3 and next to it the IPC version. btw, the SOT23-5 in Kicad is much more like the IPC version.
  • Then next from top to bottom: Kicad C, Kicad R and IPC R
  • Next to the Kicad R is also an IPC R
  • On the right: IPC LQFP48 footprint. Padsizes are larger, 0.28x1.62mm (enlarged toe with 0.1mm to match Kicad footprint, otherwise the default would be 1.52mm, still larger than the Kicad footprint)
  • In the middle: The Kicad footprint with padsizes 0.25x1.3mm. This footprint has clearly a much smaller heel.

So there are differences with IPC generated footprints (assuming again the sources for the dimensions are correct), but is this really a problem for some people? Did designs go wrong because of this? Did fabhouses return or adjust the PCB?

I never ran into problems I must say, although I did enlarge the R footprint because it really is too small!

And what about the form of the pads: rectangle, oval? Kicad is unable to create the IPC pad rectangle /w rounded corners, so the closest would be an oval chaped pad.

Many of resistors, capacitors, qfp, qfn, dfn, sop have land patterns specified by manufacturer. Both manufacturers and IPC recommendations may work or fail depending of technology and the component (ipc algorithms probably are not smart enough to work perfectly with every package on the market).

roundrect is in the builds since before June. Sadly, it did not make it into 4.0.3.

I have seen R.C footprints pushed a little, to allow trace-between pins, as that can make a big difference to routing.
Maybe that squeezed R was done to allow 2 traces ?
Likewise, for SOT23, the IPC one looks to not allow a trace thru the channel, due to too much inner heel.
KiCad SOT23 does look a little too small.

1 Like

I’m sorry but these are terrible ideas. The second bullet will be garbage in garbage out. IPC exists to ensure best practices are used. Many, many hours have been devoted to developing these best practices.

1 Like

So if I have to check each land pattern for accuracy and quality why not just make my own? This is more or less what I’ve been alluding to…

1 Like

Not everybody finds “non-ipc” footprints a garbage. If there are strict rules of sharing footprints by official channels people don’t share their work - so the kicad users will get neither the ipc nor anything else. System of users ratings could allow to choose these libraries which are really useful for users (probably some of the highest rated would follow the ipc-7351).
Footprints made with different conventions are widely used and distributed with different EDAs. Footprints made with ipc algorithms may be also garbage (sometimes it’s hard to determine the input data). Some of people claim that it’s best to follow the components manufacturer recommendations (he knows his package better than ipc). Finally if somebody needs a perfect footprint he has to do it on his own, considering the technology he uses. It’s not true that everybody who designs professionally must follow all the rules defined by ipc.

Some footprints partially following ipoc-7351 are here: https://github.com/rohbotics/IPC7351-Nominal.pretty

That’s correct, & I know designers who have even tuned their footprints by capacitor thickness, in order to get best solder fillet performance.

However, some ‘standards guidelines’ can help pollinate everyone’s efforts, without getting too formal
In those examples above, things like

  • Better Courtyards
  • Pick and Place centre
    can be used as examples.

Is that new or can I still assume that the origin in the footprint drawing area represents this (those appear as dark blue crosses in PCBnew when ‘Anchors’ is switched visible in the render tab)?

Further up I can see that IPC seems to suggest to put a visual mark on the Courtyard layer, is that correct?

Not all CAD packages have the blue cross :slight_smile:

  • so it is a good idea to have some layer+entity to
    a) show the Pick and place (usually this is the drawing origin)
    b) Give something that can be picked near the centre.
    Some CAD packages pick better on an entity, thus if nothing is near the centre, it can be hard to pick and move a small distance.

Most IPC examples above have snug-courtyards, rather than just simple rectangles.
This makes sense for those tools where courtyards are properly checked, and in those shown, the better courtyard allows decoupling caps for example, in the corner areas.

That is a pitty. Hope it will soon make it into a new version!

That might be the case.
But in general I see that IPC uses a much larger heel than the existing footprints if I follow the Library Expert default settings. The weird thing is however that in the IPC recommendations, a much smaller heel is specified than in the previous version. If I follow those recommendations, the pads are much smaller than the current ones:

Those are the same as the ones previously linked: they use old naming conventions and old rules. Furthermore they have no fabrication layer outlines and a large courtyard.

Yup, that visual mark is auto generated. The software can also auto generate fiducials if you want…

If I look at the recommendations, the calculations are simple, but it seems not all manufacturers are using these:


The question is, to get “professional” footprints, should one follow these goals to get IPC compliant footprints? Or follow the datasheets for each manufacturer?

2 Likes

It’s great to see that people are motivated to share their KiCad libraries; I would reiterate that if there are users willing to spend time contributing (and moderating) symbols and footprints then there would be great benefit in adding these to the github library: https://github.com/KiCad/kicad-library/wiki

The reason the github library is not an “open-slather” approach is to protect the quality of the library (as @wsender points out) and make it useful / reliable for all users. Some of you have pointed out that the github libraries are not very good. I would argue that they are not very good yet.

Moderators are nominally selected from the pool of people actively contributing - so if you want to help out, start improving the components or submit new ones!

There was a specific example in this thread regarding the lack of package outlines to the F.Fab layer (this was a very good example of a shortcoming of the current libs).

This has now been fixed for the Housings_SSOP library (see here https://github.com/KiCad/Housings_SSOP.pretty/pull/12)

Similar PRs are open for many other libraries:

In short - if you see something broken, help us to fix it!

I also want to make mention of a great footprint generation tool (Python) which has been used to generated hundreds of footprint symbols in the github libraries:

Here’s an example for the JST PUD series connectors:

https://github.com/SchrodingersGat/kicad-footprint-generator/blob/master/scripts/JST/PUD-top-entry.py

Not only does this allow parametric footprint generation, it is also open-source and you can contribute to make this tool better also.

4 Likes

I agree that a lot of work is done lately to improve the Kicad footprints :yum:
What I don’t understand however is why the IPC recommendations are not used to really improve the footprints and at the same time make the footprints easier to verify (see also next point about footprint generation)!
Examples:

  • I see some some discussions about the bevel/layout of the assembly outline. Why? Just follow the IPC recommendations, and no discussion is necessary anymore on this point. It’s a rectangle with a 1mm bevel @ pin 1.
  • Furthermore, although the assembly outline is drawn, the refdes is forgotten, making the assembly layer still useless for a fabhouse.
  • The value should be removed from the assembly layer and put somewhere else

I think this thread (among others) are created by ppl who want to help Kicad to get better footprints, but some of those fixes (altough IPC compliant) do not comply with the KLC, which makes it difficult to help.

This footprint generation tooling would be the best way I think to easily comply to the IPC standards, AND at the same time document the used footprint, AND minimize footprint maintenance effort.

For this the generator should:

  • use the package dimensions, nominal values +/- tolerances
  • use density level settings like courtyard excess, toe, heel and side values
  • use the B orientation
  • use specified (not built-in) line widths
  • generate the center point
  • generate pin 1 line

If all these settings would be put into some csv file, then any footprint for any density level could be auto-generated for most SMD packages and if you want the various IPC versions.
Also, in the future, if IPC vD would change some of these parameters, creating IPC D compliant footprints would be very easy, and not cause a lot of work for the footprint maintainers!

I agree, I see no reason why Kicad should create it’s own standard, while the IPC standard is there :innocent:

But seriously. As my programming skills are very limited, I did a search on the mighty internet looking for Kicad/IPC footprint generators, but could find nothing usefull (usefull as in €0 and open source).

However, would it be very difficult for a real programmer to create SMD footprints (SOP, SOT, QFN, R,C,LED etc.) generator using the mentioned package dimensions and toe/heel/side settings?? I mean, all the existing software packages are using these as the input for footprint generation :confused:

So, I think that, for most parts, the IPC recommendations should supersede the manufacturer recommendations.

The problem with IPC algorithms is that sometimes they doesn’t work with data provided by manufacturer. The tolerances are too big so the pads must be clamped to meet clearance (probably not optimal).

I agree, I see no reason why Kicad should create it’s own standard, while the IPC standard is there

The kicad library convention is simpler than the whole IPC so maybe more suitable to it’s purpose - most of contributors don’t have and don’t know the ipc standard.