I’ve been around for for a little bit and have been doing professional design. KiCAD has intrigued be for awhile because it truly has some great potential to be a tool that can rival some of the big boys.
I think one of it’s short comings is the kicad-library on GitHub. I don’t understand why the footprint database isn’t maintained using IPC naming and padstack standards. I could see how having these footprint already cooked up would add a lot of value to the tool and convince more people and businesses to use it; but if they don’t conform to any type of standard, outside of the KLC (Kicad Library Convention), they’re worthless to anyone making boards professionally. IPC has spent a lot of time researching how to make land patterns and footprint durable and build-able. I don’t see how value is being added to these libraries, from a professional standpoint, if they don’t comply with known good standards.
Also, are there any plans to use a padstack approach to via and land-pattern creation in the future? Having to redo a pad every time I place it in a different design is a bit of a pain…
Lack of resource for a start.
Changing conventions also breaks things, as happened recently as libraries were changed to follow IPC standards for diode pin 1
I see it the other way. I think you would get more people to sign up as librarians if they knew their work, and the work of others, was known good work. I end up doing all my land patterns to follow IPC because I care and then I can’t submit them because they don’t comply with KLC…
Then find like minded people (maybe even via this board) and do your own IPC compliant library…?!
Just a suggestion. Lot’s of people share their stuff via github on their own and others will be able to link to those instead of the KLC ones…
And if the nice step model generator at https://github.com/easyw/kicad-3d-models-in-freecad would be changed to comply to IPC naming conventions, then you have a complete footprint/3d model package for KiCAD!
Can you expand some more on this ?
eg Why do you have to redo a pad every time I place it in a different design
In the tests I’ve done on PadStacks, PcbNew is very close - it can import and save them, but some of the details around pour outlines, and DRC connect, have issues.
The Pour-outline needs a step removed/skipped, so that should be relatively simple, and the DRC connect is separate, but here the filled polyline-to-Pad does not DRC the same as Trace-To-Pad or Trace-To-Fill.
Those issues have workarounds, so a design can complete.
@wsender I’m one of the library maintainers for the github repositories. While a lot of the libraries are still “legacy” and the quality of many footprints (and schematic symbols) is still sadly lacking, we are (slowly) working towards improving them.
However the library maintenance team is very small, and there are lot of pull-requests to handle (and many many more old parts that need serious work). Apart from managing new PRs we also mostly focus on components that are “useful” to us (i.e. if I am using a particular part and find that it’s not very good I will update that and submit a PR to the master branch).
It would be great if we were further along with this - the main issue is time and focus. If there is a particular area in which you think a component (or an entire library) is falling behind in terms of good-practice (whether this means full IPC compliance or otherwise) then you can submit an “issue” to the particular repository.
Even better, you could help to update the components where you see the need. The more eyes we have on this, the higher the quality of the default libraries.
Having a great set of libraries will help attract users and this will in turn help to develop not only the libraries but also the KiCad product.
I hope this helps, and I hope it inspires you and others to help out where you see the need!
The problem with the Kicad repo is the backlog of PRs. It seems pointless submitting changes if they sit in a queue forever. There are many PRs dating from 2015.
What can be done to reduce the backlog? What exactly is the bottleneck and how can it be addressed?
Bottleneck_Neckdown_Size = (Manpower * Spare_Time)
The only solution is to nominate more professional maintainers with the rights of approving requests.
Well, you could think of a fast approach by chaining all the available tools into a nice toolchain
If for instance (forward thinking) you could use the full IPC set as referenced in de link above, together with the 3D generator and the stepup library stuff for FreeCad, then you would fast forward KiCAD development a lot.
However, this toolchain should be maintained, should be integrated into the KiCAD repositories, and some future release schedule should be made as in: as of v4.5 the non-ipc footprints become deprecated in v5, so users can migrate to the new standard.
Is this a simple job? Well If I look at the footprint libraries, there are still some problems/work to be done:
The mentioned footprint libraries do follow (old ???) IPC naming conventions and lack for instance the outline in the fabrication layer, which my fab house requires!
And neither of them have the eco1.user layer I use for the value (%V) + outline!
And as a personal note: i find the IPC naming conventions hard to read due to the lack of underscores/dashes and the all-capital naming. The Kicad footprint names are much easier to read!
So neither of these satisfy my needs fully
But these are problems that can be overcome by writing/changing the (python) scripts that generate the footprints. These scripts can even have options to satisfy for instance my needs for the eco1.user layer.
These scripts can also (from the same IPC compliant source) generate both the new IPC footprints and the ‘legacy’ Kicad 4.x footprints.
Same approach can be done for generating the STEP 3D files: adjust the current scripts for both situations.
After some experiments with Chris Pavlina’s footprints (https://github.com/cpavlina/kicad-pcblib) and modifying the scripts a bit (oops. Python was new to me) to get fabrication outlines, etc. I came to the conclusion that these footprints are indeed using the older IPC naming conventions and footprint conventions and are not easy to adapt to the latest and greatest IPC7351C version.
In other words: I will definitely use the free IPC footprint generator as the basis for my Kicad footprints, just fill in the min/max dimensions, pitch, etc. and you the footprint is auto-generated for you (14 pin, 1.27 pitch SOP):
As you can see, this one uses the latest standard:
Latest naming convention with the #of pins at the start and not anymore at the end of the filename, ie: SOIC14P127_865X600X172L84X41N.kicad_mod, great!
Horizontal orientation (“B”) with pin #1 at the lower left corner as opposed to the vertical “A” orientation
New courtyard outline
New silkscreen conventions (no silkscreen under the body of the chip!!!). You see only two lines at the top and bottom of the chip.
New pin 1 convention (no dot anymore, just a short line)
And not new, but very nice: everything is metric. Goodbye to imperial!
I just add my %R to the fabrication layer, and the %V and outline to the eco1.user layer, and my IPC-7351C compliant Kicad footprint is complete!
So apart from the existing Kicad footprint libraries I now have three extra libraries (the 3-tier system):
M…Most Material Condition (Level A): IPC-7351C_Most.pretty
N…Nominal Material Condition (Level B): IPC-7351C_Nominal.pretty --> My default.
L…Least Material Condition (Level C): IPC-7351C_Least.pretty
And with those libraries in place, I have a solid basis to migrate some of my current and new designs to IPC footprints where available without having to change any of the Kicad footprint libraries. They can co-exist
So let’s do that then… but I guess the professional need to volunteer first, and there may be lack of professionals willing to give their time.
To be honest, the Kicad libraries are doomed with this “cathedral” approach to crowdsourcing. By setting a high bar for new additions, and having a small set of approvers, it will go nowhere. The current librarians seem to be in denial, they don’t seem interested in engaging in how to improve things.
The whole point of crowd-sourcing is to get the crowd working for you. If there are faults, then the crowd will fix them. The maintainers are basically creating a mountain of work and then saying they don’t have enough resource to process it. So don’t create the mountain!
I can’t see any reason why many of the PR were not approved. There isn’t even a comment to say anyone has looked at them, where there are comments they are useless generic “go read the guidelines”.
It might help if there was an new / checked / approved status. Use scripts to do automatic checking, or even automatically enforce rules.
But anyway, I conclude the KiCad library repo process is terminally broken. I might set up a “community library” and see how far it gets.
A further thought on libraries. The current kicad part definition is not object oriented. So for example, the outline is a bunch of graphic lines on a particular layer. If the user wants to put them on a different layer, it’s pretty tedious.
If I was designing a system from scratch, I would have things like the outline as a specific attribute. Then it could easily be placed on different layers.
I’ve recently been using some scripts to generate symbols from a text file, for a lot of symbols that follow a standard blueprint it’s a lot easier than using the GUI editor. Also, I have software to scan a library and automatically place a KLC compliant outline on the courtyard. With the right tools, a lot of the library workload could be reduced, even to the point where submissions could be automatically accepted.
I would like to see that happen. I have libraries on my github but suspect they aren’t seen often. It would be nice to have a central site where you could go and find interesting parts and footprints.
After some experiments with Chris Pavlina’s footprints (https://github.com/cpavlina/kicad-pcblib) and modifying the scripts a bit (oops. Python was new to me) to get fabrication outlines, etc.
would you mind to share the scripts and the footprints?
The problem with github libraries is that there is not much qualified volunteers to work on it. The reason could be that if somebody has the time and skills to work on libraries he prefers using is on building his own libraries, not necessarily complying kicad library convention.
I’d like to suggest an approach to sharing libraries that I find more efficient:
create a webpage or thread on this forum that collects links to users libraries - authors will know where to share libraries and users will know where to look for them,
don’t create one public library with categories like resistors, transistors etc. - the top level division should be the author
author is free to choose his own rules but should specify them - more people will share if there will be no limitations like kicad library convention or IPC or using github or some specific license
some admin should verify quality of the works to avoid adding poor quality and undocumented libraries, also user ratings would be nice feature (or maybe this will reduce need to any maintaince).
Certainly, present database is the simplest possible line-segments.
Next step would be polylines, which keeps most as a single entity.
Next after that, is a simple block scheme, that allows group of not-polyline entities, with a common layer setting.
The Zone database comes close to managing this, so maybe Footprints can steal/expand on the Zone entities ?
That sounds like a good idea, what sort of text file format do you use ?
