I reported this: https://gitlab.com/kicad/code/kicad/-/issues/7254.
Oh no. That’s really cumbersome.
Could there be a new function check “touchesArea()”? This could be used for these tracks and pads. It doesn’t matter if the tracks can violate the edge clearance outside the footprint area because usually they aren’t routed along the edge when they start from the castellated pad. And they hardly go straight to another edge.
I checked and the code has different paths for zones and other items. Zones are “fully contained” while other items are “collide with”. I probably did it that way because our collision code is much faster than our “inside” code…
I think that’s probably OK for pads and vias. We could easily special-case tracks to check both endpoints (which still isn’t a “fully inside” check, but is probably good enough).
While I agree it’s probably not optimal for edge clearances, I really don’t want it to work differently for edge and copper clearances. And I think “both ends inside” makes more sense with copper clearances…
I like the idea of touchesArea() and changing the insideArea() code to require segments be fully inside (or at least both endpoints inside, ignoring width, as a performance optimization)
@eelik it doesn’t seem that cumbersome to me, you can also approach at an angle or just not use the co-linear cleanup functions. It seems like in your case you would just switch to touchesArea if we implement it, but in other cases where insideArea is actually what you want, you need to split up that track segment one way or another.
So I started playing around with KiCad 5.99 a few days ago (it just feels soooo much more usable than 5.0).
I’m currently on build 5.99.0-8711-gbabda304d9 and encountered a few issues with DRC rules:
The rule syntax help doesn’t have an example for a layer-specific rule, but judging by posts on this thread, it seems like this should work to enforce 5mil clearance on inner layers (for JLCPCB):
(rule "Inner layer track/space"
(layer In*.CU)
(constraint track_width (min 5mil))
(constraint clearance (min 5mil))
)
I’m not entirely sure whether it needs to be quoted (some posts here contradict the help dialog) or whether it supports wildcards, but removing that didn’t help either, nor did removing the constraints from the rule. As soon as the layer tag appears anywhere, Pcbnew fails to parse the rules and a rule syntax check ends up in an unhandled exception dialog (without any useful info).
It seems like this should be straightforward to reproduce, but let me know if you need further debugging from my side (is there a way to capture log output or something?)
It also appears that the only way to recover from this is to remove the offending rule manually from the .kicad_dru file, as any further attempts to re-open the board setup window will crash the entire KiCad process.
And a minor nitpick: The rule syntax help tells me about the existence of a version tag, but neither that it’s required nor what the expected value is (i.e. which version of the syntax is being described there). For the above I was using version 1.
Side question: Is it possible to just update the relevant parts of KiCad to track nightlies without having to re-download and install the whole parts library every day?
For Windows there is a …x86_64-lite.exe without the libraries. When installing you get the option to install demos and/or footprint wizzards or neither.
For other OSs I do not know.
The crash is a bug when trying to tell you the layer wasn’t recognized. (I’m about to merge a fix.)
The wildcard is fine, but Cu has a lowercase ‘u’.
FWIW, there are also inner and outer keywords so you don’t have to use wildcards for this – but you can and they should work.
We don’t have any code which looks at the version yet (as there’s only one), but “1” would be the safest to use.
Current nightly appears to crash if I have a condition containing
B.existsOnLayer(A.Layer)
with B being a pad and A a track.
Not sure if this is supposed to work or how to correctly handle the different pad types (SMT vs. PTH) in layer checks.
Something doesn’t appear to be working quite right, I’m gettting DRC errors about tracks on an outer layer for an inner layer rule.
How does KiCad determine what is an “inner” or “outer” layer?
Brute force:
static const PCB_LAYER_ID cu_internals[] = {
In1_Cu,
In2_Cu,
In3_Cu,
In4_Cu,
In5_Cu,
In6_Cu,
In7_Cu,
In8_Cu,
In9_Cu,
In10_Cu,
In11_Cu,
In12_Cu,
In13_Cu,
In14_Cu,
In15_Cu,
In16_Cu,
In17_Cu,
In18_Cu,
In19_Cu,
In20_Cu,
In21_Cu,
In22_Cu,
In23_Cu,
In24_Cu,
In25_Cu,
In26_Cu,
In27_Cu,
In28_Cu,
In29_Cu,
In30_Cu,
};
What’s the specific error you’re getting? (If it’s something about a hole, those are considered to go through all layers.)
I have an inner layer min track width 5mil rule and 3.5mil tracks on the bottom layer.
Appears to be handled correctly during on-line DRC (e.g. while laying out tracks), but generates a complaint in the DRC report.
If you could pare down the board to just the offending tracks and send me the whole project (so I get your rules as well), I can take a look at it.
You can either log a bug and post it there, or send it direct to jeff@rokeby.ie.
Just sent you an email with a simple reproducer project
I’ve fixed the bug. Should be in the next nightly…
2 Likes
Quick question: Is it possible to create a constraint, which enforces a certain distance between pads of different components, but not between pads belonging to the same component?
I haven’t been able to find a way to get hold of the pad’s parent component in the rule syntax.
Also, should vias be considered as plated holes by the rules? They do not seem to match A.Type == ‘hole’ && A.isPlated(). And if I grab them with A.Type == ‘via’, clearance checks seem to start at the outer end of the annular ring, not at the hole.
That seems to make it impossible to implement “plated hole to track” constraints in an accurate way (i.e. independent of annular ring size).
I’ve added a Parent property to pads, footprint text and footprint shapes.
Vias should match the plated hole test, so that sounds like a bug.
However, are you aware of the hole_clearance constraint? (It’s similar to clearance except that, well, it probably does what you want. 
)
What are the exact semantics hole_clearance?
Would I apply that to tracks to make them stay clear of holes?
Does it consider non-plated holes as well?
If I look at PCB manufacturer rules, they usually don’t seem to care much about NPTHs, but want to enforce clearance between PTHs and other copper (especially different-net copper and other PTHs), but what they actually mean is sometimes quite hard to decipher.
Speaking of vias, I’ve noticed that when I drag a via, it doesn’t highlight any DRC violations, just rejects the operation when I try to put it down. Unlike when I try to drag e.g. a footprint into a via, where the violation gets highlighted correctly.
I’ve also had a set of DRC rules at some point, which caused vias to be draggable to locations which would later fail DRC, suggesting that not all rules are being considered during the drag. However that appears to have stopped a while ago after some rule changes, I don’t know what exactly triggered it.
Oh, and when I am routing a track and place a via, after hitting + once, it only seems to consider some layers for track collisions on a 4-layer board. When I hit + a second time, it then refuses to place the via anywhere, even if there is nothing anywhere nearby.
I’m just tossing you some notes about inconsistencies that I’ve found while using nightlys for a few weeks, in case you hadn’t noticed these things. Most of them should be straightforward to reproduce, however if something isn’t obvious, please let me know so that I can prepare a reproducer project for you and verify that it’s still buggy in the latest nightly.
clearance tests copper-to-copper. It applies to plated holes when pads have been removed (for instance, on internal unconnected layers), but otherwise the hole part is normally overridden by the larger annular ring.
hole_clearance tests hole-edge-to-copper. It applies to all holes.
A bunch of bugs have been fixed in via placing (with the via tool); a bunch of bugs still exist in via dragging. I think most of them are logged…