True components library

WOW, you put autorouters before the Grand Unified Database!

This really is probably the way it has to be. There are to many changes with component manufactures over time.

I was trying to work out a simple system, and I gave up because of how time consuming even a simple system ends up being. However, as I have let the concept percolate in the back of my mind I may take another stab at it. The card I have up my sleeve is that I have worked with part number systems used in the US military and defence contractors.

Yeah, that seems to have been designed into the Foundations of the Universe back around Day 5 of creation. Iā€™ll have to take a look at Genesis.

That part numbering system was one of the primary reasons computers were invented in the first place.

Defense contractors still maintain their own in-house p/n systems, with the functional-equivalent of a look-up table between their numbers and the NSNā€™s.

Dale

DHL also has their own tracking number system.

Once your packet (with tracking number) enters DHL, itā€™s gone and you can do nothing more than wait and hope it will pop out againg.

Probably saves them a lot of headaches from customers complaints.
There can only be one possible complaint, and the answer is: ā€œWe use our own tracking numbersā€.

Some time ago I had a EUR 45 packet and EUR 25 for shipping, EUR 70 total.
DHL managed to add a bill for vat & ā€œhandling costsā€ of EUR 51, while more realistic costs would have been around EUR 20. I refused the packet, unknown tracking number, itā€™s not for me.

Lately Iā€™m delaying payment of shipments from Ali untill the seller confirms it will not be shipped with DHL.

I think thatā€™s too ambitious. I was literally just thinking of something for individual makers.

Itā€™s outside the scope of KiCad, but not necessarily outside the scope of the KiCad community.

1 Like

So many comment, thank you, Iā€™ll try to answer to someā€¦

@davidsrsb
I work in Leonardo even if my sub company is not so big. We have a cad (Zuken CR 8000) and for company policy we place only normalized components (exactly defined parts) on schematics, I find it so slow, heavy. So, true, own numbering system, but everithing else out of an internal number, is still the same as showed on any seller web page.
@Piotr
No one else will do the job to selecting order codes, at work I have to do myself. At home I can also consider to assign some components while drawing schematics: Sometimes, while designing circuits, I need to look for a particular piece to choose what to put on schema, optimize for cost, evaluate tolerance and working limits, so sometimes I found useful to annotate the component with manufacturer number, ordering code, value tolerance packageā€¦
Even more, at work every circuit BOM variation must be signed by a designer.
@paulvdh
ā€œAlso: Manufacturers go bust, parts get obsolete and replaced by other parts.
Iā€™m with Piotr. I do not want such information in my schematic, and it sort of is already in Eeschema anyway.
It will also explode the library size, just multiply the amount of resistor values with the amount of resistor sizes times the number of resistor sellers, and you want to add them all into the database?ā€
No, Itā€™s not what I mean. I think must exist just one schematic symbol for resistor, just a footprint for all 0603 components! I can set them apart from each other, lovely, but I would like also to have the possibility to search for real component and fill all fields properly. I simply add, before or later, detailed information about all parts on the schematics, and I love the simplicity to add some fields to the component properties in schematics! But I also find it time consuming and I think it could be done better. For example a couple of predefined fields each component has, are datasheet link and footprint specification. You also have a ā€œbrowserā€ for footprint that you can call while looking at a component properties, or have a matching tool to assign a footprint to every components. In similar way, imagine you open a resistor properties, type 2.2 Ohm 0.1% 1/4W, you canā€™t find reasonable SMD parts that matches your criteria, so select something slightly different like Yageo RT0603BRD072R2L RES 2.2 OHM 0.1% 1/10W 0603, push just one button ad you get a lot of field like datasheet, footprint, case, description, manifacturer number correctly filled in just one click, then come back to the schema and change something else to take account of you parts.
@dchisholm
If you are working yourself youā€™ll need a some point to solder parts on your board. Maybe you have a book of resistor of some packages, but you will probably need to buy some other parts, even in this case a couple of fields like a link to a seller may be useful, and you should probably have defined some components a lot before you have your gerber files ready. And kicad exports BOM with everithing else you put them in the schematics.
@Rene_Poschl
Thank you, interesting link, Iā€™ll look it later

Thank you all, regards, Roberto

Even when you have a ā€œwell knownā€ id like a NSN, your company and the supplier will still translate it to numbers that they know, approved vendors, bulk packaging, quality etc.
It is a real can of worms

1 Like

I am not using KiCad yet. In 1997 we have bought Protel I am still using.
Those times we tried to use elements fields existing in Protel to do what I understand you are trying to do.
I donā€™t remember exactly what make us to not use this way.
We decided to assume: single part name in Protel = exactly defined part.
Our default is 0603 so 4k7 at my schematic means 4k7 0603 1%. If I have to use new R value I donā€™t put R at schematic and change its name but I add new R into library and then put it on my schematic. This helps to not to use to many R values. The less number of values I use the less number of element boxes we need.
One exception to 0603 is that 100n means 100n 0402. 1k 0402 got the name 1k_4.
When I have to do something you have written in what I cited it tipically ends with defining new library element.
Then I have the LibreOffice Calc spreadsheet. At one page list of all my symbols in column A, and its descriptions in next columns. At next page I load a BOM from Protel and it is automatically supplemented with datas form first page. There is nothing against writeing many lines with alternative elements in one cell.
Preparing to use KiCad I decided that I would like to not have 1k_4 symbol at schematic and prefere to have 1k for 0603 and 1k for 0402. I have checked that in LibreOfiice I can do automatic text search with two fields texts combined.
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).
In Protel I didnā€™t had such help during element selection at schematic so I used self descripting names (D1A - means diode 1 Amper, Tr18 = transil 18V, Tdn4k7 = transistor digital npn with two 4k7 resistors). Now I plan to use names closer to industry names assuming that Description will tell me what I am putting at schematic.

I thought about haveing one R for all 0603 and changing its name each time after placing it at schematic but decided to add aliases with values we decided to use typically. I donā€™t know yet what I will do when I will need a new value - put R1608 and chane its name or add new alias. I will probably add new alias to have information that now we have this value in our drawer so using it makes no new storage problems for us.

Your example is one of the reasons why i do believe that a fully universal part management within any eda tool will not really be possible. The designer likely does not really care which 1k resistor is used as long as it has the correct package, temperature behavior and withstand voltage.

But the guys responsible for buying the parts might not always want to buy the exact same component. Maybe they already have a fitting resistor in stock. Or your board is re created years down the line and your original resistor of choice no longer exists.

This is where house part numbers show their power. You encode in it the parameters you care about. The rest is for the purchasing guys to decide. (They will most likely take the cheapest option under the constrains given. Including the choice: Take the same as used in the last project as our time is more expensive then we can possibly save.)

And this is also where you might discover that a universal part number can not work. You might care about a vastly different set of parameters than the next guy. Creating a library that encodes for all possibly choices will simply be way to much work for any given organization. And will most likely result in a part numbering system that is way to complex for any single person.

Which will most likely mean that every sane user will use their own true internal house part numbers which are then somehow mapped to the standardized ā€œinternational house part numberā€ which in turn points to a real part depending on your own circumstances. And now the question what benefit does this international house part number bring to an average user?

1 Like

Most important parameter when selecting which 1k to use - how many tracks I have to route under it :slight_smile:

For people really interested in this sort of thing, there is a parralell discussion going on at:
https://www.eevblog.com/forum/eda/(crowdlaborfunding)-pcb-cad-tool-idea/?all

Some guyā€™s over there seem to be desparate to explain the benefits of their database system, but for hobbyists like me it seems to be more of a bother than itā€™s worth.

1 Like

I think this summarizes the situation. 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.

