We recently updated our KiCad coil generator to v2! You are now able to create coils on as many layers as you desire. It was a lot of work to get it working, but it does now.
I’ve seen a few posts in the last few weeks of people struggling with theaddon. The issue with the unplaceable coils has been resolved. There are still a few DRC errors that I’m unsure on how to fix, but the tool works and the generated coils also work like a charm.
I do know why this happens. We hack these coils in a footprint which results in a bunch of traces tied to “no net”. These then collide with other “no net” elements on the coil, like the vias for example. Therefore this error is unimportant, but still annoying.
Also we’re unable to place vias in the footprint. This is why we use through holes in place of them. Which is fine, but maybe a bit confusing for users.
First, you have to add pads to both ends of the coil to be able to connect tracks to the footprint, and these pads need numbers, or else you can not match the pins of a schematic symbol with the pads of the footprint.
I see that the older version uses numbered THT pads at the end:
I would prefer round SMT pads with the same diameter as the track, probably offset a bit from the track if the clearance in between the windings is very small, but more than 0.5 mm is probably not needed. But as you can see, KiCad recognizes the connection between the inductor pins in the schematic and the pads in the footprint, and draws ratsnest lines to C5.
In the older version, I do not get DRC errors at all. If there are DRC problems then defining the footprint as being a Net Tie may help. Net ties are created to short specific nets, and thus DRC does not complain about shorted pads.
I can not tell all details exactly, because I do not use net ties much, and the implementation details for net ties have changed a few times in different KiCad versions.
I had a short look at github, but don’t know (yet) how to install this manually. I did see this newer version goes creating footprint libraries. That is … unusual at the very best. I much prefer if the footprint is either just put on the PCB or in the footprint editor, and you leave library management to the user, just like for all other footprints.
And concerning the footprint name. It’s now called “coil1” on my system. The KLC (KiCad Library Convention) has some guidelines for encoding main dimensions of a footprint into it’s name. This can help for telling them apart if multiple of these PCB inductors are created in the same library. It also makes comparison with previously generated footprints easier.
For pad number 3.
DRC accepts it (for me at the moment), but Update PCB from Schematic [F8] complains about it. If you add an attribute for a test point pad or a Heatsink pad then update pcb does not complain about these.
We did add SMD pads, so that works. Like I said, the coils do work fine.
Works the same way with SMD pads. However it is actually a good idea to add an option to the menu to support both SMD and through hole pads. Noted!
You have the option to just place it in the PCB like you said, or to store it in a library to link it to a schematic symbol. Since we wanted to be able to directly place it in the PCB editor, while also only providing a single menu, we decided that this route would be probably be the best. Moreover there already is another addon that adds a footprint wizard, so for now we did not want to “copy” their solution.
The footprint name is defined by the user, they can name it however they like. Having a better automatically generated name would probably be a good idea, yes
I was trying to do it with V7 but failed those time, what doesn’t mean it was not possible.
A month ago I tried with V8 and I did it. It is done as KiCad allows. Probably in future it will be possible to be done better…
At the moment I don’t want to deal with manually installing plugins.
I am willing to help with testing (on Linux). Testing is also best done on a example project. If you create an example project with your newest coil generator and post it, then I can see what DRC thinks of it, and if there are any differences.
That is weird. Unless maybe it’s related to library creating and file handling. (As I already wrote, I would leave that to the standard interface myself). Maybe it’s related to the KiCad version.
You can install it via the “Plugin and Content Manager”. Thanks for your offering, but I have a windows, linux and a mac machine, so plenty of testing opportunities.
Yes, I used that to create the screenshot from the older version.
But I have some experience with KiCad and can give you hints about why some of the DRC errors are generated and how to fix them. In a test project, I can also manually modify the footprint to see how DRC behavior changes.
Thanks for your offer! I fixed the DRC issues, it was resolved with a net tie. I’m not sure why it didn’t throw these errors on my linux machine though.
I released version 2.1.0 and 2.1.1 today that clean up the plugin and also fix loads of bugs. I guess the update is live tomorrow. Thanks for your feedback!
I work at PC not connected with net (if there is a way of automatic loading from net it will not work).
My PC connected with net is Win7 at which I understand KiCad V8 will not work.
I have another Win10 PC with KiCad V8 and connected with net but not here but if there is no other way I can run it there but then I need to know how to copy it at my separated PC.
I’m not sure if it will work with KiCad 6, but KiCad 7 should be fine. You can download the zip from the release page and import it in the addon manager (see the readme file for a short tutorial on how to do that)