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 ?
The problem with rules… my experience with coding standards is that they are highly ineffective. If they are comprehensive, they are too unwieldy to use. A lot of the stuff is cosmetic, and not necessary to end performance.
Frequently, different conventions are contradictory, so clearly they are rules for the sake of it. Instead of making humans do what they are bad at, the only way to use rules effectively is to have tools that support them and do automated checking. The #1 thing for rules is that prevent errors in the final product, anything else is not that important.
In the open source case, rules are largely counter productive. You want lots of users to see and check the files, to do that you must accept them into the repo. Eating dog food can be unpleasant, but it is how to harness crowd sourcing.
KicadCloud has been around for a while (now dead?), and has a “free for all” approach. It has a few problems, e.g. awkward to find and use the parts. Often low quality, which is expected, but without efficient way to update parts, rate them etc.
I just cobbled something together for a specific set of connectors (two 164 way connectors…). It was worth writing code just to avoid doing that in the GUI. I got the text from a PDF, and then wrote a parser.
I like all that except the last bit. Relying on admins is what creates the bottleneck. Get the users to verify the quality!
Actually the forum software here gives a good example. It takes many years of experience with user-generate content sites and enables features for the community to manage itself. There is also wikipedia of course. Obviously wikipedia is quite flawed, but the amount of useful info there is vast, and it is largely free.
Yes, that would be the best to make some platform where people will add their libraries and the highest rated / most downloaded will be on top of the list (I guess the first places: 1. kicad github, 2. smisioto, 3. some ipc compliant stuff, >4 other people with their own libraries).
The approach would be to group content by author (author == set of rules). The contribbutors who made more libraries of better quality, keeping one convention, will win and then users will have easy access to their good libs in one place.
Unfortunately I won’t do that - no skills
Furthermore I created some footprints with the Library Expert program using (I hope) the latest JEDEC specs and compared them with the Kicad footprint:
The Kicad pads are 0.25x1.3mm, the IPC pads are 0.25x1.37mm. Not that much of a difference.
For resistors I see larger differences. IPC uses larger pads than the Kicad library.
And of course the results depend highly on the source: I have seen different JEDEC specs, all resulting in different pad sizes. And with every IPC version (currently C), the sizes differ also (different heel/toe calculations)…
So, creating standard footprints, while the standardization committee is changing the standards might be a lot of work
