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.
Issue submitted. Had to gzip the board; it’s a bit on the large side.
why don’t you want to add to kicad v6 graphical interface for custom netclass rule (especially contain CLEARANCE MATRIX ) ? like altium, like eagle cad, like mentor pads, like orcad ? to click
Has someone said they don’t want to add it?
A matrix can be implemented on top of the custom rule system, but not vice versa. The rule system is much more powerful and flexible. As far as I have understood there were two options: either a matrix with a GUI and then a backend dealing with the router and DRC, where the backend is probably the more complex part; or a rule language and more complex backend. It was decided that the better rule system was needed anyway. Now we already have the backend. Adding a matrix means adding a GUI which creates simple rules for the existing backend. So, now when we already have the backend, implementing a matrix for ease of use is almost trivial compared to implementing a matrix GUI + a custom backend.
But this doesn’t happen for v6 because the major features have been planned and decided, the feature freeze has gone already. This is necessary to keep even remote resemblance of a release schedule – otherwise we would never see the final v6 release. So, it can happen in v7 at the earliest.
Yeah, it’s worth noting that the 6.0 DRC system runs only rules; all the existing netclass values and keepout settings are compiled into rules behind the scenes.
A couple of syntax changes for all you guinea pigs:
isDiffPair()is no more. Use
ABtoken added. It should be used for
(In the interests of full disclosure I should mention that the expression evaluator knows what
isCoupledDiffPair() means and ignores the object token so whether you call it with
B won’t actually matter.)
I have a rule defined as follows:
(rule "Reinforced PRIMARY to BOUNDARY" (constraint clearance (min 5.5mm)) (condition "A.NetClass == 'PRIMARY*' && B.Layer == 'Margin'")) (rule "Reinforced PRIMARY to BOUNDARY" (constraint clearance (min 5.5mm)) (condition "B.NetClass == 'PRIMARY*' && A.Layer == 'Margin'"))
designed to keep copper of a certain net away from an area defined by a drawing on the “Margin” layer. During routing, the rule works fine however the DRC does not pick up violations if a pad with the PRIMARY netclass violates the rule. Do I need to use a different rule type of pads?
I think you want
clearance (for the constraint type).
I may have tried that (including hole_clearance) but I will give it a go again.
What is the difference between “clearance” and “edge_clearance”?
I see the different constraint types are listed in the syntax help file. Would it be possible to update the syntax help file with a brief description of the different constraint types?
clearance only checks items on the same layer.
edge_clearance checks between items on any layer and items on
Unfortunately using edge_clearance didn’t bring up DRC errors when I ran the check. As before, the rule is “active” as the constraint appears when attempting to route a trace from the pad but does not show a DRC error if the pad itself is too close.
Select the pad and the graphic object on the Margin layer. Go to the Inspect menu and select Clearance Resolution…
I get this:
Edge clearance resolution for: Through hole pad 1 of CON1 [netclass PRIMARY_AC] Line on Margin Checking board setup constraints; edge clearance: 0,6350 mm. Unconditional constraint applied. Checking rule Copper to Board Edge; edge clearance: 0,5080 mm. Checking rule condition "A.Layer == '*.Cu' && B.Layer == 'Edge.Cuts'". Condition not satisfied; rule ignored. Checking rule Copper to Board Edge; edge clearance: 0,5080 mm. Checking rule condition "B.Layer == '*.Cu' && A.Layer == 'Edge.Cuts'". Condition not satisfied; rule ignored. Checking rule Reinforced PRIMARY to BOUNDARY; edge clearance: 5,5000 mm. Checking rule condition "A.NetClass == 'PRIMARY*' && B.Layer == 'Margin'". Rule applied; overrides previous constraints. Checking rule Reinforced PRIMARY to BOUNDARY; edge clearance: 5,5000 mm. Checking rule condition "B.NetClass == 'PRIMARY*' && A.Layer == 'Margin'". Rule applied; overrides previous constraints. Resolved clearance: 5,5 mm.
Any suggestions? Is there something else I could try or perhaps I have an incorrect setting?
5.5mm is what you want, right?
So it’s come up with the right answer, but DRC isn’t reporting it? (Are you sure you don’t have that DRC violation severity set to “ignore”?)
I’ll check the severity settings.
I set every Severity setting to “Error” and it still doesn’t come up