Dear Kicad developer dear all,
I have noticed from several comments and treads that the time change in component library management is arrived. In the daily build I have already noticed changing in the “Choose Component” window.
I would like to give you my point about features that can bring Kicad a small step ahead professional ECAD .
Kicad is build around the idea that first you draw the schematic, after assign footprint and than you move into the PCBnew. Personally I really like this idea because it gives such as focus in what you need to take care step by step.
What is missing in my opinion in this path is the assignment of component parts ( I am referring on component Part Number and Manufacturer Name).
I think there would be very helpful a tool such ad “CvPCB” that allow the association between components and real Manufacturer Number and Part Number.
This is not the problem faced by hobbyist but when you are developing a PCB board with hundreds of component usually a small percentage are unique components but a huge percentage is made by components that needs to be equal to reduce manufacturing costs (I.E. resistors, capacitors …).
Somebody can say that you can associate those information (MFN and MPN) component by component once you add it or making a custom project library component.
Despite the fact that this would be very tedious task the huge problem will be when, for some reasons, you need to change from a specific manufacturer to another. In a board with hundreds of component this is impossible. You could use an external spreadsheet with a BOM to keep track on MFN and MPN but doing that you are disconnecting the schematic from the component part list and this can introduce problems once you need to update your pcb with for example a new component or layout.
I hope I gave you an idea of this feature lack in kicad and I hope this my topic will be at least discussed between Developers.
I agree with this. However, this would be quite an undertaking and would have to be database-driven (SQLite, MySQL, etc.). Take, for example, an LM386 audio amplifier IC.
There are at least 3 variations of that IC, each with its own electrical characteristics. That would require at least 3 entries in a “part lookup table”, with the “primary key” for that table being the MPN. Each user will have different opinions on exactly what to name that field (MPN, MFN, etc). as well as which data fields (from the data sheets) that need to be associated with that part.
Then, to be truly useful, there would need to be a vendor lookup table which would include not only the MPN, but the vendor part number and vendor price as well, along with various other data fields that each user will also have different opinions on.
MUCH time then would be spent just doing database maintenance tasks. While not impossible, it would be very time consuming to say the least. And with the varying opinions on exactly which data fields need to be included for each lookup table, I feel it would be nearly impossible for all users to come to an overall agreement on this.
Just my thoughts. Anyone else… Feel free to jump in here with your thoughts.
While we are looking into this, it would be neat to combine this with the appropriate spice models, since the new ‘simulate’ option allows us to easily access ngspice. It seems to me that the spice model is almost as dependent on the vendor as the other specifics of the parts.
It would be very handy, though.
And yes, it would probably involve a lot of maintenance, but as the user base of kicad grows and grows, it is possible the vendors are interested enough in the community members, to help maintaining the database for their parts.
One thing I failed to mention is the variations of multi-tier pricing for each vendor (some: 1-10 pieces, others: 1-20 pieces, etc.). The variations are substantial and would simply be a nightmare to maintain.
Another would be exactly which database engine to use. SQLite might be a better choice, as it doesn’t require a separate db server to be installed (as opposed to MySQL, Postgre, etc), but that will also vary with opinion.
There is no doubt that it would be useful, but quite a chore to implement.
They are already doing that for themselves ?? Wouldn’t that be double work on their part ?? At this time, I’m just not thinking of a somewhat feasible way to address all the variations that would need to be addressed.
Yet another variation…
At times I purchase items from Jameco. When looking at a particular item, they offer this:
I have downloaded CSVs for capacitors, resistors, opamps, etc. from them in order to look them over and see the feasibility of starting my own database of items I often use. What I got was CSVs having column counts ranging from 15-column to 31-column. At least in this case, the column count is not consistent, even with the same vendor.
I do not think it would be double work, because they almost all use spice models. Once a vendor has developed a spice model, it can be supplied without much extra work.
As I start, it would be good to have a community database of spice models that can be associated to kiCAD parts.
We’re apparently on two different trains of thought here. I was just thinking in terms of the OP’s comment and configuring database tables in a manner that would be feasible to implement and relatively easy to maintain.
While I appreciate this discussion one has to be very careful as to where are you dragging KiCad. We just moved from a library manager to a parts manager to an ERP system. When you do more than 5 projects a year then managing parts becomes a real issue. I keep forgetting what components I built into the project before the last one. That applies to the component, its packaging and the subsequent order numbers. When one talks about ‘generic’ components like R’s C’s Diodes Op-Amps etc… in many cases you can reuse comps. As a matter of fact, some companies require to use comps which are second sourceable. Before somebody gets exited about atomic parts, as the generic comps are concerned they are utter nonsense and would blow up the libs with a lot of redundant material. In our little shop we’ve been thinking about this issue a long time and came to the conclusion that there should be that famous ‘Select Part’ button which you could hook up to your own parts db (Material Management System, ERP. I’m no db or software pro but I guess one would need something like an ‘internal part number’ which would be fine for me. Doing it this way all the ‘material’ issues, reduction of (quasi)duplicate parts, order parts, choose the most cost efficient vendors, the right price breaks, managing your stock, is left to the specialists. There are system out there, open source, which do this and a lot more.
Another issue is that KiCad users are in many countries with different currencies, pricing and distribution. This makes comparisons even more complicated.
.
