Relating pins and pads [KiCAD pitfalls for newcomers]

I’m fairly new to KiCad, coming from Eagle, and I’m not sure I understand the process of connecting symbols and footprints. In Eagle, the process is very simple, straightforward, and, for the most part, not very error prone. In my first KiCad project I ended up with a 3-pin voltage regulator wired wrong because the symbol pins didn’t match the footprint pins.

I’m using an MCP1754 in the SOT-23 package.

The following are a set of packages that this part has:

The symbol has the Vin pin labled with a 1, and the Vout pin labeled with a 3. This is correct for the SOT-89 package, but not for the SOT-23 package.

In Eagle, you assign symbol pins names, and link those to pad numbers for the different footprints when you create a device. It appears to me in KiCad that there is some sort of assignment of pad numbers in the symbol. How do you then deal with different packages that have different pad numberings?

Did I miss a step when I should have assigned symbol pins to footprint pads?

I made this mistake with my first board, made with Orcad; many years ago…

You must be sure to match the pin number of the symbol (schematic) with the pin number of the footprint (layout). That’s all.

Whether you do that changing the pin numbers of the symbol or of the footprint, kicad doesn’t worry.

1 Like

Currently in kicad you need one symbol per package in such a case. (for the 8 lead package you should also include the nc pins in the symbol.)
In the official library we require the package name to be given in the symbol name for such cases. (At least we do now. There is a chance that old symbols do not follow this rule. There is also a chance that the library maintainers make a mistake.)
See the symbol variants section in the library FAQ for more details. (On how we handle it now in the official library. For your personal lib you can do what you want.)

Why have pad numbers at all in the symbol? You’re pretending that symbol and footprints are separate, but then you’re mixing them together by pre-assigning pad numbers in your symbols.

1 Like

Because there is no entity that links symbols to footprints. This information needs to exist somewhere.

Or you remove pad numbers from the symbols and make them truly generic, and force the association between symbol pins and footprint pads when you select the footprint.

This is a forum where users help other users.

We try to help telling people how the program works. Kicad way to link a component pin to a footprint pad is using pin/pad numbers.


The new symbol file format is currently under development. I think the new format might be a bit more powerful than the current format. But it will be some time until this format is available for users. (The next release will not include the new file format. Which means the new format is at least two to three years away.)

Currently there is no way to connect a footprint pad to a symbol pin other than both having the same pin number. Which means what you want does not exist (yet).

Also as @pedro already stated this is a user forum. Only a handful of developers visit regularly. If you want to get in touch with the developers you need to do that via the bugtracker.

I think what you want could be considered a feature request. Something like that is normally done by filing a bug and marking it as wishlist.
Just a heads up:
Pure wishes, without support by a Dev or a patch ready to go into the KiCAD code have a very small chance of ever being implemented.

Sorry & good luck.

1 Like

I think it is harder to program all the system than spending some time learning kicad.

If the linking component-footprint is made by the pin name instead of the pin number, the problem will endure.

SOT-23 can be Vin-Vout-GND, but also Gate-Source-Drain, Cathode-anode-nonconnceted…

I always say to new users “don’t try to make kicad your old CAD program, learn another way to do things”.


Probably… LOL.

Taking a look at the DataSheet for your “base part-number” there are seven different “packages”, and each package has a different signal applied to the separate pins.

On the SOT-23A package, pin 1 is GND.
On the SOT-89 package, pin 1 is Vin.

KiCad simply doesn’t have the database for all of these specific part number combinations.

To correct your issue, once you have chosen a specific part number (and thus assigned the footprint that goes with the symbol), refer to the DataSheet and verify that the signals match the pin numbers on the symbol.

You can always save this as an “atomic part” in your local library, and never have to worry about this issue again for that specific part number.

Very good advice.


Succinct and to the point. And, if that old CAD program was everything you wanted it to be, you wouldn’t have switched to KiCAD.


I’m not trying to make KiCAD Eagle. I’m trying to understand the rational how KiCAD works the way it does so that I can avoid errors in the future and be as efficient as possible.

It can also be beneficial to look at the way other programs work to understand the pros and cons of an approach. Eagle is not perfect, but even as a novice I was never led down a path where I had an inconsistent part. I may end up with the wrong footprint, but there was no way to think you’re connecting to Vin, when you’re actually connecting to Vout.

.[quote=“pedro, post:9, topic:6186”]
If the linking component-footprint is made by the pin name instead of the pin number, the problem will endure.

That’s why someone (the part developer or the end user) needs to go through the process of assigning Vin to a pin or set of pins and Vout to a pin or set of pins, etc for a particular package. I think the root of the problem is that the symbol that I used was designed for a different package than what I chose. I, as a novice didn’t know that was possible. In the future I will be more careful, but making it more explicit would not be a bad thing.

1 Like

I could name at least a dozen things that are better than my previous CAD program, but that doesn’t mean the KiCAD is perfect, and I think my old CAD program dealt with the intricacies of integrating symbols and parts much better.

Thank you for the help. I think I understand the rational behind the KiCAD model better now. We could continue to discuss “other” ways of linking symbols and footprints, but I’m not sure that’s necessary.

