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