(As a next step up - and Iā€™d rather not see KiCAD resources diverted into this right now - perhaps we need to define (yet another) library. Call it the ā€œPartsā€ library, or the ā€œPiecesā€ library, or the ā€œItemsā€ library. The records in this library will require a unique identifier - probably a house part number, but maybe a generic description or abbreviated mfgr p/n. Each record in this library should include, as a minimum,

  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.

(Astute observers will recognize that these three items are the minimum required to define a so-called ā€œatomic partā€. So maybe this library should be called the ā€œAtoms Libraryā€, or ā€œMolecular Libraryā€.)

Allow the user to add fields and subfields - at least several dozen of them - to the records in this library so he can refer to OEMā€™s, suppliers, descriptions, key specs, simulation models, datasheets, second sources, inventory counts, stock locations, specification drawings, accounting cost, similar parts, evaluation reports, etc, etc. These fields should be searchable and sortable.

At some future time - KiCAD version 7.0.0, or 8.0.0 - create the ability for the core KiCAD programs (EESchema, PCBNew, symbol editor, etc) to access items through the ā€œPartsā€ library as well as the symbol library or footprint library. E.g., selecting an item from the ā€œPartsā€ library will add both its symbol to the schematic, and its footprint to the board layout. If the symbol and footprint are flagged as originating from a ā€œPartsā€ selection, rather than separate selections of ā€œSymbolā€ and ā€œFootprintā€, the user can be warned about changes - much like the ā€œChange Footprintā€ dialog asks whether all instances of a footprint should be changed, or only those with the same value, or just one instance.

This is just a thought for future reference. By creating this new level of library, KiCAD can still operate, unmodified, in the form we all know and love. But it also allows KiCAD to become integrated with external tools for purchasing, inventory control, MRP, etc. )

Dale

1 Like

I am not so sure i see the benefit of having a separate entity (the part) here. Everything you describe can already be done with symbols and footprints as they are now. (Or am i missing something?)

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 think the main thing is that there will never be a single library that will be made for everyone. The official library will always be a compromise and i am not really prepared to use manpower just to add some kind of part numbering system that in the end will benefit no one. (What else can we add then using the part number as the symbol name?)

The designer only specifies minimums. If I call out a Resistor 1.2Kohm 10% 1/16 watt then someone else chooses thruHole over Surface mount. If the pick and place machine already has a 1.2Kohm 5% 1/4 watt then that is what goes on the board.

A lot of people donā€™t seem to believe that it is possible to come up with a workable universal part naming system but that is exactly what the real brick and mortar libraries have done with the International standard book number(ISBN). Each and every book has a identifier that uniquely identifies that printing of that story. If they can do it then so can we. This is something that the IEEE needs to own and create.

They did this 15 years ago. Itā€™s called IP-Xact IEEE-1685.

John Eaton

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

Exactly the same I thought reading about this third library (including the parentheses).

I see no advantage in such a system, and would also not like development sources being poured into this.

All of KiCads file formats are very simple, open, and well documented.
Any database worth wile would have quite some complexity and adding some scripts to generate custom KiCad libraries from that would only be a small extra effort.

People who want such things also do not trust the KiCad libraries, or have an elaborate verificiation procedure or strict quality guidelines.
KiCad has built in support for custom fields and that should be enough for now.

The Cern team has done, and is still doing, a wonderfull job but as far as I can see they are still working on leaving behind the old legacy stuff out of KiCad and lifting it into the next Century. Subjects like this may be worth re-visiting in 5 or maybe 10 years time.

I have also never looked into the target audience of the Cern team. If itā€™s mostly from hobby-ists to small companies then this database stuff is probably irrelevant. I do not think KiCad is ready to try to compete with Altium.

This is already in place, partly at least, and it looks very promising. In:
Eeschema / Tools / Edit Symbol Fields
you get a spreadsheet like overview of all the fields of all the Eeschema symbols. You can easily make groups of them, and then you can copy text strings from one field to another.

You could for example make a group of all 1k resistors and then associate those (and only those) with a ā€œResistor_SMD:R_0805_2012Metricā€ footprint. Or you could bulk- change all 1k resistors to 2k2 resistors

Sorting is also implemented by clicking on the top index row above one of the columns.

This functionality is something that has long been my personal wish to be added to the spreadsheet in CvPcb. It makes it a breeze to edit meta data of multiple data fields at once.

You can even directly copy from and to this tool to any spreadsheet application (libre office calc, excel, ā€¦)

Iā€™ve done a lot of reading in this thread, and the EEVBlog thread, and it looks to me that most of the comments indicate that users donā€™t know this function now exists.

Confirmed :slight_smile:
Just copied the whole component table to LibreOffice Calc, by using ā€œtabā€ separtion instead of the default comma while importing.

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. The assertion seems to fail when there are more spreadsheet fields copied into the table than fit in the table.

