kicad-developers team mailing list archive

[Jeff Young <jeff@xxxxxxxxx>]

Hi Mark,

There are 4 or 5 bug fixes after the hash you’re using.  The one I just pushed is most likely to address your pad-to-pad DRC issue.

Cheers,
Jeff.


> On 21 May 2020, at 20:53, mdoesbur@xxxxxxxxx wrote:
> 
> Hello Jeff,
> 
> That works fine on the plane, but when I do a DRC check if fails on the
> pads of C1 and C2. I'm using cec857c0f49d4fd984a4095896306ff5d3a5930e,
> not sure if you changed anything after that.
> 
> To me the syntax is just fine, as long as these things can be specified
> correcly.
> 
> regards,
> 
> Mark.
> 
> 
> 
> Jeff Young <jeff@xxxxxxxxx> wrote:
> 
> 	Hi Mark,
> 	
> 	That???s expected.  The effective clearance is the largest specified in all rules that match.  Since both selectors match in the same-net case, the effective clearance is 1.3mm.
> 	
> 	There is a ???relaxed??? token to address this, which allows a higher-priority rule to relax a constraint.
> 	
> 	So try:
> 	
> 	(version 1)
> 	(selector (priority 150) (match_netclass "Net-(C1-Pad1)") (match_netclass "Net-(C1-Pad1)") (rule "0.2mm"))
> 	(selector (priority 100) (match_netclass "Net-(C1-Pad1)") (rule "1.3mm"))
> 	(rule "1.3mm" (clearance 1.3))
> 	(rule "0.2mm" (clearance relaxed 0.2))
> 	
> 	It???s worth noting that we???re not very happy with this syntax and are working on some other ways to address it.
> 	
> 	Cheers,
> 	Jeff.