I’m currenty working on several extensions of the KiCAD library (adding symbol and footprints/3D models etc. seee https://github.com/jkriege2). During this, I thought about the following extensions/improvements to the Schematic Library Editor that would really make working on the lib easier:
Currently Aliases can have their own name, description, datasheet, But I think it would be great to also specify a custon footprint for each alias. This way we could e.g. have one diode symbol (with the correct pinout) and from this generate all sorts of diodes with different standard packages, without having to double,triple,… the actal symbol, just to be able to set the correct footprint. This would be useful, especially for components, like resistors, diodes, transistor (especially with the Q_…-series of symbols in device.lib), …
As an extension to the above thing: Would it be possible to link in a .CMP-file to a specific .LIB-file (in addition to implicit linking via the filename)? This way, one could create .cmp-file without the .lib and simply link the generic devices in e.g. device.lib, but if needed add additional symbols to the custm .lib-file
To edit and maintain all this it would be great to have a table-UI that allows to edit the Aliases (currently I have to close the properties editor, select a new alias, open the properties dialog, edit the props, close the dialog again, save the changes, …). In such a UI, we would have an additional (dockable?) window with a table of the Aliases that contains these columns: Name, Description, Keywords, Datasheet, Package (see 1) that can be edited directly in place (e.g. in-cell buttons to get parent-data, or even auto-fill with parent data, comboboxes/buttons to select footprint, …) + buttons to add new aliases, delete aliases, duplicate aliases, …
Today there is a pin-table window, which shows the pins in the device, but does not allow editing them … It would be great to be able to edit the pins+their props there!
This will be the source of terrible mess. I think the current approach is good.
We only need to create less “universal libraries” - for other devices than base devices like: resistor, capacitor, diode, etc. - which allow to select any footprint to symbol.
I don’t see why that would generate much more mess than today? We can already overwrite name (=ALIAS), description, keywords and datasheet … one more field would not really be that bad, or? Or is it a problem of the datastructures that represent the libs internally? I think it makes sense to have a set of those “universal” libs for this set of discrete components:
Here if we had those universal symbols + extensions it would e.g. be very easy to fix problems with the symbol or replace it with a newer version, as we don’t have to change X single symbols, but only one. Also maintenance and adding additional components, such as a new diode would be very easy. The current solution means a lot of multiple symbols that are really all the same.
… Uuuuppps, I mean .DCM file!
E.g. generate a diode.dcm-file without a lib and then write something like this in it:
$ECMP 1N4148 device.lib:D D Diode K diode F ... P Diodes_ThroughHole:Diode_DO-34_SOD68_Horizontal_RM7.5 $ENDECMP
Here $ECMP is a special EXTERNAL component, which means an implicit alias to the second parameter, i.e. the symbol “D” in “device.lib” the same file could full well also contain a normal section
$CMP 1N4001 D Diode K diode F ... P Diodes_ThroughHole:Diode_DO-41_SOD81_Horizontal_RM10 $ENDCMP
which then references the symbol 1N4001 in the diode.lib file.
This still struggles when two manufacturers make the same part, with different part numbers and one of the numbers means a different part to the other or a third manufacturer. Ambiguity rules out there.
This is why we have house part numbers
This causes a lot of double, tripple, quadruple … symbols, as there are actually only few different symbols for a vast variety of components. And that part of reality I would like to mirror in the lib structure, as it would help to maintain the libs. Say e.g. you want another style of transistor symbol, then if you have one component for each type, you’ll have to change tons of symbols. In addition we could allow people to simply tansmit a small dataset to the library, consisting of symbol-name, description, keywords, datasheet, package and we have the new component, they don’t have to go through the hassle of duplicating a matching symbol, changing the props, doing a PR … This way we could maybe also quickly generate a large lib with many components, which is IMHO one of the main reasons to choose an ECAD (at least for me a good lib is relatively cose to good usability ;-). Also note that my proposal does not forbid to to make components, as you propose (e.g. most ICs will be of this type), This would just improve/extend a bit the already existing ALIAS-option.
IMHO it is good for an ECAD software to have a large lib of parts already available, as this way the user’s productivity is higher out-of.the-box and we could gain more user, i.e. also a larger base of people that contribute to the lib …
PS: I would also be happy to implement some of these features … For that it would be great to have someone, who can give me a short intro into the code structure (I tried to snoop around a bit in the code yesterday, but wasn’t too successfull in e.g. finding the code of the SCHLIB-Editor …
But it has also some advantages. You choose correct symbol with pre-filled some data and don’t care about the rest of things (for ex. CvPcb job is gone). Just pick and place.
But you still do with my proposal … For the user it is completely transparent … just like an ALIAS today … it’s just an extended ALIAS and an extended way of definig them (if the $ECMP would be implemented)
Attracting the hobbyists and beginners is important. Compare kiCad with gEda. The latter was arguably more mature for many years, but lack of libraries made most beginners go off with Eagle. The result is that the number of gEda users is very small and the project progresses slowly with no visibility of the progress to outsiders.
Large numbers of users attracts support from the fabs and developer interest from beyond the CERN core group.
Simulation will be a different story. Creating your own simulation models is hard, which is why LTSpice is so dominant over QUCS etc
I used the term ALIAS, because it is used by KiCAD … and I use it in a way in which it is used today in the KiCAD libraries! Take e.g. the 74xx TTL parts. Here we have e.g. a component calle “74LS00” which has aliases “74LS37” “7400” “74HCT00” and “74HC00”. THese are al clearly different parts and the user selects the footprints he wants simply from the footprint library, which is filtered with a few terms.
Another example, let’s take the transistors lib and component BC547, which has aliases “BC546” “BC548” “BC549” “BC550”, which are all the same in a sense as they are NPN bipolar transistors with the same pinout. Even their package is all fixed to the same …
So this is the current usage of the features that KiCAD provides! Starting from this, the situation is as follows: Components are “ALIASed” more or less according to their schematic symbol, not by beeing the same component. Which is also IMHO no problem. SO it would make sense to support this usage, by making it simpler to group more components, as this allows quick and easy management of the lib (if I want to change e.g. a package name, I don’t have to touch 200 components, but only one …!)
Best,
JAN
PS: This is just a small feature that would improve the current usage of KiCAD features, not a large change and ground-braking change!!!
In my freelance days, PCB layout was something of an adjunct task that came with a gig, rather than a specific section of my position description. I did two or three boards a year, or made modifications to an existing layout. I worked in 4 or 5 different software programs and eventually landed in P-CAD. On most jobs I at least modified an existing symbol or footprint, or created a new one. About 4 or 5 years into this I realized I was spending a significant amount of time on each job doing “library work” - probably 25% of the total effort, and maybe as much as 75%. That’s when I decided to formally create, organize, and maintain my own libraries and treat the programs’ native libraries as “suggestions” or “examples” or “unfinished work in progress”.
But I needed the programs’ native libraries at the start, to keep myself from being overwhelmed by the sheer volume of what had to be learned. I wish somebody had pointed out, before I figured it out on my own, that I would learn to make my own symbols and footprints. Not just because “that’s how the pros do it”, but because eventually that’s the most practical way to do it. But . . . . (big "But . . . ") . . . . it’s not necessary to learn this right away.
Here’s my suggestion:
From the very start, point out that KiCAD’s libraries are NOT comprehensive, and have no plans to become comprehensive. Also, any program that claims to have comprehensive or almost-comprehensive libraries is full of crap.
Impress the user that KiCAD’s documentation will efficiently teach him to make libraries of footprints and symbols. (And, of course, produce tutorials and other documentation that truly does this.)
Create a set of VERY high quality libraries - perhaps calling it the “Basic KiCAD Library”. (The existing set of libraries might get called “Advanced KiCAD Libraries”.) The Basic Libraries should have enough symbols and footprints to do truly useful work, but not so many that searches and library maintenance become burdensome. Can it be done with, say, 100 symbols and 500 footprints?
Change the standard KiCAD installation so that it creates the directory structure for a user’s libraries. This should probably be relocatable to a user-specified location, rather than in “Program Files” along with the KiCAD executables.
Include not only tutorial material that teaches the processes for creating symbols and footprints, but also material that discusses factors to consider when creating symbols and footprints, and managing libraries.
The transition occurs when you need symbols/footprints who aren’t there and you start to search around for them and try to get them into one of the existing libs or make your own.
And you definitely will be sent over the edge once you do 2-3 boards within a year with more than 10 components on it and you discover KiCAD can also be your BOM manager (and more) if you just had a different setup of the libraries.
Anybody who doesn’t need those ‘features’ or hasn’t those ‘problems’ will be happy with the native hobby way of doing things right out of the box.
Luckily for the rest of us, KiCAD can do the more complex stuff as well without annoying the hobbyist.
As for advanced libs vs basic libs… If you avoid splitting through libs, but instead mark out basic (absolutely necessary libs) and advanced (you can get those later if you need to libs) you probably got a winner.
Don’t overwhelm the starter/hobbyist with a big pile of libs that he has to crawl through to find anything.
Give them the basic ones he will definitely need and if he needs more a nice interface to grab them where he sees fit - and make it hot-plug right there in the program.
But for all of this to make sense and be doable I would wait on the refurbishment of the code sitting under EEschema and the symbol libs as once that is done the hooks into them will be similar to the way pcbnew does stuff.
I’m expecting that those extra files @jkriege2 is talkking about for additional info will all be incorporated into kicad_sym files in sweet folders.
Again, anyone who has any desire to influence those developments, get in touch with the developers (and become one) by joining the dev mailing list on launchpad. https://launchpad.net/kicad
Be aware joining that list and suggesting/demanding things aka the bugtracker with ‘wishlist’ tag won’t get you anywhere.
Hhmmm … yes, the libs will never be comprehensive, but I would say the hobbyist wants a lib which is reasonably comprehensive, not minimal.
I think 100 for the basics is maybe OK, although the typical beginner will want say a BC548 and not a Q_NPN_EBC and then in addition figure out, which package to use … The same goes for ICs … and I think most hobbyists use quite a variety of ICs (ADC/DACs, OPAMPS, Timers, TTL, …) … so this will encompass (I would say) at least a few 1000 components, otherwise the “beginner” will use the software, tries to find his component, see’s its not there and use somthing else … at least I would do it that way!
I think this is a good point: Split the libs in basics (no special components) + full (all TTLs, different transistors, …) + extensive (all unusual comps). By default 1+2 are activated, the expert can deactivate 2 and the “I want all”-guy can activate 3 … Downloading from within the Tool: YES, REQUIRED.
In addition: My proposal would also make it easier for someone who wants to build his own lib: You can make a symbol once and then easily add new special derivatives (e.g. different transistors with the same pinout, but different footprints). When using them (or generating a BOM) KiCAD does not care how the comp was generated (ALIAS; ECMP, …), it just uses them.
But maybe it’s best to wait for the new lib format.
Great points, and I agree with you, but want to make one distinction.
There is a difference between a COMPREHENSIVE library and a RELIABLE library.
I bought Altium when they were advertising a pretty low price for the complete package ($3000) and the first question I asked on the User Group Forum was whether the included libraries were reliable. the answer was… NOT REALLY. TEST EVERYTHING.
Really? Well at the time I didn’t have time to create my own library from scratch so I never used it AT ALL, and I’m still kind of upset at myself for not looking into that topic before I bought (I had TWO days to decide before the offer ran out)
Anyway, the reason I’m responding is that no one wants to create a whole new library from scratch. Tasking a new user who doesn’t even know the basic principles is absurd, so the libraries that KiCAD provides should be tried and true, even if they are incomplete
Making environmental variables KISYSMOD and KISYS3DMOD “path” variables that specify multiple directories to search and in what order would help users setup their own directory structure for their personal libraries.
How many paths do you got?
You can define path variables for you own stuff if you want to.
So, additionally to KISYSMOD you could define MYMOD and maybe a GITHUBMOD if you work in a shared environment.
No need to water down the KiCAD System Module path variable into a jack-of-all-trades.
It’s way more important that EEschema works with this as well, so both parts of the toolset work alike and I can finally use a MYPDF path variable
At the moment I only have one additional path for collections of modules, components and 3D models. But I would like to share collections with my colleagues by just sharing a folder and then updating the environmental variables the specify the search path lists.
Definitely important that both parts of the toolset work alike. Collections of modules, 3D models, components, and symbols should all use path lists!
I don’t know how making these environmental variables lists of paths is watering down anything. Using environmental variables to specify a list of paths is conventional and straight forward approach.
