And there’s a reason that the task of making symbols, in most companies it is concentrated to a small number of people doing it often and being experienced about it. Even the small companies I used to work for, where the circuit developers themself needed to draw the schematic and layout. Footprints were always the job of a specialized person (I know, that does not help us here). And it is a boring task, so you need to pay people to do it 
Yes, that is pretty much the idea behind symgen.
1 Like
Tbh, I am not sure it is fair to ask people to submit MRs, since they will probably sit there becoming stale, and contributors become disappointed. There are currently 915 MRs, dating back 3 years.
I have no good answer for that either.
Currently my motivation to do kicad-stuff is close to non-existent. I am trying to get the library-utils stuff done and rolling, but that’s about it. I think I have not merged a symbol or footprint submission in 2 Months.
A year ago I was able to finish about 3 MRs per week. The Team also felt more productive/active so we managed to keep the list of open MRs from growing fast. Sometimes it was even shrinking.
I found the “Merge Requests” on the gitlab Webpage, and now i better understand why there are so many pending ones. And I understand why most companies restrict the making of the symbols/footprints to very few persons - the rest need just to accept their style with no discussion.
I’m surprised about the loose connection between schematic symbols and footprints in KiCAD. As a example in one thread in the merge request folder, the footprint filter allowed for the same package with different sizes of exposed pads, so it is still up to the user to choose the right footprint (although having the wrong size EP is not so critical in most cases).
And it is only connected with the footprint by the name, so every renaming event of the footprints might cause a bug, with the wrong footprint chosen for a symbol. Therefore destroying the confidence that the symbol and footprint fit together every once in a while when there was a mayor library update (renaming, reordering folders, etc.).
I always assumed the correct (and tested!) footprint tied to a symbol is one of the key features of having a library. And this being long-time-used, therefore being confident that there are only few bugs.
About the v6: Now I understand that the file format of the symbols and footprints is going to change. So maybe I wait until v6 is out, with a binary for Linux MINT, because I’m very bad with compiling stuff myself…
As I understand there is already a generator for symbols, probably using a pinout table (CSV?) as input:
I don’t readily understand which kind of input this takes, is there an example how to use it? I assume that it creates a retangle-style symbol (like for most integrated circuits) out of a table with pin definitions?
That seems to surprise a lot of people 
The origins of KiCad lie in code “created in 1992 by Jean-Pierre Charras while working at IUT de Grenoble” wikipedia. I think originally it ran under DOS. With limited time and resource, decisions were made to make coding easier, which with hindsight didn’t lead to an ideal data model, but now those decisions are baked into the KiCad ecosystem and are difficult to change.
Indeed, keeping name references in sync is a constant battle. As are debates over preferred style.
There are several examples at https://gitlab.com/kicad/libraries/kicad-library-utils/-/tree/master/symbol-generators. This particular symbol generator is programmatic; the API layer allows any type of symbol to be generated.
Loose connections between symbols and footprints is not unique to kicad. Even PADs PCB and Altium can work that way.
It’s only EAGLE that I’ve personally used that had the tight coupling.
I think the main difference is that most other tools seem to support either option (loose coupling or tight coupling) equally well. KiCad is much more aimed at loose coupling (although it does support “tighter coupling”, not quite as tight as some of the commercial tools). We have some ideas on how to improve this in the future.
I would not state that kicad is in any way limited with tight coupling. After all if you set the footprint in the symbol library then it is completely coupled. Of course users can still overwrite this but to be honest i don’t see that as a downside.
What might be missing is an easy way to define different footprint pad to symbol pin mappings for differing packages. (Warning: this is my version 5 knowledge it might have been added to v6)
For example if the sot package has some function connected to pad 1 but the TO package has it on pad 2 then one needs two separate symbols or some hacks on the footprint side - This is for example the case for transistors available in multiple packages.
Unless one only considers it tight coupling if all asset types are in the same file. I would however argue that coupling is on a much higher abstraction level then the details of how stuff is saved on disk so the number of files should really not matter. I can however be persuaded that an exchange datatype for an atomic part (symbol, footprint and optionally 3d model and spice model) can be of use to simplify adding stuff to the lib (on “installation” kicad could then ask what library each asset should go in and adapt the links accordingly)
There are two other limits I can think of right now, in addition to the one you mentioned (not possible to have 1:many relationship between symbol and footprints with control over pin mappings)
- there is no way to package a symbol and footprint together in a single file, so it is still possible for a symbol to reference a footprint that cannot be found (some other EDA tools make this possible)
- as was recently discussed ad nauseam, there is no way to package a 3D model with a footprint
I argue that the tightest coupling requires them to all be in one file, because this is the easiest to distribute and the easiest way to make sure that symbols and footprints don’t get out of sync with each other.
Note: I am not saying that I think the KiCad official library should go this way. Just that this is what “tightest coupling” looks like in some commercial EDA tools, and it’s a way that some private/unofficial libraries may want to be organized.
1 Like
For distribution of symbol/footprint/3Dmodel sets, maybe something can be figured out once the plugin manager starts to get implemented. That way someone (or some organization) could distribute a single file (some sort of structured zip file like a openoffice document or ArduinoIDE library) that the plugin manager can unpack, read the manifest, and install the proper files into the proper locations.
IMHO this should probably be secondary to actual plugins, but if the concept of how to do this is present at early planning then hopefully implementation doesn’t lock this out.
The sensible way to handle linked data is with packages, which thousands of other programs use. Binary files like JPEG are best left separate, trying to incorporate them into a new custom file structure is daft. Therefore use files, but put them into a package.
The only things required for a package is a manifest file, and a defined structure. You can also add metadata like organisation, version, and integrity checks like MD5. Once you have that, it can be used for a single component, or whole libraries, for local storage, and distribution.
This is such a well known and widely used solution I really really don’t understand why KiCad developers try to invent something different.
2 Likes
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.