Problem with 7812 when trying to open netlist in Pcbnew

So I was using KiCad for the first time, created a schematic, netlist and then I get the following error when opening it up in Pcbnew:
Info: Checking netlist component footprint “U1:/570507FF:TO_SOT_Packages_THT:TO-220_Neutral123_Vertical”.
Adding new component “U1:/570507FF” footprint “TO_SOT_Packages_THT:TO-220_Neutral123_Vertical”.
Error: Component ‘U1’ pad ‘VO’ not found in footprint ‘TO_SOT_Packages_THT:TO-220_Neutral123_Vertical’
Error: Component ‘U1’ pad ‘GND’ not found in footprint ‘TO_SOT_Packages_THT:TO-220_Neutral123_Vertical’
Error: Component ‘U1’ pad ‘VI’ not found in footprint ‘TO_SOT_Packages_THT:TO-220_Neutral123_Vertical’
I searched online, but can’t wrap my head around this, this has really put me off. What is the single best course of action in this case?

Off the top of my head, I believe this was an issue with older versions of KiCad. There is a discrepancy beteren the pin numbers/names of the component in eeschema and the footprint in pcbnew. I would edit the component to have numerical pin numbers (they appear to be VI, VO and GND now) which would make them compatible with the footprint. Don’t forget to export the new netlist after making your changes!

I had the same issue and I’m new to KiCAD so I think it is a current library error. But your solution was what I did to fix the problem.

The regul.lib still has too much generic symbols for some “backward compatibility”. This is the reason for these issues.
Therefore, I suggest to use only those symbols that have full names according to the manufacturer encoding.

1 Like

I read somewhere that this will create problems with backward compatibility, and will have to be redone after every update of KiCad.

What is meant by that?

Anyway, is this going to fixed anytime soon in some future update of KiCad or its libraries?

There can’t be a 100% fix for this kind of error… man, even my personal libs & footprints (I and a lot of others here don’t use the public available ones but make our own) will have mistakes in them.

For example just 2 days ago… I made me a symbol for a voltage reference (device has 3 pins)… I started with a 5 pin symbol from an adjustable LDO that I just modified… renamed the pins, deleted the ones I didn’t need… saved, export netlist, import netlist… and there is an error… “can’t find pin #5 for Uxy, yadda yadda…”
Turned out I missed one number on a pin there… still had the ‘5’ and needed a ‘3’.

You stumble upon them and know what to do.
If it’s your first time, you’re confused, sure… but you will know what to do in future.

1 Like

Manufacturers part-number.

When you take a wider look at regul.lib (for example) you will find some symbols I’ve called “generic”: 7805, 7812. Easy to find because they doesn’t have a visible pin numbers. IMO they are less usable in designs, and should be removed soon.
On the other hand, when you dig more you will find other similar symbols like: LM7805ACT, LM7812ACT, MC78L05ACP which are complete and preferable to use as a component: has manufacturer name, has right pin numbers, has correct footprint (at least as a hint what to looking for), has datasheet link.

Few years ago when I started my KiCad journey generic symbols dominated, because such was the approach. Libraries have to be very - or even too much - universal. Today, this approach is also considered to be right, but this situation would not last so long, because KiCad is of interest to the (more or less) professionals. Thats why I started to commit non-universal symbols in those days.

Everything is at hand of current library maintainers. You can help in that using Git and commit changes (by forking and prepare pull requests).