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.
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.
Sound like time to try my bom2sch.py scripts – It work very well for me :-). Back import custom fields