Yup, and somehow KiCad needs to be able to offer the same control.
Valid question.
Rhetorical question: If a user specifies a PAD clearance, what are they trying to tell the tools ?
With finer pitch parts, the need for some trace necking control increases. That necking control needs to cover both trace width and clearance settings.
Maybe we need to wait to see what v6 does to solve this ?
What KiCad version are you using? (Basically you should always tell that when you ask something.)
I’m using KiCAD 4.0.7. Waiting eagerly for 5.x.
I don’t believe something like differing clearances per area or per trace has been added to v5. But there are plans to do it for v6. At least according to this mailing list message: https://lists.launchpad.net/kicad-developers/msg34781.html
It’s not a bug, just missing functionality. I’ve been fighting this for a year. I have a patch to fix this ready to go into version 5 but the small delay to the release of version 5 it would cause is not acceptable to the core developers. Not enough people are affected by it I guess.
I used the same work around you did.
Protip #2: net tie might work for you.
I’m not sure about 4.0.7, but in 5.0RC1 you can set clearances visible (as outlines) for the tracks and pads through Display preferences. At least you can easily see what’s actually causing the violation.
Well, then it should be in one of the nightlies at some point, right? 
Not until development on 6 starts, and not unless the core developers accept the approach. If there were more people that needed this I might have a chance of getting it into version 5 but so far it seems only a few people do complicated enough layouts to be affected by this.
Wayne rejected it not because it is not useful but because kicad is in feature freeze. (And it seems some developers had a more powerful feature in mind that might need a slightly different approach. So maybe kicad will benefit from a discussion here.)
Right now kicad is even farther ahead than a simple feature freeze. The first release candidate has been tagged. As your patch would change the file format this would mean that a file made by rc2 can’t be opened by rc1. That is just not how release candidates are supposed to be.
Even changes to the user interface are now problematic as the guys writing the documentation need something stability such that they can write the documentation for v5. (The docu should be finished before the official release.)
The time between rc1 release and the final release is mainly used to write the docu and to fix remaining bugs.
You would have had a chance getting it in v5 if you submitted your patch at least half a year ago. You are not the only developer who submitted a feature during feature freeze. Others have also been told that their patch goes too far. Their patches had much less impact then yours.
If the development team would be a bit larger it would be possible to branch away v5 and start developing v6 already. But a lack of manpower means the core team really needs to focus on v5.
Thanks for commenting. My understanding of the situation matches yours though I’d like to clarify a couple points.
I did not claim Wayne would reject it for any reason other than feature freeze. The stable release policy states that features can go in post feature freeze by exception. If I thought I had enough support for the feature from the community (what I lamented about earlier) then I would bug Wayne with the actual patch. But I don’t have that support and I have not bugged him. I’m aware how limited the resources are and have tried hard to not get in the way. As soon as 5 goes stable I’ll bring it up.
The file format tweak (https://lists.launchpad.net/kicad-developers/msg34779.html) is a different, very small patch. Furthermore, it does not change the file format in a breaking way. There would be no problem opening v5rc1 files. I will still try to get this added. There are a lot of good reasons why the patch may not be accepted, but the impact of it on my team is too big to not try.
Thanks for all the work you put into the libraries.
I think the basic idea that something which would serve only one customer would be added to the file format is problematic. Even if it would be easy to remove afterwards. Have you thought about a more general solution, like adding “custom-extension” attribute which would have text/text (key/value) pair? I don’t know about the file format, but if there can be many attributes with the same name, anyone could add any data to items and handle it as they wish. So, if your patch only enables the possibility of some new data by letting KiCad accept and ignore a certain attribute, why not make it so that anyone could use that for any purpose? That could be more interesting to the core developers.
It’s not a matter of not needing it or not doing “complicated enough” layouts, but rather having features like this, and several others that have been mentioned on this forum lately, thought through and implemented properly.
@1.21Gigawatts I get your point. Of course in my opinion what you see in the video has been carefully thought through and implemented properly. It slots in with the DRC system and the netclass system, both as it is now and with the additional heuristics being talked about as future stuff. It stays out of sight in the UI until users actually need and use it, so as to not complicate things for new users coming up the learning chain.
I do honestly believe that if enough users would benefit from it, it could go into version 5. But I only count a few so far that have voiced their need, and I have no intention of wasting the core developers time for that.
They say this
"- we are planning to overhaul the clearance/design rules system in V6.
Storing the clearance DIRECTLY for each track segment/via will conflict with any more sophisticated design rule management system."
I can see merit in clearance-by-segment, as it is easy to explain, but it is manually focused, and not compatible with Autorouters. If you rip-up a trace, the clearance info is lost.
Being manual in nature, it also consumes many mouse clicks, and is less compatible with more formal design rule definitions (which avoid operator over-rides)
Best to wait to see what the “overhaul the clearance/design rules system in V6” means - this thread is about PAD / PART clearance, which is useful to be able to mange with fine pitched parts.
Expanding that, a more general neck-down-rule would permit shove routing to exit fine pads, then use a default larger trace/clearance, but permit necking between pads.
@eelik I believe that code exactly like my file format patch will need to go into 6 (even if they do their own clearance thing and reject mine) so I prefer to think of it as an early code addition rather than something that serves only me and my team.
I thought about offering a patch like you describe. Because one has keep track of those key/value pairs (and where they are if you allow them to be anywhere in the hierarchy) and then rewrite them, the patch would be a good chunk of code and bigger than I felt comfortable trying to push into version 5.
I think user key/value pairs would be a good addition to the format.
Interesting idea. It would be fairly easy to have KiCad tolerate extensions, but the tricky bits come during edit and save.
How should Kicad preserve those extensions, if it does not understand them ?
In this suggested case, clearance info is optionally added/removed to segments during editing, but the file that results will only generate final valid copper plots in a segment-clearance-aware KiCad.
To get back to the original problem, did you check with visible clearance lines which one actually has too large clearance? Here in 5.0RC1+ it’s clearly the via, not pads. Pads obey the given pad clearance.
Can you make the vias smaller?
If the vias are already as small as allowed, you could cheat a bit. Create a footprint with only a round(ish or octagonal) non-pad copper area of the diameter of the needed via diameter. Make the via annular ring smaller and place the footprint on it. The non-pad footprint copper area doesn’t offend DRC. For the power plane part of the via you have to e.g. use a thicker via segment.
@eelik, I don’t think the problem is the via in this case because when the via would violate the real-time DRC, KiCAD refused to even draw the via and all I get is a trace that runs out from under the BGA. See my two photos in the earlier post. The via is being pushed away from the B2 pin. It is hard to tell in 4.0.7 which clearance is being used for any given pad or trace due to the inheritance, but by swapping clearance values in the net classes and footprint, it seems the problem is the pad. Here is another screenshot of routing a via between pads that are not connected (which belong to a different net class with a very small clearance). There is not problem and the via is snapping properly to the middle.
I just tested 4.0.7 in a virtual machine… looks like the clearance outlines are visible only in the Default view mode. So, switch to Default view mode for a while. Choose Preferences->Display->Show Track Clearance:Always and Footprints:Show pad clearance. Then post a new screenshot. I say this because for readers it’s so much easier to see with eyes than understand something written, and for you it’s easier to see it directly instead of playing with numbers.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
