I’ve been designing electronic products for many years. Looking back I don’t see how this would be any benefit at all.
As an electronic designer I choose a part, at the same time I choose the package, package material, the need for any cooling (whether thermal pads of physical heat sinks). When I’m done I had these and other design requirement to the PCB designer. Even if I am the PCB designer the same process applies.
If there were such a connection as you described, would call those footprints “standard” for a certain company for example.
If I (electrical) pick a package that isn’t “standard” then its up to me to justify the package I choose. Then the (PCB) person will use that package regardless of what is linked to that resistor, transistor etc.
Before easily attainable PCB programs were available we would use outside PCB design services. We would give them information for every part. Without exception, they would make a footprint for every part we specified. I asked why don’t they use “standard” footprints. The answer is: the footprints are so easy to make that the risk of a standard footprint not meeting our specifications was too high.
Add to all this the fact that component physical designs are changing so often one cannot easily keep up with these changes with such a database (aka link to standard footprints).
Organisation of the database can take many forms. The beauty of the KiCad database connection technology is that you can configure the backend to suit yourself. If you have the disk space for the database, nothing is stopping you from storing a symbol with all the variant footprings.
The next advance I think is when the schematic editor gets a stable extension language API which can also interact via the GUI, and several key points in the code, like choosing a symbol can be redirected to plugin code. Then people who want more elaborate symbol selection UIs can roll their own.
We are somewhat doing that using the KiCad Database feature – see this example:
In this case, ANA-0002 had two different variants, and two different packages. It turns on in this example, the symbol is different, but we could have cases where the same symbol is used with multiple footprints. Each one will have a different IPN, as they are different parts.
In every design I’ve worked on, the design engineer specifies the package, as there are thermal and other concerns. If there is an issue at layout or procurement, then the engineer collaborates with these people to change the part.
In the end, I want a different IPN for every part used, and I want these in a reusable database.
The database or HTTP connection really gives you a lot of flexibility to do whatever you want.
Let me know how it goes. The current gitplm app is a little out of date (note, the app repo is different than the parts repo) as it has not been updated to use the new KiCad database CSV format, where each category is in a separate CSV file, but with the KiCad database stuff, there is less need for the gitplm app. So at this point, the gitplm app is only really needed to put together BOMs for multi-level projects, and run release scripts. We’ve done some neat stuff lately with kicad-cli to completely automate the release process for PCB in KiCad.
Hopefully, I can get this all updated soon, but the parts repo should be very usable now – we’re using it on several different projects.
Using a different Symbol for every footprint variation is balky, clumsy, st…
Other programs have solved this in a better way using a “Device”, or “Component” hierarchy level, with one Symbol, and as many footprints as you like, reflecting the reality that silicon dies can have many different packages.
This is a higher priority than 3D rendering, that bloats libs, and have little usefulness, unless very cramped injection-molded package integrations are used, which is unlikely in the KiCAD space.
A “Device” should have one “Symbol”, then different Footprints are connected in a separate screen according to the datasheet.
This makes it easier to switch to another package without ripping up schematic.
Unused pins can of course be left unconnected.
Ground and thermal vias can be conveniently included in center pads.
I don’t think I ever used a stock library symbol or footprint. Stock symbols are usually too large, not descriptive, not reflecting physical chip layout that is needed for RF.
There is no standard for every package that you can trust. Small variations for RF parts can be detrimental. Data sheets have to be studied for every part.
Footprints also need to consider SMT processes and stencil cleaning, for which corners needs to be given a radius. No reason to ever have sharp corners on pads. Take a look at a stencil pasted board.
Please point me to the authoritative user survey you apparently have done, or to some other reliable source which proves this isn’t just your opinion. Meanwhile I reserve the right to put you in the same locker with many others who claim they know how an EDA program should have been made.
I would not do anything for some dude on the net with a smug attitude, and that seems to be convinced his baby is the greatest
YOU show me the authoritative survey that KiCad blows the doors off every EDA package on the market.
KiCAD has changed a lot over the years, because it was originally perfect?
Get a grip.
Altium is so worried now.
Please stay a bit polite towards each other here
(Gosh, I’d ever thought that I would write that here )
I had a short look at **/usr/share/kicad/symbols/MCU_Microchip_ATmega.kicad_sym for the ATmega328, same example as the screenshots before, and it’s definition is quite short. It starts with:
And the whole definition is just 7 of those “properties”.
Also, as an Open Source project, KiCad grows in little increments. Where KiCad came from long ago, it’s library system was perfectly adequate, and now 30 years later, it’s seams are getting tight. I like the idea of the database driven libraries, and those can also work perfectly together wit partial blocks of data such as loose footprints. I mostly see the hobby and forum sides of KiCad and have not used these database driven libraries at all. But from the little I know this should work quite nicely with integration for already implemented databases that companies have built up during the their time “before KiCad”. And I think it’s a good division. Hobbyists have a nice assortment of simple parts they can easily modify and make to fit into their projects, and companies can re-use their in-house databases that have been built up over many years.
A few weeks ago I installed the AKL (Alternate KiCad Library) and it doubles the amount of available symbols in KiCad.
is 921KiB and it has 879 different diode bridges in it. That is >>> 921*1024/879 = 1072 characters per symbol, which seems pretty compact, considering KiCad’s “verbose” use of S-Expressions. (For the curious, it’s just 21KiB when zipped. 16KiB with .7z.) And there is a lot of graphics re-use. I guess there are just 8 different graphic symbols, one for each pin combination.
And overall, I also do not care much what the size of those libraries is. The time and effort for maintenance is much more important, and graphics reuse helps a lot here too.
I also very much appreciate the ease of use of the “simple” / generic symbols for resistors and capacitors. You just grab some resistors and capacitors to quickly put down an idea on a schematic, type in some values, If you have models for the IC’s you can make some simulations, and when you want to go though with a PCB, you can add footprint data later. I see this as one of the core strengths of KiCad.
I am trying but I’m having difficulty in understanding what the actual problem is that supposed to be addressed in this thread. Going back to the original post:
But KiCad does support this via the keywords in the footprints. If you use the Footprint Assignment Tool, and filter for the Keywords, then you get only resistor footprints when assinging a footprint to a resistor.
OP complains there is bot a US and an EU resistor symbol in KiCad’s libraries, but he also wants reflow, wave and hand solder variants for footprints. (Those can also be easily swapped with Schematic Editor / Tools / Update Symbol Library Links
@JohnP Have you ever used the Footprint Assignment Tool and filtered for Keywords? Is this close to what you want?
So I’m still not sure what the actual problem is. I suspect that you mostly used one way of combining symbols with footprints, and are unaware of the other options that are also supported by KiCad. It is possible (plausible) that these footprint filters do not work good enough in some cases, but that is probably due to some errors or omissions in KiCad’s libraries. Nothing except Leeloo is perfect on this mudball.
I have a large library constructed over the last 30 or so years of use with several different CAD/layout programs. As many here have said, in one form or another, “I don’t trust a symbol / footprint that I haven’t personally validated” - because I’ve been burnt too many times.
@JohnP (me) wrote:
kicad doesn’t support the concept of symbols that are associated with a set of footprints.
@paulvdh writes
But KiCad does support this via the keywords in the footprints.
@craftyjon writes:
As noted, right now the only requirement is that the pins all have matching names with the pads.
I understand the “use a resistor footprint filter for the R symbol”, or even “provide a list of specifics…”. Cumbersome, but workable, I guess. Until someone adds a footprint that matches an existing filter or worse, doesn’t, or the filters pick out unobtanium combinations or ones with pin quantity/name mismatches. BTW, dandruff components are easy and not worth the trouble… the complex ones are the ones that matter to me.
@JohnRob wrote:
We would give them information for every part. Without exception, they would make a footprint for every part we specified
And what happens when you mistakenly give them the wrong information - say misreading a datasheet and specifying a TSSOP package that isn’t actually manufactured for that device? Yeah, making footprints is easy, that’s not the point: I want to make it easy to use correct, in-production footprints that are known to work!
As an example, I’ll use the ATmega called out earlier in this thread. KiCad has what? Three or more slightly different symbols, filters for two or three footprints and a bunch of trial and error sleuthing just to address a subset of the Atmel ATmegaAVR product offerings.
What I want (and looks to be potentially do-able with some scripting and sql using git-plm) is to create VALIDATED PACKAGES.
Each PACKAGE would associate a SYMBOL with a set of FOOTPRINTS, the PIN MAPPINGS that match the data sheet(s) from a vendor and a list of all the available component VALUEs. Why? So that, when I use this product in my design, I don’t have to guess about footprints, manufacturing part numbers and ordering info - the reasons I built my own personal library in the first place.
The workflow I want is
Create my validated Library of PACKAGES
Add a Package’s SYMBOL from that Library to the schematic.
ATmega megaAVR
Choose a Package VALUE for the device.
ATmega328P
Choose a Package FOOTPRINT - possibly deferred until I get to the PCB stage…
28P3 - 28-lead SPDIP
See the resulting Part Number in the PartsList, BOM… ATmega328P-PN
Peace,
John
Example:
PRODUCT:
ATmega megaAVR
Acceptable VALUES for each of the available devices:
Not possible AFAICT today in KiCad
The ATmega48A/PA/88A/PA/168A/PA/328/P differ only in memory sizes, boot loader support, and interrupt vector sizes. The table below summarizes the different memory and interrupt vector sizes for the devices.
Table Memory Size Summary
Device
Flash
EEPROM
RAM
Interrupt Vector Size
ATmega48A
4KBytes
256Bytes
512Bytes
1 instruction word/vector
ATmega48PA
4KBytes
256Bytes
512Bytes
1 instruction word/vector
ATmega88A
8KBytes
512Bytes
1KBytes
1 instruction word/vector
ATmega88PA
8KBytes
512Bytes
1KBytes
1 instruction word/vector
ATmega168A
16KBytes
512Bytes
1KBytes
2 instruction words/vector
ATmega168PA
16KBytes
512Bytes
1KBytes
2 instruction words/vector
ATmega328
32KBytes
1KBytes
2KBytes
2 instruction words/vector
ATmega328P
32KBytes
1KBytes
2KBytes
2 instruction words/vector
SYMBOL
a SYMBOL definition for an Atmel ATmega
PACKAGES for the 4 footprints the device is available in:
32A - 32-lead, (1.0 mm) Plastic Thin Quad Flat Package (TQFP)
28M1 - 28-pad, 4 x 4 x 1.0 body, Lead Pitch 0.45 mm Very Thin Plastic Quad Flat No-Lead (VQFN)
32M1-A - 32-pad, 5 x 5 x 1.0 body, Lead Pitch 0.50 mm Thin Plastic Quad Flat No-Lead (VQFN)
28P3 - 28-lead, 0.300” Wide, Skinny Plastic Dual Inline Package (SPDIP)
My company uses database libraries. We started several years ago with Altium, and it made library management an order of magnitude easier. We now have a small symbol library and a large footprint library. Making new parts that use existing symbols and (tested) footprints is a breeze. It has reduced our error rate due to bad footprints and BOM errors to almost zero.
When we started moving to KiCad, we added a couple fields to point to the KiCad symbol and footprint folders (since we duplicated everything for KiCad), and it worked, i.e. we have one single database library for both programs.
If I ever do this on my own, as a hobby or otherwise, I will go straight to a database library.
My company recently switched to database library (actually we are still migrating). However the benefits you mentioned have already been noticed. The time we spent designing, migrating to and populating the database is totally paid off.
Having a concise and robust component database for engineering team, that can be linked to others databases for commercial and factory usages is a incredible leverage.
We also do what Cliff_Brake posted above, indeed it’s really flexible to deploy.
My career was in new product design so except for the most basic parts many parts were new to us.
say misreading a datasheet and specifying a TSSOP package that isn’t actually manufactured for that device?
I created/defined a pretty robust checking methodology. Pretty basic, we only had a few errors for all the years I was there. Biggest issue were transformers.
With your suggestion it would still be easy to make a mistake and specify the wrong footprint. And I suggest you have a much larger chance of making a mistake. The sense of security that comes from using current production parts could be a detriment.
Companies often use a house numbering system, linking a symbol, footprint, stock and purchasing information. For this, a database is the best solution.
I don’t disagree with your perspectives and experiences as much as I’m trying to suggest that, like those personality-type grids, there are others out there that are just as valid.
Depending on your perspective, KiCad’s handling of components ranges from being intuitive to being an active impediment, passing through frustrating and awkward along the way. Stuffing components into a database is a work-around that can make managing a library a bit more tolerable, but it doesn’t address KiCad’s built-in design limitations and assumptions that IMO are at the root of this awkwardness:
There is no concept of a component - only a loose assortment of symbols, footprints, 3d models and the like.
The concept of “component value” is, in some places, hardcoded to a symbol, and in others, hardcoded to a footprint, and in others, left to the user, with no concept of validation.
There is no concept of logical to physical mapping - instead there is a pervasive reliance on footprint naming conventions, filters and hidden pin-count-magic
Addressing these “issues” is a non-trivial effort that won’t even get started if we don’t agree that they are issues in the first place…
Yes, there are issues, but when you keep on using that tone of voice you are more likely to get yourself ignored then any other reaction. For example:
No, it is absolutely not a “work around”. There are a lot of people for which the database connection is an essential part of their workflow. Without the database connection they would not even consider using KiCad. People like this often work in companies that already have a working database with some other EDA program. at least 4 people have mentioned the database system in this thread alone. If you keep on calling it a workaround, then the shame is on you.
If my understanding of your goal is correct then perhaps Kicad is not so far as you believe.
If you make a set of symbols, each with a specific footprint, then create a script to fill the parts selector with the footprint specified in the symbol you will have something very close to your requirements.
I’ve not delved into scripts in Kicad so I can’t comment on the ease of this approach but it could get you close if not the exact workflow you suggest.
Actually, I found an even better solution.
In your own (locked) library create:
A symbols folder for symbols (those that you have standardized footprints for).
A Footprints folder containing a <match_Symbol>.pretty subfolder containing all the options for the symbol you are using.
I have worked with ECAD linking to big databases that also link to stock and pricing information. KiCad is never going to intrude into that space. A database connector is the solution
)