Brian, kicad lets you make your own library with symbol-footprint pairs, what people call atomic parts.

In every schematic symbol there is a field “footprint”. Fill in this field with the footprint chosen and save it to your own library.
This way, the pairing symbol-footprint is made only once for that specific part.

I like cvpcb, but many people here hates it and they never use it. This flexibility sometimes makes the learning curve longer.

1 Like

Thanks. I’ll do that, but I have to name the part differently, right? Last night I tried doing that just to allow me to switch the pin numbers on the symbol, and every time that part was referenced, it went back to the standard library, even after I deleted it and re-added it directly from my local library. Not a big deal, but a bit annoying.

I don’t so much dislike cvpcb. I just think it’s a huge duplication of effort for all the end-users to be going through the process of selecting the footprint for a part that has a defined footprint. That assignment could easily have been made once at part creation time. Whoever created the symbol probably created a footprint for it or verified that one of the standard footprints was appropriate. Why not save that association?

Never mind the fact that not all SOT-23-5’s (or whatever) are the same, so you really should check the exact footprint dimensions for every part-footprint assignment when you make it. And then there are those parts that have odd footprints that you have to create specifically for that part.

I can understand disassociating symbols from footprints with the basic components, but with more complex components I’m not sure I see a real benefit, especially when you embed some aspect of a footprint pad assignment in the symbol that might or might not be correct depending on what footprint you choose.

In the schematic, kicad takes the first instance of a component found in all the libraries added to the project. I mean, if there is a component called Qnpn in two different libraries, kicad fetchs the first one it meets. This behaviour has led to suicide more than one :slight_smile:

1 Like

Yes and no.
I have made schematics without choosing the final parts. Sometimes we make a first prototype with through-hole components and afterwards a second one with smd components. The schematic is the same for both.

That works to a point for very simple parts, but not for more complex parts.

Even with a simple MOSFET, you probably want to identify a specific MOSFET at some point before your schematic is complete. Maybe at first, you select a generic MOSFET, but ultimately you want a part number. At that point you’re limited to a finite set of footprints with which to chose from. Maybe that goes in your schematic, maybe that is associated with the board, but it should be somewhere.

And, back to my original problem. If you want your schematic to be generic, why do the symbols have pad numbers on them that are only valid for specific footprints? The symbol to pad assignments only make sense when you chose a specific part with a specific footprint.

If I choose a “generic” MOSFET with pins 1,2,3 for G,D,S, and then I pick a footprint/part that is 1,2,3 for D,G,S, I’m screwed, which is essentially what my original problem was.

You are missing the whole point. If you browse the “symbol” library “devices” you will find that there is NOT a single part number for any of the “devices” in that library.

Digkey has 130,883 different part numbers for resistors IN-STOCK; never mind the 480,398 total for part numbers in it’s database.

Exactly who at KiCad do you expect to provide this database to you for FREE?

Then, I don’t see any entry in the entire KiCad library entry for MCP1754; so I suspect that you edited the part number in Eeschema to reflect what you wanted the part number to be.

Page 3 of the Microchip DataSheet is very much in-line with the typical “symbols” in the “regul” library. Now, if you take the time to filter and search the library with the term “ka” the device KA378R05 should be the first one to show up. This IS AN ACTUAL “part” comprised of the correct symbol pin-out along with the correct footprint for that specific part number.

So, are you really trying to tell me that in “your other EDA software”, if a specific part number did not exist in the library, that you took no responsibility for creating it yourself and ensuring that the part numbers and footprints matched each other according to the manufactures DataSheet?

How do you think KiCad was able to be used by users when it was first created?.. When there were ZERO (or extremely minimal) libraries. Occam’s Razor suggests it was one of the developers that created the pins in that arrangement for the most common regulator that they used.

In the end here, you really do not have any valid complaint from my point of view. I’m a little surprised the forum members have been so nice. Because, I think that if you had RTFM you might not have got it wrong.

1 Like

KiCAD - and especially the libraries that ship with it - have had no connection what-so-ever between symbols and footprints (this is starting to change with some hints/pre-select choices now going in there).
On one hand that is a big pro with hobbyists, on the other hand, if you’re unaware can bite you in the a$$.

If you dislike that - as some of us around here do as well (see, you’re not alone) - then you have to create/maintain your own personal local libraries where symbols and footprints are pre-linked and vetted by yours truly.
Some around here call those atomic parts, as most then go the extra mile and also put in vendor information, part numbers, distributor numbers, order numbers, etc. pp. to make Bill-Of-Material creation and all sorts of other stuff way easier.
Just search for ‘atomic parts’ or what @Andy_P likes to call them from his other CAD tool… ‘integrated’ parts/library.

PS: welcome to KiCAD.


That’s how we roll. :heart_eyes:
Also, new users might not appreciate where KiCAD did come from (hell - I don’t know this really) and thus just see what it is now and make assumption, which when confronted with reality sometimes have surprising and upsetting outcomes.
Picking them up where they are and leading them to some sort of understanding of what they deal with could lead to us as a community getting lucky, as we might get a new Developer as he got some idea and talent and wants to see his quirk dealt with :nerd:
Alienating won’t help KiCAD in the long run. :innocent:

1 Like