It is a little setup, but well worth it.
1 Like
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.
Really, guys, try to use database libraries!
Well, this is my penny to the discussion.
1 Like
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.
1 Like
@JohnRob et al…
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…
2 Likes
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.
easy!
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
1 Like
In the last month, I’ve installed the gplm-parts database system (thanks, @ Cliff_Brake) and converted my personal library to it. First off, thank you! The install, readme and videos made it trivial to install and understand, even on a Mac instead of Linux.
My take-aways are
- for a 1-person shop, this is an interesting integrated inventory/BOM integration solution, and I will continue to use and play with it.
- From a larger KiCad workflow perspective, there is inadequate separation of responsibility between schematic design, PCB layout and BOM management that is exacerbated by the overloading of Symbol and Footprints with supplier and inventory choices - the explosion of symbols in the schematic component picker is unwieldy and the pervasive ties into dynamic supply chain details unwanted.
In the physical world,
- Symbols have a 1:many relationship with Footprints: a “R” can be PTH or SMD, each in many variations and sizes.
- Due to stylistic differences (US-vs-world?), there may be multiple symbols for the same item, so this could also be seen as a many:many relationship
- Footprints have a 1:many relationship with symbols: SOT-23 is used by many different Diodes, Transistors, etc
- A Symbol+Footprint has a 1:many relationship to components: think of all those 0603 resistor choices…
- Supplier Part Numbers (sourcing) have 1:1 or even many:1 relationships with a specific Component (think alternate suppliers)
- KiCad user part numbers (aka my local inventory) may have a 1:1 or a 1:many relationship with supplier part numbers.
- … one can go deeper in several more dimensions if desired…
In the KiCad world,
- While there are mechanisms to manually manage segments of this supply chain - BOM tools, footprint filters, attributes and table-oriented schema and PCB bulk editors, these mechanisms are largely unpopulated and left to the user to discover, populate and work into a custom workflow.
- This entire chain of dynamic relationships is collapsed into a combinatorial explosion of symbols that get hardcoded into eeschema circuit design files.
Why is this frustrating?
- At design time, I should only need to specify relevant design requirements - values, capabilities, behaviors, tolerances, wattage, voltage.
- Once I have my circuit design complete, I can move on to PCB layout. There I should focus on physical constraints, such as power handling and cooling, connector layout and part footprint selection.
- Once I have a complete design (validated schematic and PCB layout), I need to focus on inventory and supplier management. Costs, availability, lead times, etc.
KiCad’s web / DBC parts management design point seems to presume that I want to (or can) specify everything at schematic symbol placement time:
Place a 10k 100mW 1% 0602 wave solder style thick film FRC series resistor made by FOJAN P/N FRC0603J103TS from LCSC with an LCSC stock number C2930027 from my inventory IPN RES-0022-0103
This completely falls apart when I need to place a second order for that product, and need to source different LCSC part numbers. My schematic is now WRONG, because it over-specified the symbol details.
2 Likes
KiCad doesn’t have an opinion on this actually; it’s just one possible workflow.
The solution I recommend to this, which is the one most commonly used in industry, is to keep some separation between design BOM and ordering BOM, for example through some kind of PLM system.
At its heart, what a system like this needs to do is provide arbitrary internal part numbers, and a list of approved manufacturer part numbers for each internal part number (this is commonly called an AVL; approved vendor list)
Your KiCad design would then only refer to internal part numbers and their properties:
Place a 10k 100mW 1% 0602 wave solder style thick film FRC series resistor with inventory IPN RES-0022-0103
And then your PLM system would know
IPN RES-0022-0103 can be ordered as FOJAN P/N FRC0603J103TS from LCSC with an LCSC stock number C2930027
As well as any other alternates you add, without any need to change your KiCad design.
While I don’t claim that your approach here is “wrong”, I will note that it is not the only approach, and not the one I personally use / have seen used at the places I have worked. You can also do these two steps together: be thinking about the PCB layout during the schematic design. Maybe this approach is uncommon at very large / legacy companies where there is a separation between “schematic designer” and “pcb layout designer”, but at every place I have worked, these two tasks are done by the same people, and so people are already thinking about the PCB at the time they are drawing a schematic. Sometimes this means that you make an initial guess about what will be an appropriate footprint/package for a part and then go back and change it later, but in my experience you can make correct initial guesses at schematic time most of the time.
3 Likes
I have worked with similar workflows, but it is clear that there cannot be a one size fits all solution to this.
The best that KiCad can do is to permit as many as possible of the various methods
1 Like
At our company, we even have an engineer who starts with the PCB layout first, keeping the schematic entirely in his head. Only after completing the PCB does he draw out the schematic. (I know—it sounded unbelievable to me too, until I saw countless ERC errors tied to a flawlessly functioning PCB.)
The point is, just because a particular workflow suits you perfectly, the person next to you might have a completely different approach.
KiCad aims to accommodate as many workflows as possible while maintaining usability for everyone. It’s an enormous challenge! So, don’t be upset if the software isn’t 100% tailored to your specific workflow.
You make very good points.
Libraries and BOM generation needs to be very well thought out, error free and have some flexibility.
A Part can have one Symbol, and many different Footprints, and many different Manufacturers, and many Vendors, many different Specifications (tempco, ppm, % tolerance, frequency, voltage, temp specs, ampere, watts, vendor hyperlinks, etc), and can be either Source Controlled or Specification Controlled. SMD, PTH, placement method needs to be included and searchable.
All this needs to be contained somewhere.
Ki should not make assumptions or impose limitations nor leave out relevant database placeholder.
This information may well end up on a spreadsheet.
I agree… I think. You may not be saying this but I would not want raw device specifications to be in Ki. We found it difficult to document and control a vendor specification sheet, where you are ordering the vendor part number. Adding detailed info in “yet another place” is nearly impossible to control.
1 Like
A simple example would be a resistor, visible on schematic would be designator and resistance.
Other stuff like size, power rating, tolerance should be on a different layer.
This would be a Spec Control part, which could have 20 different manufacturers and even more vendors.
The other example would be a Source Controlled part, say an operational amplifier where the base part number is the “value”, and other variables goes on a different (documentation-) layer, like footprint, quality grade, possible substitutes (if any).
This is not to burden the schematic with too much info, but have it available for BOM export.
A fully hyperlinked BOM makes quoting fast and easy.
A “Part” ( or “Device”) can have different “Symbols” , U.S. conventions and the rest of the planet differ, like resistors, ceramic capacitors, electrolytic capacitors, ferrite beads, BJTs, MOSFETs, logic ICs, ground symbols and others.
A “Part” should have the option of changing symbol, IF the pin names and quantity remain the same.
A “Part” (or “Device”) should/could also have multiple “Footprints”, for different “Packages”.
Changing a Symbol, a Package or a Footprint should not break the design.