Application: kicad
Version: 5.0.2+dfsg1-1, release build
Libraries:
wxWidgets 3.0.4
libcurl/7.63.0 OpenSSL/1.1.1a zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) libssh2/1.8.0 nghttp2/1.36.0 librtmp/2.3
Platform: Linux 4.19.0-1-amd64 x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
Boost: 1.67.0
OpenCASCADE Community Edition: 6.9.1
Curl: 7.62.0
Compiler: GCC 8.2.0 with C++ ABI 1013

Build settings:
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_WXPYTHON=OFF
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_USE_OCC=OFF
KICAD_SPICE=ON


ASSERT INFO:
ā€¦/src/generic/grid.cpp(1108): assert ā€œAssert failureā€ failed in AppendRows(): Called grid table class function AppendRows
but your derived table class does not override this function

BACKTRACE:
[1] wxGridTableBase::AppendRows(unsigned long)
[2] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[3] wxEvtHandler::SearchDynamicEventTable(wxEvent&)
[4] wxEvtHandler::TryHereOnly(wxEvent&)
[5] wxEvtHandler::ProcessEventLocally(wxEvent&)
[6] wxEvtHandler::ProcessEvent(wxEvent&)
[7] wxScrollHelperEvtHandler::ProcessEvent(wxEvent&)
[8] wxEvtHandler::DoTryChain(wxEvent&)
[9] wxEvtHandler::ProcessEvent(wxEvent&)
[10] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[11] wxMenuBase::SendEvent(int, int)
[12] g_closure_invoke
[13] g_signal_emit_valist
[14] g_signal_emit
[15] gtk_widget_activate
[16] gtk_menu_shell_activate_item
[17] g_closure_invoke
[18] g_signal_emit_valist
[19] g_signal_emit
[20] gtk_propagate_event
[21] gtk_main_do_event
[22] g_main_context_dispatch
[23] g_main_context_iteration
[24] gtk_main_iteration
[25] wxWindow::DoPopupMenu(wxMenu*, int, int)
[26] wxWindowBase::PopupMenu(wxMenu*, int, int)
[27] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[28] wxEvtHandler::SearchDynamicEventTable(wxEvent&)
[29] wxEvtHandler::TryHereOnly(wxEvent&)
[30] wxEvtHandler::ProcessEventLocally(wxEvent&)
[31] wxEvtHandler::ProcessEvent(wxEvent&)
[32] wxScrollHelperEvtHandler::ProcessEvent(wxEvent&)
[33] wxEvtHandler::DoTryChain(wxEvent&)
[34] wxEvtHandler::ProcessEvent(wxEvent&)
[35] wxGrid::SendEvent(int, int, int, wxMouseEvent const&)
[36] wxGrid::ProcessGridCellMouseEvent(wxMouseEvent&)
[37] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[38] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[39] wxEvtHandler::TryHereOnly(wxEvent&)
[40] wxEvtHandler::ProcessEventLocally(wxEvent&)
[41] wxEvtHandler::ProcessEvent(wxEvent&)
[42] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[43] g_closure_invoke
[44] g_signal_emit_valist
[45] g_signal_emit
[46] gtk_propagate_event
[47] gtk_main_do_event
[48] g_main_context_dispatch
[49] g_main_loop_run
[50] gtk_main
[51] wxGUIEventLoop::DoRun()
[52] wxEventLoopBase::Run()
[53] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[54] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[55] wxEvtHandler::TryHereOnly(wxEvent&)
[56] wxEvtHandler::DoTryChain(wxEvent&)
[57] wxEvtHandler::ProcessEvent(wxEvent&)
[58] wxWindowBase::TryAfter(wxEvent&)
[59] wxAuiToolBar::OnLeftUp(wxMouseEvent&)
[60] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[61] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[62] wxEvtHandler::TryHereOnly(wxEvent&)
[63] wxEvtHandler::ProcessEventLocally(wxEvent&)
[64] wxEvtHandler::ProcessEvent(wxEvent&)
[65] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[66] g_closure_invoke
[67] g_signal_emit_valist
[68] g_signal_emit
[69] gtk_propagate_event
[70] gtk_main_do_event
[71] g_main_context_dispatch
[72] g_main_loop_run
[73] gtk_main
[74] wxGUIEventLoop::DoRun()
[75] wxEventLoopBase::Run()
[76] wxAppConsoleBase::MainLoop()
[77] wxEntry(int&, wchar_t**)
[78] __libc_start_main
[79] _start