Clearances are set by the netclass in KiCad, but I often need a different clearance at specific locations of the same net. Particularly when fanning out from a tight pitch BGA or QFN part, and sometimes when layout out power traces. I have heard that RF layouts need to do this also.
The only way you can do this right now is a bit of a hack. You can change the netclass clearance as you do your layout. DRC is no longer valid for nets that you do this to.
I have written a patch to KiCad that lets us set the clearance on the fly if needed. https://youtu.be/05vfAvYwDio
I’m posting here to see how many others besides myself would find this to be useful.
As a help forum people come and go so if you get little response it doesn’t mean much. I know this has come up at least one other time though. The place to go is launchpad. That’s where the developers are. If the code is written and doesn’t break anything then there may not be much resistance to adding it.
Settable clearances will be very handy for routing low voltage (ie 240VAC) boards. Especially when you are trying to break some clearance rules just for certain known areas.
One of the developers said this, but I don’t agree with him that storing clearance directly will conflict with a more sophisticated system, and I have not seen any other devs agree with him either.
Currently track width is automatic by netclass and yet being able to manually set the clearance when there is an exception that netclass can’t handle is something that you can do. My improvement only does the same with clearance. It does not prevent any more sophisticated automatic clearance heuristic from doing it’s thing. It just allows one to manually set the clearance when there is an exception to the rules.
Yes, and I can see the use case for that - it is simple to apply and explain, but also comes with caveats…
He is correct, any segment tagged clearance has to merge into the rule decision tree, and which rule wins ?
If the segment tag always wins, it has trumped the other rules.
It also is not compatible at all with Autorouters.
I can see use for a two-level clearance design, where you say
I prefer this clearance/trace width
I allow this clearance/trace width, in tight PAD locations (aka necking)
That rule is Autorouter compatible, and would cover most of your use example too, without the many-mouse-clicks dance ?
That is my mental approach to trace routing in general. It would be great if there was an automated neck-down algorithm that produced smooth, uniform, transitions from the preferred width & clearance rules, to the rules for tight PAD locations. Even better would be an algorithm that didn’t neck down more than necessary in a given location.
Yes, this could co-operate well with a tear-drop generator (various ones have been demonstrated).
An elastic neck choice is possible, but might need steps to avoid gerber file D code explosion ?
Perhaps a step-size or rounding rule could manage that ?
Besides fine-pitch-parts, another area where auto-necking would be useful is high current traces.
I think you may be think of this stuff in too narrow a context. The whole point of an exception is that it is not part of the rule decision tree. A manually set clearance is an exception, only used when the rules fail. Again, this is the same as trace width currently works, and that does not conflict with the more sophisticated netclass system, nor the ‘keep current width’ rule. I can’t quite picture the situation that would require the many-mouse-clicks so I can’t really speak to that without more info.
I know about path planning algorithms but not about the specifics of autorouters for electronics. Why do you think this is incompatible with autorouters? So far my code works fine with the Push n Shove autorouter already there as well as the DRC, with no change to the autorouting or drc code. But I definitely want to avoid future problems if there is an aspect of this I did not think of.
I hope it’s clear that I’m not suggesting that the current netclass, or more improved clearance setting heuristics, should not be used. This is just the little piece of the puzzle that sits underneath everything and a fallback when the user needs to do something the heuristic designers did not think of.
I agree, I can see a use case for this.
I can also see that the developers want to wait to do all “overhaul the clearance/design rules system in V6” & it would be logical to see then, if this can merge/co-exist with what else they have planned.
Great, this would really help in RF design where I often have 50 Ohm transmission lines that need a wide clearance. But at a pad of an ic package, the clearance is often violated.
I’d love to see this feature in the main branche.
Region based clearances are quickly becoming the feature at the top of my wish list. I having been doing quite a bit of uBGA exit routing and HV work (1kV to 6kV), and having location/region based clearances for routing and DRC would save a ton of time.
Can anyone point to the appropriate launchpad issues to flag and follow? I searched and thought I remember couple of items were already open on this issue, but struggled to find one covering it.
Yeah, there’s a bit more work that would need to happen. My patch only makes individual clearances possible and usable manually.
The dev team has plans to work on some sort of heuristic for clearances in 6. Whether they end up with area based, or have a matrix like you want, time will tell.
