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 
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,
-
A link to a KiCAD symbol, as symbols are currently defined.
-
A link to a KiCAD footprint, as footprints are currently defined.
-
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
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 1013Build 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 functionBACKTRACE:
[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
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.
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.
1 Like
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.
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, …)
1 Like
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.
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.