True components library

[ouabacheDesignworks]

@Piotr

@ouabacheDesignworks

then someone else chooses thruHole over Surface mount.

What! The designer designs PCB and then someone decides TH or SMD?

The circuit designer designs the circuit and someone else decides if it is SMD or THT or both. You can do a lab proto with THT because it is easy to instrument and test but go SMD for production. Both use the same schematic.

[Piotr]

@ouabacheDesignworks

You can do a lab proto with THT because it is easy to instrument and test but go SMD for production.

You can, but I have never used such solution. Have you?
I think it can be usefull only in some very special situations and only in very limited scope.
For example I would never assume EMC tests of any THT PCB would be comparable with SMD PCB behaviour.
Schematic is for me 20% of work, and PCB 80%. Designing two PCBs for one schematic - I would not like it.

[John_Pateman]

I think this project summarises some of the aims of this type of workflow
https://github.com/turdusmerula/kipartman and this was discussed previously in this forum.
Place components from SQL database

I still think there is value to a workflow that enables an ‘Add symbol from database’ alongside a conventional ‘Add symbol’ workflow.

https://user-images.githubusercontent.com/11743864/34055733-678d938a-e235-11e7-82ef-13ed33e863ab.gif(image larger than 4096KB)

[Rene_Poschl]

There is a difference between having some parts of the symbol (like order information) found in some database and having the symbol in the database.

To be honest i still do not see the benefit of having the information that is in the database then embedded into the schematic. Simply use some single field as the key to tie together the database and the schematic. This allows you to update order information without changing anything in the schematic. (The schematic itself likely stays valid much longer than order information for digikey, farnell, …)

[Sprig]

@Rene_Poschl

Simply use some single field as the key to tie together the database and the schematic. This allows you to update order information without changing anything in the schematic.

And again the solution is an in-house part number.

Just because some EDA softwares does ties everything to the database, this does not mean that they should.

@dchisholm

1. A link to a KiCAD symbol, as symbols are currently defined.
2. A link to a KiCAD footprint, as footprints are currently defined.
   3. A link to a KiCAD 3-D model, as currently defined.

One issue that I have is that the current “link path information” is shown in the Schematic Fields editor for the Footprint. I don’t really care about the path information, I just want to declutter and show just the Footprint Name; if it’s a KiCad library I’ll know just by they library conventions.

Number 3 is really good idea. At the moment, the 3D is assigned at the Footprint level; but does this really make sense in the context of this thread? Why not assign the Footprint and 3D model with the CvPcb tool? … and BOM and Database stuff?

All that would be needed is for all Field Information to be available to read and edit in all 3 programs.

[ppelleti]

@Rene_Poschl

Something that might help would be a more powerful aliasing system. (for people who do not want to have copies of the same symbol just to have different fields pre defined.) Maybe the inheritance system that is part of the proposed new file format would do the trick.

I’ve wished for a feature that I call “palettes.” A palette entry would be a pre-defined combination of a schematic symbol and fields, which could be instantiated from eeschema, just as you can instantiate symbols from eeschema.

This would be exactly the same as making a personal symbol library with predefined fields, except that the schematic would not remember which palette entry it was instantiated from; it would only remember the symbol name and fields. That way, someone who opens my schematic has to have the same symbol library that I do, but they do not need to have the same palette library that I do. Use of palettes would be a totally personal thing, and would not be visible to someone who downloads my project from GitHub.

[nhatkhai]

@Piotr

I am at stage of library definition (currently breaked as I have to write some software) and my decisions (not tested in practice) are: I will have a library named R. It will have one element R1608 (I change to mm) with many aliases like: 1k, 1k5, 2k2, 3k3,… I will also have a library named R1 with one element R1005 and only few aliases.
I will take from KiCad BOM only element name and its footprint and rest from my spreadsheet.
In libraries I am adding only the description to help me when adding the element to schematic - I hope it is visible (didn’t looked at it with V5 yet).

This is what I intended to do by layout the path way in my scripts Back import custom fields

[nhatkhai]

@paulvdh

Then I tried it the other way around, and it seems that if you paste data for multiple cells into the Symbol Fields editor it’s pretty buggy. I’ve had several failed assertions which made Eeschema crash completely.

Sound like time to try my bom2sch.py scripts – It work very well for me :-). Back import custom fields

[nhatkhai]

@ouabacheDesignworks

You can do a lab proto with THT because it is easy to instrument and test but go SMD for production. Both use the same schematic.

This call the configuration manager. And my script again just couple more line of code to be able to help apply difference configurations of difference section of the design… I just have not formula and have time to write them yet util I readily need in my own project. But I’m well come everyone to modify my code…

[nhatkhai]

SQL database is the thing that hard to maintain, and access, and make every one so dependent on it to the point that no escape. So database should be see as a form a other type of file accessing to get your data. Instead interface it out, so people can scripting for any type of database, digikey API, octal part API Rest, personal mySQL, person csv file whatever so that the same search engine can be work on for get the part automatically.

[ppelleti]

@John_Pateman

Octopart is now owned by Altium, I believe. Although it is currently free to use, that may not always be so

And, indeed, that just happened.

[John_Pateman]

The point is that the responsibility for setting up / administering / running any database is completely separate from KiCad - totally optional and absolutely and entirely the responsibility of the user. All I am suggesting is an possibility to hook into an pre-existing SQL database that the user can use to store their own components. This is simply a way of reading the data in and has absolutely nothing to do with maintaining the content/accuracy or completeness of the database. I am not suggesting that any development is spent on trying to maintain an actual database of all components - that is clearly madness and I have no expectation or interest in the developers actually producing a database. All I would hope to achieve is to populate the current F component fields and the DRAW/ENDDRAW library sections from an alternative source. Additionally, it should be possible to support looked up fields for footprint/model etc. also held within a database.

You say ‘interface it out’ - thais exactly what I am suggesting; simply the ability to use a database as an alternative the source of a part definition rather than a flat file.

It is absolutely not an appropriate expectation of Kicad to manage /administer/ install or otherwise interact with the database - simply offer the ability to pull in some fields from here rather than from a flat file. The point is that if (like me) you have a pre-existing SQL database which has some fields of interest that I want in my design and BOM, you could choose to select them from the database not from flat files.

There are many many tools for interacting with SQL and accessing and manipulation/sharing the data is very well supported and highly efficient. It is fairly straightforward to then develop tools that can manipulate and manage the SQL side. Unfortunately, for me the possible loss of Octopart access will perhaps have to make me reconsider the value of this.

Anyhow, I get the feeling that I am a lone voice in this so have no real expectation and I too believe there are some other features which probably deserve more focus. However, if the V6 > 7 > 8 … roadmap is not completely fixed, I think it is a possible consideration to bear in mind when making design choices.

[Sprig]

@John_Pateman

The point is that if (like me) you have a pre-existing SQL database which has some fields of interest that I want in my design and BOM, you could choose to select them from the database not from flat files.

I think this topic deserves it’s thread. However, I’ve stayed away from SQL databases as one less thing to have to try to learn. Yet, it’s possible that I may well need to learn this in the not so distant future.

It also looks like adding this feature would satisfy the requirements of most of the users on the EEVBlog that did not consider KiCad to be a “real” design tool without it.

@John_Pateman

Anyhow, I get the feeling that I am a lone voice in this so have no real expectation and I too believe there are some other features which probably deserve more focus.

There might be more users that would appreciate this feature than is currently being displayed; as the squeaky wheel always gains the most attention.

Please create a new topic so that I don’t derail this thread with questions on exactly what functionality you might want with such a new feature.

[RobertoP]

Ok, I have read a lot of comment, sugestion and ideas, i’ll try to add some tough…

• I realized that every people/company work in a different way
• I think kicad maybe even better (simpler and faster to use) than very expensive software like Zuken
• I realized I didn’t explained me so well, I probably don’t want a real database
• I probably realized I’m interested more in a system to collect some data from web in a specific way than a real local database

Just one quote:

@dchisholm

A well-defined database system is someplace between impractical and impossible.For now, let’s be content with having an ability to add data fields to the symbols. Make the fields searchable, sortable, and perhaps display-able on schematics. Let the end users decide what information should go into the fields and how it will be used

this is exactly what I mean, thank you @dchisholm!

If you are not interested in this functionality, you can still use KiCad as you are used.

If you want to generate something like a BOM from your schematic, you may want to add some information to symbols on your schematic. Double click on one symbol and you have just 4 predefined fields, fine. If I need to add some fields, I probably want every component in the schematics wich has the same type of infos, would have exactly the same fields attacched on it. Predefined fields (I have the italian version) are: Riferimento (Reference), Valore (Value), Impronta (Footprint), Specifiche (Datasheet), for example I may want to add manufacturer number so add a field “manf#” and this field should Always be manf#, no M. no. or manufacturer number. Other minimum fields may be Description, Supplier, Populated.
Ok, so you have opened dialog Windows for symbol properties, in the right of the Windows there is the field area, in this area (a different tab that opens in same location or anithing else) I set common properties for every symbol: this means empty (~) fields with fixed names: manf#, description, supplier, etc… In the meawhile, after a long search around the web I choose the exact part I want that symbol to be, copy link(?) from compatible website and paste in KiCad symbol properties window, then click a button like fill fields and get all stuff in place: manf#, Description, supplier, but also value, footprint, and specification get filled, directly from website.
A little extra to this approach, is to save a local copy of information acquired in a local database (read as csv o xml simple file, a flat table) if desired. Local copy and schematic symbol may have replaced corrected fields for example to fix a footprint not automatically linked or extra data like a company part number. Later I can use this backup copy to search for already used (in older projects) parts. When using a local parts description, automatically verify matching beetwen local and server remote data, alert if something doesn’t match.

I’am an hobbist? I can easily have a BOM from my schematics. I’am a little company? I can save most used company parts in a file that I can use to find components to place on my schematic.

Regards, Roberto

[RobertoP]

I was googling around when I found this video about librePCB, and its approach to libraries: https://youtu.be/vu-h5y6tK34.

@Sprig

It also looks like adding this feature would satisfy the requirements of most of the users on the EEVBlog that did not consider KiCad to be a “real” design tool without it

If I think to myself when drawing a schematics, I place a bounce of components and connect them whith a couple of lines, look into a lot of datasheet to find some foundamental information, then apply some changes to the schematics, for example place a particular components, add a value to resistor and capacitor around it, maybe a comment in a field of some components that tells me something more about tolerance, voltage range, power rating… In each case, library and component annotation are the most important feature, add some labels and wires and you can make a schematics of any complexity, anithin else is useful but not foundamental.
When you have your schematic, add a footprint to each component (I try to add a footprint and a code to the component when I’am viewing its datasheet, doing this later is a waste of time to me) to get a board. this step is also strictly based on libraries. Only the last step, move footprints around and connect them by tracks is not so closely based on libraries.
After the PCB you would probably generate a BOM, here is another step based on the field you have filled when designing the schematics. If the BOM is not complete, simply add missing information manually.
I still think that library and fields associated to each components are one of the most important thing in the whole process.
I can’t understand why kicad has only 4 predefined fields for each components but has a bom generator utility, it’s seems to me a countersense: it’s not so if I manually add fields to each components, but this is not very practical.
May be I didn’t conviced you but, sorry, I’am still convinced that a good library sistem is a must have for every tool like kicad, and this could be the reason that makes so many company pay someone to draw and mantain library.
But library must be easy, I don’t like aliases, I don’t like to have a normalized specific part of every components I place into the schematics as I must do when I’am at work.
I like to use generic symbols in my schematics, add data to create a given part, if this is not done only manually this could be faster and less prone to errors. Get data from commercial website, why not? Save in a local archive and recall each time you wont, this is just a bounce of textual data and the ability to fill-in in a semi automated way, and if you don’t want this, this doesn’t change the way you already use Kicad.

In short:
Which is the importance of librares in your opinion?
Which data do you fill in kicad schematics?
How do you use kicad BOM tools?
How do you do the BOM?

By, Roberto

[paulvdh]

Have you seen this link?
https://forum.kicad.info/t/for-those-fans-of-atomic-part-libraries/15212

[RobertoP]

Thank You paulvdh, there’s a lot of stuff already out there… This seems to be the topic of this discussion:

Projektanker/kicad-db-lib

Other tools can fetch data from a web page, having both seems to fulfill my wishes, just wondering if I can fetch data in kicad-db-lib database!

Thank you a lot, regards,
Roberto!