Why are the Kicad Library conventions non-IPC compliant?

Layout
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.

59

Including values on a silkscreen layer removes a lot of flexibility for a manufactured product. It’s not unusual for component values to get adjusted in the final stages of design optimization, or even after initial production release. Having the values on the silkscreen layer forces a revision to the board in response to every minor tweak, and possibly discarding dozens (or hundreds or thousands) of boards already procured.

Dale

60

Because it is sometimes useful, it sounds like it should be a plot-time option, rather than embedded in the footprint layering.

Other PCB pgms allow you to build a ‘merged plot’, of selected items, from selected layers.

1 Like
61

I would have thought the place to put value is on a fabrication layer in the component courtyard. The value is there for the assembler or QA inspector