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…
I wanted to know if it was possible to implement a rule made like this:
(rule "AC clearance"
(constraint clearance (min 5mm))
(condition "A.NetName == 'AC-F' && B.NetName == 'AC-N'")
)
To establish a minimum distance between two nets.
I’ve done some tests but I’m not getting results.
I tried to replace A.NetName with A.Net but no violations are found.
When you click on an item of each net and do a Clearance Resolution (Inspect menu) what does it report?
I misspelled the network name:
- I had used the one written on the track but it is not correct.
- I used what is displayed in the Net Classes window but I omitted the last character of the name.
I had never used the tool to check the clearence resolution is functional to determine if the rules are applied correctly.
Thank you
Yeah, the rule resolution inspectors are really handy, but most people don’t notice them. Not sure how to make them more visible…
It would be convenient to have the possibility to do the DRC test also inside the window where you write the rules as to check them you have to keep opening and closing the “Board Setup” window which is inexplicably slow to open.
Or make PcbNew usable with the “Board Setup” window open (better).
As for the inspection commands I believe it is only due to the fact that users are not currently using the custom system of rules yet.
But when the potential is sensed, the inspection controls will become familiar.
1 Like
Yeah, a non-modal rules editor is definitely on the list for 7.0. (Of course not everything survives the feature cuts…)
I’ve been playing with the custom DRC rules in the nightlies, and have come across a performance issue. Not sure if this is a bug or me doing something wrong, so I thought I would ask here.
Short version:
Running DRC on my board without any active custom rules takes about twenty seconds. With a single custom rule, it takes almost fifteen minutes (14:40 if you want to be specific) on an Apple M1; it took nearly twenty on an older i7 Mac. I don’t have a generic linux box handy to test there, unfortunately. It also seems to cause delays in interactive routing, zone filling, and possibly other areas.
The board is what I (someone new at this) would consider to be moderately complex: 4 layers, ~360 components, ~850 Vias, a few dozen differential pairs, half a dozen net classes, and a dozen or so filled zones.
I’ve seen this issue on a nightly from two weeks ago, and it’s still the same in a nightly from a couple of days ago. I hadn’t used it before that, so I don’t know if it might be a regression.
The rule I’m playing with is:
(version 1.0)
# Default neckdown
(rule "Courtyard Neckdown"
(constraint track_width (min 4mil))
(constraint clearance (min 5mil))
(condition "A.insideCourtyard('U*')"))
I’ve tried various other rules (including one that doesn’t call insideCourtyard()), and similar timings occur.
Is there something I’m missing that is causing the slowness, or is this a known issue or perhaps just a bug?
Please open an issue for this and attach your board if possible (you can mark it a confidential issue if you don’t want your board to be public).
Will do. Wasn’t sure it whether this was known or not, so I wanted to ask first before filing. 
It’s known that there are ways to use custom rules that will make things very expensive, however what you experience doesn’t sound normal at all, especially on a fast machine.