Why are the Kicad Library conventions non-IPC compliant?

Layout
39

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
40

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:

41

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.

42

True, in that case I simply enter the manufacturer values and generate the footprint. It happens rarely though.

I agree again. But if KLC would have been derived from the IPC standard, it would make it a lot easier to comply and adhere footprints to upcoming IPC standards.

It is also much easier to get the manual soldering versions of a footprint: just raise the value of the toe, and (re)generate the footprint.

The only thing I like about KLC is the naming convention: much more readable. But with all other things I do prefer the IPC reccomendations. And if you use recent datasheets, the manufacturer footprint is exactly the same as the “Nominal” footprint of the IPC 7351C standard.

Currently I’m using generated IPC footprints where possible. And in all other situations, I use Kicad’s footprints.

43

Exactly. Keep it as simple as possible so that it is not a daunting work to just glance at it.

Many rules regarding land patterns are from IPC-7351. They are noted as such in parentheses at the end of the rule. Of course, much like the libraries, the KLC can be improved so I am waiting for your suggestions! You can submit a pull request on the kicad-library repository.

Edit:

Our small team would be very welcome in any new addition. The only thing we require is a successful pull request of yours first as a demonstration of your seriousness. For a quicker processing of your pull request, please chime in on the KiCad IRC and send me a private message.

Regards,

Carl

3 Likes
44

To give you an idea about the problems I have with KLC and IPC-7351C I ran the check_kicad_mod.py against some of my IPC-7351C generated footprints:

  • The script crashes on most footprints with the following error:

    Traceback (most recent call last):
    File “check_kicad_mod.py”, line 38
    module = KicadMod(filename)
    File “cyx”, line 53, in _init_
    self.value = self._getText(‘value’)[0]
    IndexError: list index out of range

  • In the cases it doesn’t crash I get the following violations:

  • Violating Rule 10.4 (Value is filled with footprint name and is placed on the fabrication layer.)

  • Violating Rule 10.7 (3D Shape “.wrl” files are named the same as their footprint and are placed in a folder named the same as the footprint library replacing the “.pretty” with “.3dshapes”.)

  • Violating Rule 6.5 (Silkscreen is not superposed to pads, its outline is completely visible after board assembly, uses 0.15mm line width and provides a reference mark for pin 1. (IPC-7351))

  • Violating Rule 6.6 (Courtyard line has a width 0.05mm. This line is placed so that its clearance is measured from its center to the edges of pads and body, and its position is rounded on a grid of 0.05mm.)

  • Violating Rule 6.9 (Value and reference have a height of 1mm.)

Explanations:

  • Crashes: The IPC generated footprints don’t contain a ‘value’, only a refdes. The script cannot handle this I guess… If I add the value to the Eco1.user layer (my personal place to put the value and the value outline) I get a rule 10.4 violation.
  • 10.4: IPC specifies that the refdes should be placed on the fabrication layer, not the value!
  • 10.7: I’m using or re-using existing 3D models, so this is a logical violation of the KLC.
  • 6.5: Silkscreen width differs: IPC specifies for example 0.12mm for nominal density level
  • 6.6: Courtyard line width is indeed 0.05mm, but may be rounded on a grid of 0.01mm according to IPC
  • 6.9: IPC value/height depends on footprint size, so differs in most cases from the KLC 1mm rule. The refdes for instance should fit the assembly outlines.

So, apart from the 10.7 rule (which is my own fault/choice), the other KLC violations, although described as IPC-7351 compatible are a violation of the IPC-7351C.

So, what now? The Kicad team needs help, which I think a lot of ppl would want, but from the above excercise I know that every IPC compliant footprint I would propose shall conflict with the KLC, and thus be rejected!

1 Like
45

6.5 and 6.6 I think the KLC should allow IPC compliance.
6.9 is harder to judge, what would be the value/height range be in practice?
10.4 is a philosophy point

46

Yes, that would be great, and not a very big change I guess.

See following recommendations:

876×564 99.3 KB

And the assembly outline, with chamfer corner to indicate pin 1 location as follows:

876×577 72.7 KB

I don’t understand exactly what you mean by that: it is a clear IPC recommendation as you can see from the figures above and the fabhouses I know demand the refdes on the assembly layer. Just as they demand a clear pin 1 location on the assembly layer and a visible pin 1 location after assembly on the silkscreen layer for verification.

The more I read and think about this IPC stuff, the more I think that a table driven, and thus verifiable (with min/max dimensions, heel, toe, side settings etc.) Kicad footprint generator shouldn’t be that difficult, but would avoid a lot of work in checking footprints.
But again, I’m not a skilled programmer :grin:

47

Re padstack and object oriented approaches to generating footprints. See MadParts on Github. IMHO it is a step in the right direction. Currently it does not emphasize inheriting pads (padstacks?), but I think that could be fixed. Then you could define a part and generate either IPC compliant or manufacturer compliant footprints just by inheriting a different pad. Similarly for the keepout area, you could inherit either a IPC or KiCad convention keepout just by inheriting a different algorithm for generating the keepout.

Re IPC naming conventions. It is a bad idea to require a name to encode the attributes of the part, but people do it because there is not a good alternative. An object oriented approach would help here also. Knowing the input attributes of the footprint, MadParts could generate both IPC names and KiCad convention names. (The file would be named one way, but the other names would be attributes.) The use case is that the user knows (or guesses) the name they want and needs to search for the footprint.

KiCad could let you filter by more attributes than just the pin count, such as “isPadsIPCStandard”. The “truth” whether pads are IPC standard would be in one place, the MadParts code that generates the pads.

48

Inheriting pads is not quite what I call PadStacks.

Inheriting pads has not really been used since PCAD days, and it is quite dangerous, as the change in one place ripples out to many parts, and not all parts should have the exact same rules.
To be safe, you generate a large number of these Inheritance entities, and you cannot easily modify a single footprint, without adding a means to spawn more unique copies…

It sort of made sense way,way back in Gerber Photo-Wheel days, when you had a very small number of apertures and needed to manage those carefully. These days, it is just a PITA.

A PADSTACK to me is literally a Stack of Pads, where you can define separate shapes/sizes on Top & Bottom and also on Mask and Paste layers.

ie not be limited to a simple over-under size, users should be able to define Copper larger than mask for adhesion/cooling reasons, and paste smaller than mask, for paste-volume control.
Also, Paste in Via should be possible.

KiCad is quite close to supporting this now -
PcbNew can import and save PadStacks (Unique shape on every layer), but it has a couple of bugs & issues in other areas this uncovers

From memory,

  • Still cannot define Inner Layer Stacks, but you can sort of do this on the Drill Stack, assuming the inner layer is going to be smaller than outer layers.
  • Pour Flood does not quite manage thermal spokes of SAME NET pads right
  • DRC Connect check has a bug on PAD-Thermal-Outline-Connect check, that magnifies the issue above.
    (as well as cause false connect messages even on non-stack designs)
  • Paste in via is not yet supported.

No ‘brick-walls’, but a number of (minor?) fixes needed.

49

PCB_Wiz: Inheriting pads has not really been used since PCAD days, and it is quite dangerous

Yes it is powerful. But I am not suggesting it be done in PCBNew, only in MadParts, which is a footprint generator. The inheritance stops at MadParts. Sure, if you incorrectly change an inherited pad, and use MadParts to regenerate a library of footprints, any PCB designs you subsequently create using the library will have the incorrect pads.

OTH, if say the IPC-standard for a pad changes, inherited pad definitions helps you. You update the pad definition and use MadParts to generate a new library that conforms to the new standard. Yes, you must make sure to use the correct library. Now the footprint libraries have versions, just like the standard does.

Another use case: you want all your pads to be hand-solderable. In MadParts you could copy the definition for a footprint (say QFN-16) and change the inherited pad from “IPC-standard QFN pad” to “handsolderable QFN pad” (in one line of the definition), and generate a new footprint.

Or maybe in MadParts you could specify the set of pad definitions (say the “hand solderable set”) to be used to generate an entire library. In other words, from a set of footprint definitions, you could generate both production footprints and hand-solderable footprints.

Moreover, you could inherit not Pads, but “ContactPatch”. A part has contact patches between a leg and the PCB. (For no-lead parts like QFN, its not a leg.) You could describe the part, not the footprint, and MadParts could generate the footprint. In other words, you change the interface at which standards are defined from the footprint to the part. (I don’t know whether the actual standards are defined for the footprints or for the part contacts.)

I am not a pro, I might be using the wrong terminology. These nebulous ideas have probably already been thought of and rejected as having too many pitfalls.

We’re hijacking the thread, we should start a new thread about “footprint generators”. I think there exist more than MadParts, but they aren’t open source and the part manufacturers provide part definitions for the other, non-open footprint generator?

50

Hi Mars_Warrior,

Thank you for your input. Here are some comments on the mentioned rules.

  • KLC 10.4: Indeed, IPC states refdes on the fab layer and not value.
  • KLC 6.5: In a few cases we are using density level A. Rule 6.5, 0.15mm silkscreen width is one such case.
  • KLC 6.6: As for the round-off, it comes from 7351B which is 0.05mm.
  • KLC 6.9: We chose the least density level for the silkscreen refdes and later on we just added the one on the fab layer, using the same rule for it. Accepting up to 2mm as long as it is inside the courtyard could make sense.

All in all, I do think applying the latest IPC-7351C would be the logical choice!

Carl

51

Ah, OK, that makes more sense…

Right, here inherited pad definitions applies more in the software sense, than to the block or graphical inheritance seen in PCAD.

I would agree a combination of Rules Driven Wizards and Scripts are a good way to generate and check footprints, especially where there are many levels of relatively tedious rules to apply.
That’s just not human-operator-compatible…

52

Hi Mars Warrior,

Can I get a link to the full document from which you have taken these screen shots.

Thanks.

53

I didn’t understood these M, N, L exactly.

is this like N is for default use and M is for hand soldering application?

54

KLC 10.4: Indeed, IPC states refdes on the fab layer and not value.

Should the component value be moved to the SilkScreen layer? There is already the functionality to explicitly NOT plot the component values when generating gerber outputs, so having them on the silkscreen means that users can print them to the gerbers if they want, or simply un-check the box in the plot options if they don’t want them there.

With the current library config (value on fabrication layer) there is no way of plotting the values to the silkscreen (if that is something you wanted to do).

However this would mean that the silkscreen layer could get pretty crowded in pcbnew…? I’m not sure where the best place for the value is, wrt KLC 10.4

55

In these small smd times there is no way that silkscreened values will work, squeezing references in is a real challenge.
In the throughhole days, most companies did not want their customers to see values on the pcb anyway

56

I would tend to agree - I have never printed a PCB with values on the silkscreen. If this option were pursued it should be ‘disabled’ by default. What if the value is on the silkscreen layer but set to invisible?

57

I have seen values on the silkscreen in a CD player, but the most common use is on pcbs supplied in electronics kits

58

That’s how PCB Library Expert does it: it stores component package data, not the footprint data.