Warn/Error if footprint has more than enough pads

[Philipp Legrum]

Using KiCad in the class room we stumbled over the following problem:

If you assign a footprint with pads that cannot be mapped to nets in the schematic --usually a (wrong) footprint with too many pads--, pcbnew will read in the netlist just fine. No warning, no error.

This makes an important error class slip unnoticed.

Is there a situation where a pcb-designer intentionally wants to do this?

The dual case, where there is too few pads, results in an error.

Encountered in version 5.0.1, still present in
version: 6.0.0-rc1-dev-1407-ga8d76d218-dirty

I've written a patch that issues warnings for that situation. We'd be happy if future versions of KiCad could at least warn -- if not error out.

Let me know about issues.

Thanks.

[eelik (eelik)]

In my opinion warning would be enough. It's possible to create quickly a symbol which has only the needed pins even though the physical component has more. I don't recommend that to anyone, but I would expect that to be possible in the future, too.

[jean-pierre charras (jp-charras)]

Footprints having more pads than symbol pins is a very frequent case.

Many op amps, regulators, transistors, relays ... use standard packages (like so8, dip8, dip14 ...) having more pads than pin symbols.

[Philipp Legrum (philulm)]

I played around with multi-unit parts leaving some units unincarnated. The patch I attached creates warnings then (which I find unseful). Maybe the "Wrong footprint?" in the warning is misleading in this case.

As far as I understand the semantics of KiCAD now, excess pads are **implicitly** unconnected.

If this is a desired feature, pcbnew can do little about it at the stage of reading in the netlist other than warn at the price of annoying users who heavily rely on that implicity.

The best approach is to encourage the user/library part provider to give KiCAD explicit info about every pad. (Pins of parts can be hidden, can't they? Isn't that the right way to go with excess pads?)

Conceptually, every part should be able to have a **list** of suitable footprints (coming from the parts library), rather than just a single optional default footprint. Then, pcbnew or even eeschema could warn that the selected footprint is not in the list of suitable footprints of that part. Is something like that beeing planned?

[Rene Poeschl (poeschlr)]

There is another use-case unaccounted for. There are parts out there that have a lot of "do not connect" leads. With your stricter requirement such a part would need to add a lot of NC pins to the symbol.
There are some parts out there where you have more NC pins than normal pins (NE555 in a qfn package comes to mind.) It does not really make sense to add all these unused pins to the symbol. (Really we looked into this a lot more than i care to admit.)

Regarding the list of suitable footprints: This already exists. It is called the footprint filter.
Take a look at my "how to make a symbol" tutorial over at the forum. And the "how to assign footprints to symbols" tutorial.
 - https://forum.kicad.info/t/tutorial-how-to-make-a-symbol/13336
 - https://forum.kicad.info/t/how-can-i-assign-a-footprint-to-a-symbol/8901

The kicad library convention might also be a good read. We have quite strict rules about footprint names to allow your "assign alternative footprints" behavior easily (example for adding a thermal vias variant or a handsolder variant). And by extension we also have strict rules for the footprint filters. (ensures they are designed in a manner that makes use of the footprint naming convention.)
http://kicad-pcb.org/libraries/klc/

---

By the way: I am really not a fan of having generic symbols in a library. If a part comes in SOIC and DIP then it has to have two distinct symbols in the lib. Each named with the correct part number and with the correct footprint assigned. (We call this a fully specified symbol.)

The official lib permits generic symbols only in a few libraries. These are the Device lib and Connector libs. All other libs must contain fully specified symbols. (Sadly the logic series libs violate this rule right now. These libs are in a bad state in general. Meaning they really need extensive rework to fit our current standards.)

[Seth Hillbrand (sethh)]

It seems that the consensus is that there are many cases in which an experienced designer does want this. Novice/classroom specific checks can be implemented using the scripting interface to ensure the designs meet local standards.

[Philipp Legrum (philulm)]

Just because we stumbled over a problem in the classroom it does not mean it is a novice/classroom specific issue -- quite the contrary.

Renee Poeschls NE555 example is a perfect reason to have a warning: Taking 555 symbols with 8 pins and assigning a qfn package with 20 pads to it, I figure that KiCad connects the 8 pins of the symbol to pads 1-8 of the footprint leaving 9-20 unconnected. This is definitely wrong and no usecase where an excess number of pads would be acceptable -- let alone handled correctly by KiCad. KiCad cannot handle excess pads correctly. It handles them implicitly by not connecting them, which may or may not be what the user wants.

Fully specified symbols are definitely welcome because a user can do little wrong. The associated footprint shouldn't be changable in eeschema for those, though.

I kindly ask you to reconsider accepting the patch and reopen the bug. While the patch is no perfect answer to all of KiCad's pin-pad assignment issues, it might save somebody's tears in the future.

---

It is a (more or less basic) design decision if KiCad is supposed to handle generic symbols with a variety of footprints. For that, the symbol library needs to provide explicit pin mapping. Eagle symbol libraries, for example, have an explicit list of good footprints for each symbol -- super convenient from a users perspective. For every good footprint in that list there is an explicit pin-pad mapping.

If KiCad wants to follow the "fully specified symbol"-approach (which may be perfectly fine for users) a pin-pad number mismatch must be considered erratic because KiCad only knows the identity mapping.