He described it as a collaborative process, however it was a PIA for the design engineer who likes to design circuits and / or mechanical components. Its a different mind set, when you are making millions of product the economics must make the product market viable.
Remember, the device must still work and be reasonably reliable, else the market will push it aside for another brand.
It’s a bit off-topic question, but seems like a few active Database users here.
Id’ like to ask if with the new Database approach to Parts inventory, KICAD supports an easy way to “pick” or “exchange” component?
Like for example, I’m using 1k 0603 resistor for R17, and would like to replace it with 2k2 0402. Is it getting as simple as selecting “Pick new part” and search the list of available items?
With the standard approach, it was quite cumbersome to the point that building personal library of “fully defined parts” was not a reasonable option to me.
So, what’s the paradigm now? Can we easily use “Parts” with the DB engine?
Here’s my old topic on that matter: Components "Superlibrary" - #26 by fred4u
I can find a GITLAB ticket that also touches this matter: KiCad Library Symbol Editor - "Value" is hard linked to "Symbol name" (#9389) · Issues · KiCad / KiCad Source Code / kicad · GitLab
Actually it would work quite well. I think it’s a misconception that the EDA database library has to be the single place where component data lives. In common usage this is not always the case. The database that provides the schematic symbols and metadata about the “ideal” part doesn’t have to be the same database that also provides information about what alternate parts are acceptable, their current cost, etc.
In my experience, we do not put information about cost, lead time, etc into the design database. Instead there is a separate manufacturing/production database (managed by different software) tracking these things.
In smaller organizations, the design engineers themselves can be responsible for maintaining the design database (not the manufacturing database). All you need is a workflow with some kind of review process – this review process can be distributed, you don’t need to run all changes through a “librarian” although I’ve seen that workflow too in larger places.
The manufacturing system handles this. The schematic always lists the original part, but in some database (like a PLM system) there is information that the new/cheaper part is a direct equivalent for the original part, and the purchasing team can then buy whatever approved parts are available at the cheapest price. You don’t have to go back and update your schematics etc when a cheaper part appears; you just update the PLM system.
This is the advantage to the approach that empowers all design engineers to add data to the design database – you have very little reason to use a suboptimal part just because the optimal one isn’t in the database yet.
You should just be able to use “Change Symbol” – does that not work?
Will need to check.
Previously it was not as easy – what I described in the thread quoted in my previous post.
In the 6.0 I currently use, “Change symbol” is an exhaustive dialog with multiple options (e.g. change multiple symbols at once, with different data update strategies).
“Pick new part” as a standard way of changing part’s definition (like the mentioned before change resistor’s value from 1k1 to 2k2) should be very easy and achieved with minimum number of steps.
The editor should just ask for a replacement item from the Database, and automatically update all the fields defined in Database (this way we can assure that the new part will be in sync with all the information like in-house ordering #, footprint etc.).
This is the change of paradigm between “standard Kicad” (where the symbols are not tightly coupled with other part’s details), to the one which is based on a finite list of physical parts fully defined in the database. This will make quick&easy change of the whole part a necessity (as it will become one of the most frequently used functions).
Yes, because it handles many different scenarios. However the scenario you describe should only require you to pick a new symbol from that dialog in one place. By default it will just update the item you have selected. There should already be a minimum number of steps for the thing you describe. There are also more options in that dialog for other things people might want to do.
It does not matter whether you are using a database library or not – the process is the same. You can choose whether to update everything about a symbol, or just update the fields for example.
All that defines this paradigm is how much information you store in your library. There is no real change in KiCad needed. The database library just makes it easier to store a lot of information and keep it updated (especially when you need to synchronize with other software) but you could technically do the same thing with a normal KiCad symbol library.
I’d only partially agree.
For some reason, the design choices coupled symbol’s name to the Value field, making the “Value” a key field. I’d prefer naming symbols after my “In-house inventory” name. So if the Symbol’s name and it’s value fields are separated now, it will make it easier to work with a fully defined parts library.
Then, there’s question of searching the library. Say I’d like to list 1206 resistors between 10k and 20k resistance, and then pick the one best suitable for a task. This could be (relatively easy) possible with the DB engine running in the back.
This is no longer the case in V7
It is not yet possible to do complex queries like this from within KiCad, however you can do it with an external tool to identify suitable part numbers. However, this is just an ease-of-use thing.
Great, does it mean I can use my otherwise hidden complex private P/N as a symbol “name”, and a simple data displayed directly on the schematic as the part’s value that’s used e.g. also for simulations?
One more question, is the extended part data (fields) linked in the Board editor somehow? Previously board editor did not have access to many part data (like for example 3rd party tools like Interactive BOM plugin).
It is/will be a natural part of the workflow. If an organization does work with a finite number of identifiable P/Ns, quick access to a filtered list seem almost a “must have”. Even if it can be done outside of KiCad, it will impact the efficiency of a work.
Yes
Custom fields are transferred to the PCB as footprint properties. These are not currently accessible from the PCB Editor GUI, but they can be accessed through scripting.
In closing…
In the environments I worked in alternate parts are not chosen by the mfg folks.
This is the advantage to the approach that empowers all design engineers to add data to the design database.
I look at such a procedure as more of a implemented than a positive. I my experience design engineers tend to “avoid” extra paperwork.
In closing, perhaps my experience with the different companies I’ve worked at is different. I don’t dislike a company preferred parts list. However if feel its implementation could easily become cumbersome and diversionary.
Just following up after my initial plea.
CraftyJon - thank you again. I haven’t had time to go back and check out your implementation, but from the comments alone it seems like you knocked this out of the park in its implementation and your understanding of the need.
To those that doubt its value - ignore it if you don’t think it is of value. If you only ever build one board, it probably isn’t of value. But without it, you will not be building on the time and effort of part selection in a way that you can use effectively on future board designs. This isn’t about corporate vs non-corporate, doing more paperwork, etc. It’s about marrying two tools (PCB design software and information management) in an effective way that makes the sum more than its parts.
Yes, building a parts database takes some effort. But not an insurmountable effort for even an individual - as I said, when I was one man shop, I built a parts database of several thousand parts in a few days, and for only 4-5 boards I designed from it, it was well worth the effort.
The management of such a database, how extensive it is, etc. is all up to the user. I was the librarian, designer, maintainer, etc. A larger corporate environment would most likely distribute the effort.
I will say that if you are just starting from scratch, start building with the perspective of long term use. Specific parts are added on an as needed basis. But for common parts, like resistors and caps, do some research, select a series that gets 90% of what you need done, and add the entire series. Downloading data from digikey made this easy when I did it. I used a lot of 0603 resistors, so I added the whole series of panasonic resistors that I wanted. Just copy all the primary information into the fields you want multiple times, then go back and edit part numbers, part values, etc that are different for each individual part. All those parts point to the same footprint, same data sheet, same schematic symbol, etc…
When I design, I then go and pick parts from the database that I already know. Once I’ve built a board I know that that footprint is good, so its good for future designs. I use the database to skinny down on part selection and start looking at the differences between parts that matter when I’m down to just a few - tolerance, etc…
I’m glad to see this capability come to KiCad. This tool is getting very competitive to some very expensive commercial software, and its great to see this core capability added.
Thank you again Jon.
I have one quick question. If one develops a design using a database library, will the resulting project be something that will be self-contained, i.e. the design components created from the database will be stored with the design. Specifically, can such a design then be sent to a third party and they can open and use the design without needing access to the database?
The development of the database is fantastic news, so many thanks to all involved. My employer is looking hard at KiCaD (as in transferring an existing design to KiCaD) to replace our present solution and this capability is the last known roadblock. I have been pushing for them to contribute financially, so if we make the move, I hope those seeds bear some fruit as well.
John
Yes. Like with non-database libraries, any components used in a design are copied into the design. You don’t need access to the database to open the design; only to update the components from changes in the database.
@Claudio.Lorini Hi Claudio, is it possible to share your testing database (or sql scripting file) and the KiCAD configure file? So, we can test the feather more easier.
@craftyjon Thank you for your effort on this feather. Suggestion: KiCAD could include a simple SQLite example, including the database file and the KiCAD configure file, just like the demo projects included in the package. Let the user do the ODBC bridge things with a tutorial in the documentation. This makes the new database feather more easier approaching.
Ciao,
sorry but it is not possible, it contains some “sensitive” information about our research projects.
(and, by the way, i’m still in the process of remapping the Symbols/footprints with KiCAD library
ones, which is a huge, painstakingly slow, boring and extremely dangerous task)
C.
if you look here:
you can find a very simple example prepared by craftyjon for code testing.
The DB is SQLite but the concept with MySQL or others remains the same.
Note that to run this example, you need to install a SQLite3 ODBC driver on your system. KiCad is not going to start automatically installing any ODBC drivers, which is why I’m not sure it’s a good idea to ship an example database next to the demo files (rather than just the QA database that Claudio linked to).
Thank you both of you. @Claudio.Lorini and @craftyjon
I’ve tested the feather with QA database that Claudio linked to. It’s really awesome!
We know that the OrCAD/Allegro and AD have the database support. I do not know whether KiCAD and OrCAD/Allegro (or AD) can share the same database? Maybe it is possible.
It’s certainly possible (I’ve tested it). You just have to add columns to your database for KiCad symbols and footprints.
With the “View->Symbol Library Browser”, we could see the elements from the associated database. However, we cannot put the selected element into the schematic. For other elements which are not from the associated database, they can be put into the schematic from the “Symbol Library Browser” dialog. There is no problem for the “Symbol Chooser” dialog.
