I have a simple PCB coil made of a spiral on front side, from large diameter toward smaller, then a via in the center and a corresponding spiral in the same direction from inner to outer diameter on the back sile.
The footprint is completed by two pads on the outer edge.
Both spirals are routed with 0.15/0.15mm track width/spacing, while the reminder of the board is routed with 0.2mm clearance.
Making the final DRC I get clearance errors between the pads(via and the copper lines of the antenna with an actual 0mm (indeed the tracks start from the pad/via).
Other clerance errors are from the same pads/via and surrounding antenna spirals with an actual of 0.15mm which is indeed correct).
I tryed also to make a special rule:
(rule PCBCoil96
(constraint clearance (min 0mm))
(condition “A.getField(‘footprint’) == ‘StudioFerraris:PCBCoil96’”))
But still I get the same errors.
Any idea, either to change the footprint or the board rules to avoid these errors?
Thanks in advance.
I tryed also to generate a new pcb coil using the KiCAD Coil Creator | Hackaday.io project.
The result is actually very similar to mine (just a little larger), but is affetced by the same problems.
Here are the details:
You could start by posting the exact DRC messages.
I am guessing that the spiral is defined as graphics on a copper layer, and not as copper tracks.
Currently the workaround is to make the graphics a part of the pad by using the “Edit pad as graphics shape [Ctrl + e]” mode. I don’t have much experience with it, but I think that in it’s current implementation (KiCad V7.0.7) just entering and exiting that mode for a pad is enough to add overlapping graphics on a copper layer to that pad.
If you can’t figure it out, then upload your footprint so others can have a closer look at it.
If using DRC, it’s important to understand the correct settings for your design.
Some design aspects are not very manufacturable (and not all PCB makers will accept all parameters)
To help understand what aspects/paramters cause DRC Violations, it would be useful to do a little Test.
Consider the following Test as an Example of testing…
I drew some Tracks at different Widths
I Connected them only to reduce ‘Unconnected Errors’
I Set DRC violations and marched down the list with different settings and observed the Violations.
I left the DRC settings at those for the thinnest Track with the Smallest Via
Those settings are shown in screenshot. The Vias are tiny and difficult to see - Enlarged view of smallest is shown in last screenshot
A short explanation is that the component is a two terminal component from the schematic point of view, but is instead a giant short circuit from the PCB point of vew, so, the real trick is to declare the pads as part of a Net-Tie.
I didn’t think of it
Thanks again.
Mau.
You’ll find the final footprint here (in case someone else needs it)
It is a two layer 96 turns planar coil PCBCoil96.kicad_mod (36.7 KB)
Posting a single footprint here after it has been fixed is nice of you but it is not very useful. Within a few weeks it gets pushed down the topics list and not many people would see it after that.
It would be more useful if you contact the creator / maintainer of the plugin so it can be modified so it creates correct footprints.
Net ties are supposed to change in some future KiCad version. It started as a hack in which graphics was added between pads on a copper layer (and DRC did not recognize graphics on a copper layer). Later the the “net tie” keyword (with a space in it, who thought up that abomination for a keyword?) had to be added as a workaround when DRC became aware of graphics. A “real” implementation of net ties is progressing very slow, for more info see:
Hi paulvdh,
you are right, but earlier during this conversation I was not able to post any file, until the problem was solved.
I posted the file just because, in the future, someone with more search skills than me, may find this conversation and get the final footprint ready (and fixed).
And indeed I will send a request to the coder of the coil generator program to submit this same solution.
I don’t agree with that. The current implementation isn’t a hack. The feature enhancements are about widening the scope of net-ties and even making it possible to use other items than pads as net ties.
The current implementation still abuses graphics on a copper layer, needs the atrocious double word “net tie” and abuses pads for things for which pads should not be used (which makes net ties on inner layer difficult for example. It also needs a footprint to keep all the parts of a net tie together.
I don’t see why you think that is not a bunch of hacked together.
I (mostly) know how it grew into this, and it is quite usable as it is, but I do not consider it a “well thought out” way of doing things.
And someone with some time, willingness and focus to update the manual… The way net ties work is also still a little todo item:
Support for graphics on a copper layer is getting better. It went from completely ignored by DRC, to being recognized by DRC so you do not create accidental shorts, and I’ve read that in the next KiCad version you can even assign a net name to it, so apparently you can make it a part of a net.
Yay!!
A little bit later…
After examining a net tie in the footprint editor, I found it is in: Footprint Editor / File / Footprint Properties / Clearance Overrides and Settings (tab) / Net Ties which has a list of: Pad groups allowed to short different nets:
