Re: [Kicad-developers] DRC rules panel

[Ben Ellis]

Neat, that'll be super useful

On Mon, Jul 20, 2020, 9:56 AM Jeff Young  wrote:

> To do syntax highlighting and code completion.
>
> > On 20 Jul 2020, at 14:41, Ben Ellis  wrote:
> >
> > Why are the DRC rules parsed w/ s-exprs as they're being typed instead
> of after? I just fixed a bug where typing ) without ( crashed the entire
> program
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules panel

[Jeff Young]

To do syntax highlighting and code completion.

> On 20 Jul 2020, at 14:41, Ben Ellis  wrote:
> 
> Why are the DRC rules parsed w/ s-exprs as they're being typed instead of 
> after? I just fixed a bug where typing ) without ( crashed the entire program
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[mdoesbur]

Hello Jeff,

I just checked and that doesn't seem to be the case here.

R1 /a0cec481-6d12-448f-86cc-c28b78945760
R2 /2b22cd25-9b07-4b44-9454-a447c5deb022
R3 /5728510b-9b66-4b52-a87f-214fd4df2e61
R4 /305018a5-34e0-410a-bff5-1eb7a79bc504
R5 /36178733-2e55-42eb-8e00-ab3976b16d92
R6 /17490a70-e00b-49eb-b458-1c72867c2424

The actual DRC violation involves R1,R2,R4 and R5 but is reported on R3.

regards,

Mark


Jeff Young  wrote:

Hi Mark,

We???ve seen something like that DRC error before.  I think it was 
because the two items (the reported item and the correct item) had the same 
UUID.  Can you check to see if that???s the case here?

Thanks,
Jeff.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[Jeff Young]

Hi Mark,

We’ve seen something like that DRC error before.  I think it was because the 
two items (the reported item and the correct item) had the same UUID.  Can you 
check to see if that’s the case here?

Thanks,
Jeff.

> On 4 Jun 2020, at 13:59, mdoes...@xs4all.nl wrote:
> 
> Hello Jeff,
> 
> I was using github instead of gitlab, this lags gitlab by a day it seems.
> The problem fixed with ae852e17f987b77e2acf141285edbbbdaf27548f.
> 
> I am not able to reproduce the overflow, but it seems it might be
> something else. The attached project does contain a DRC error, but the
> wrong pads are identified. The actual error is in the middle of the board,
> where Net-(R4-Pad2) and Net-(R1-Pad2) are too close. The reported error
> is between Net-(C2-Pad1) and Net-(C1-Pad2), the location of the error
> arrows are correct however. The violated constraint is also correct.
> 
> regards,
> 
> Mark
> 
> Jeff Young  wrote:
> 
>   Hi Mark,
>   
>   That???s 6 change-lists too early for the fix.  You need at least 
> d2cd4de280353b02ab66dab8e22e8da88415dc13.
>   
>   Cheers,
>   Jeff.
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[Nick Østergaard]

Erhm, ooh yeah, I sorta nuked the jenkins instance that performed the
mirroring... so I will need to fix that one of these days..

On Thu, 4 Jun 2020 at 14:59,  wrote:
>
> Hello Jeff,
>
> I was using github instead of gitlab, this lags gitlab by a day it seems.
> The problem fixed with ae852e17f987b77e2acf141285edbbbdaf27548f.
>
> I am not able to reproduce the overflow, but it seems it might be
> something else. The attached project does contain a DRC error, but the
> wrong pads are identified. The actual error is in the middle of the board,
> where Net-(R4-Pad2) and Net-(R1-Pad2) are too close. The reported error
> is between Net-(C2-Pad1) and Net-(C1-Pad2), the location of the error
> arrows are correct however. The violated constraint is also correct.
>
> regards,
>
> Mark
>
> Jeff Young  wrote:
>
> Hi Mark,
>
> That???s 6 change-lists too early for the fix.  You need at least 
> d2cd4de280353b02ab66dab8e22e8da88415dc13.
>
> Cheers,
> Jeff.
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[mdoesbur]

Hello Jeff,

I was using github instead of gitlab, this lags gitlab by a day it seems.
The problem fixed with ae852e17f987b77e2acf141285edbbbdaf27548f.

I am not able to reproduce the overflow, but it seems it might be
something else. The attached project does contain a DRC error, but the
wrong pads are identified. The actual error is in the middle of the board,
where Net-(R4-Pad2) and Net-(R1-Pad2) are too close. The reported error
is between Net-(C2-Pad1) and Net-(C1-Pad2), the location of the error
arrows are correct however. The violated constraint is also correct.

regards,

Mark

Jeff Young  wrote:

Hi Mark,

That???s 6 change-lists too early for the fix.  You need at least 
d2cd4de280353b02ab66dab8e22e8da88415dc13.

Cheers,
Jeff.
<>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[Jeff Young]

Hi Mark,

That’s 6 change-lists too early for the fix.  You need at least 
d2cd4de280353b02ab66dab8e22e8da88415dc13.

Cheers,
Jeff.

> On 4 Jun 2020, at 10:13, mdoes...@xs4all.nl wrote:
> 
> Hello Jeff,
> 
> I just tried version 9ff09aa784551264e89350368f61ed6b35266f7a, but
> it still fails. I tells me that it requires 1.3mm clearance, but both
> the hole and the track are in the "Net-(C1-Pad1)" netclass, which should
> only require 0.25mm. The plane clearances are as expected.
> 
> With this version I can fix the problem by changing the drc file to
> remove the default clearance of the netclass. So what I have now is:
> 
> 
> (selector (match_netclass "Net-(C1-Pad1)") (rule "1.3mm")) #  the "default" 
> rule
> (selector (match_netclass "Net-(C1-Pad1)") (match_netclass "Net-(C1-Pad1)") 
> (rule "Default"))
> 
> 
> If the "default" rule is removed everything is OK. Now obviously I can
> do this, but it has consequences for the number of drc-rules I need. For
> the big design I can constrain with 451 lines when I can use a default,
> if that's not possible I need 7437 lines.
> 
> There is also an overflow at some point. Two pads, one at (364, 218.5)
> and the other at (124.45, 50.4) are only 4.351mm apart according to the
> DRC check.  I'll create a testcase if you want me to.
> 
> regards,
> 
> Mark.
> 
> Jeff Young  wrote:
> 
>   Hi Mark,
>   
>   The hole clearance logic never got updated to pass both items (the 
> track and the hole).  It should work now.
>   
>   Cheers,
>   Jeff.


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[mdoesbur]

Hello Jeff,

I just tried version 9ff09aa784551264e89350368f61ed6b35266f7a, but
it still fails. I tells me that it requires 1.3mm clearance, but both
the hole and the track are in the "Net-(C1-Pad1)" netclass, which should
only require 0.25mm. The plane clearances are as expected.

With this version I can fix the problem by changing the drc file to
remove the default clearance of the netclass. So what I have now is:


(selector (match_netclass "Net-(C1-Pad1)") (rule "1.3mm")) #  the "default" rule
(selector (match_netclass "Net-(C1-Pad1)") (match_netclass "Net-(C1-Pad1)") 
(rule "Default"))


If the "default" rule is removed everything is OK. Now obviously I can
do this, but it has consequences for the number of drc-rules I need. For
the big design I can constrain with 451 lines when I can use a default,
if that's not possible I need 7437 lines.

There is also an overflow at some point. Two pads, one at (364, 218.5)
and the other at (124.45, 50.4) are only 4.351mm apart according to the
DRC check.  I'll create a testcase if you want me to.

regards,

Mark.

Jeff Young  wrote:

Hi Mark,

The hole clearance logic never got updated to pass both items (the 
track and the hole).  It should work now.

Cheers,
Jeff.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[Jeff Young]

Hi Mark,

The hole clearance logic never got updated to pass both items (the track and 
the hole).  It should work now.

Cheers,
Jeff.


> On 2 Jun 2020, at 22:27, mdoes...@xs4all.nl wrote:
> 
> Hello Jeff,
> 
> I've tried my big board and the clearances seem to work OK for planes.
> I still have to compare the gerbers and check if they are exactly as
> expected.
> 
> However I get a lot of clearance error on holes in the board, and am
> unable to solve this. I've attached an example project. There is a
> plane which has the correct clearance, there is a track in this plane
> as well. I don't expect this track to give a DRC error, but it does.
> 
> I've tried (match_type pth) and also hole but I cannot make the error
> disappear. Any help would be welcome.
> 
> regards,
> 
> Mark.
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[mdoesbur]

Hello Jeff,

I've tried my big board and the clearances seem to work OK for planes.
I still have to compare the gerbers and check if they are exactly as
expected.

However I get a lot of clearance error on holes in the board, and am
unable to solve this. I've attached an example project. There is a
plane which has the correct clearance, there is a track in this plane
as well. I don't expect this track to give a DRC error, but it does.

I've tried (match_type pth) and also hole but I cannot make the error
disappear. Any help would be welcome.

regards,

Mark.
<>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[Jeff Young]

Mark,

Yes, last selector.  Order of rules (at present) doesn’t matter.

No, we were not planning on keeping the separation, although we did discuss 
supporting named conditions.

Cheers,
Jeff.

> On 2 Jun 2020, at 13:00, mdoes...@xs4all.nl wrote:
> 
> Hello Jeff,
> 
> I assume in that case the last selector is applied and not the last
> rule, correct?
> 
> To be honest I prefer the selector/rule seperation, is that going to stay?
> 
> regards,
> 
> Mark.
> 
> Jeff Young  wrote:
> 
>   Hi Mark,
>   
>   The condition syntax was just a preview.  It???s not implemented yet.
>   
>   You???ll need to use the selector syntax for now.
>   
>   So, for instance:
>   
>   (selector (match_netclass "Net-(C1-Pad1)") (match_netclass 
> "Net-(C1-Pad1)???) (rule ???Min_Net-(C1-Pad1)")
>   
>   Cheers,
>   Jeff.


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[mdoesbur]

Hello Jeff,

I assume in that case the last selector is applied and not the last
rule, correct?

To be honest I prefer the selector/rule seperation, is that going to stay?

regards,

Mark.

Jeff Young  wrote:

Hi Mark,

The condition syntax was just a preview.  It???s not implemented yet.

You???ll need to use the selector syntax for now.

So, for instance:

(selector (match_netclass "Net-(C1-Pad1)") (match_netclass 
"Net-(C1-Pad1)???) (rule ???Min_Net-(C1-Pad1)")

Cheers,
Jeff.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[Jeff Young]

Hi Mark,

The condition syntax was just a preview.  It’s not implemented yet.

You’ll need to use the selector syntax for now.

So, for instance:

(selector (match_netclass "Net-(C1-Pad1)") (match_netclass "Net-(C1-Pad1)”) 
(rule “Min_Net-(C1-Pad1)")

Cheers,
Jeff.

> On 2 Jun 2020, at 11:05, mdoes...@xs4all.nl wrote:
> 
> I just tested the old simple testcase, the new rule file is:
> 
> 
> (rule "Max_Net-(C1-Pad1)"
>(constraint clearance (min 1.3mm))
>(condition "A.netclass == Net-(C1-Pad1)"))
> (rule "Min_Net-(C1-Pad1)"
>(constraint clearance (min 0.25mm))
>(condition "A.netclass == Net-(C1-Pad1) && B.netclass == 
> Net-(C1-Pad1)"))
> (rule "Max_Net-(R1-Pad2)"
>(constraint clearance (min 1.3mm))
>(condition "A.netclass == Net-(R1-Pad2)"))
> (rule "Min_Net-(R1-Pad2)"
>(constraint clearance (min 0.25mm))
>(condition "A.netclass == Net-(R1-Pad2) && B.netclass == 
> Net-(R1-Pad2)"))
> (rule "Max_Net-(R4-Pad2)"
>(constraint clearance (min 1.3mm))
>(condition "A.netclass == Net-(R4-Pad2)"))
> (rule "Min_Net-(R4-Pad2)"
>(constraint clearance (min 0.25mm))
>(condition "A.netclass == Net-(R4-Pad2) && B.netclass == 
> Net-(R4-Pad2)"))
> (rule "Specific_Net-(C1-Pad1)__Net-(R1-Pad2)"
>(constraint clearance (min 1.3mm))
>(condition "A.netclass == Net-(C1-Pad1) && B.netclass == 
> Net-(R1-Pad2)"))
> (rule "Specific_Net-(C1-Pad1)__Net-(R4-Pad2)"
>(constraint clearance (min 1.3mm))
>(condition "A.netclass == Net-(C1-Pad1) && B.netclass == 
> Net-(R4-Pad2)"))
> 
> 
> I'm probably completely missing the point, but everything seems to be
> constrained at 0.25mm clearance.
> 
> 
> regards,
> 
> Mark.


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[mdoesbur]

I just tested the old simple testcase, the new rule file is:


(rule "Max_Net-(C1-Pad1)"
(constraint clearance (min 1.3mm))
(condition "A.netclass == Net-(C1-Pad1)"))
(rule "Min_Net-(C1-Pad1)"
(constraint clearance (min 0.25mm))
(condition "A.netclass == Net-(C1-Pad1) && B.netclass == 
Net-(C1-Pad1)"))
(rule "Max_Net-(R1-Pad2)"
(constraint clearance (min 1.3mm))
(condition "A.netclass == Net-(R1-Pad2)"))
(rule "Min_Net-(R1-Pad2)"
(constraint clearance (min 0.25mm))
(condition "A.netclass == Net-(R1-Pad2) && B.netclass == 
Net-(R1-Pad2)"))
(rule "Max_Net-(R4-Pad2)"
(constraint clearance (min 1.3mm))
(condition "A.netclass == Net-(R4-Pad2)"))
(rule "Min_Net-(R4-Pad2)"
(constraint clearance (min 0.25mm))
(condition "A.netclass == Net-(R4-Pad2) && B.netclass == 
Net-(R4-Pad2)"))
(rule "Specific_Net-(C1-Pad1)__Net-(R1-Pad2)"
(constraint clearance (min 1.3mm))
(condition "A.netclass == Net-(C1-Pad1) && B.netclass == 
Net-(R1-Pad2)"))
(rule "Specific_Net-(C1-Pad1)__Net-(R4-Pad2)"
(constraint clearance (min 1.3mm))
(condition "A.netclass == Net-(C1-Pad1) && B.netclass == 
Net-(R4-Pad2)"))


I'm probably completely missing the point, but everything seems to be
constrained at 0.25mm clearance.


regards,

Mark.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[Jeff Young]

Hi Mark,

Rules are now evaluated in order: last one which matches wins.

Most of the time you won’t need priority, but if you do have two rules that 
match the same things, put the higher priority one later in the rules file.

Cheers,
Jeff.


> On 2 Jun 2020, at 09:41, mdoes...@xs4all.nl wrote:
> 
> Hello Jeff,
> 
> I tried to give the big board a new attempt, previously a lot of strange
> things happened which I quite couldn't figure out. I noticed the priority
> was no longer accepted. Can you give a quick update on the intended way
> the rules are supposed to be used?
> 
> regards,
> 
> Mark.


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[mdoesbur]

Hello Jeff,

I tried to give the big board a new attempt, previously a lot of strange
things happened which I quite couldn't figure out. I noticed the priority
was no longer accepted. Can you give a quick update on the intended way
the rules are supposed to be used?

regards,

Mark.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[mdoesbur]

Hello Jeff,

It works correctly with 4f14769ce1ca587f72b51024a71e12a97d9d42f8. I will
have to update the rules before I can check the big board. This will take
some time, I'll let you know the result.

regards,

Mark.

Jeff Young  wrote:

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.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[Jeff Young]

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, mdoes...@xs4all.nl 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  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.


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[mdoesbur]

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  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.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[Jeff Young]

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.


> On 21 May 2020, at 19:55, mdoes...@xs4all.nl wrote:
> 
> Hello Jeff,
> 
> I've tried to get the big board working, but I'm unable to set a default
> clearance on a netclass. What I want to achieve is that a certain netclass
> has a small clearance (0.2mm) with itself, but a large clearance to
> other netclasses, for example 5.5mm. For some netclasses I would like
> to set a smaller clearance. I've tried the following approach (with and 
> without
> priority, and in reverse priority). But in this case it always uses the 1.3mm,
> also within the netclass itself. I've attached the test project.
> 
> 
> (version 1)
> (selector (priority 100) (match_netclass "Net-(C1-Pad1)") (match_netclass 
> "Net-(C1-Pad1)") (rule "0.2mm"))
> (selector (priority 150) (match_netclass "Net-(C1-Pad1)") (rule "1.3mm"))
> (rule "1.3mm" (clearance 1.3))
> (rule "0.2mm" (clearance 0.2))
> 
> 
> regards,
> 
> Mark.
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[mdoesbur]

Hello Jeff,

I've tried to get the big board working, but I'm unable to set a default
clearance on a netclass. What I want to achieve is that a certain netclass
has a small clearance (0.2mm) with itself, but a large clearance to
other netclasses, for example 5.5mm. For some netclasses I would like
to set a smaller clearance. I've tried the following approach (with and without
priority, and in reverse priority). But in this case it always uses the 1.3mm,
also within the netclass itself. I've attached the test project.


(version 1)
(selector (priority 100) (match_netclass "Net-(C1-Pad1)") (match_netclass 
"Net-(C1-Pad1)") (rule "0.2mm"))
(selector (priority 150) (match_netclass "Net-(C1-Pad1)") (rule "1.3mm"))
(rule "1.3mm" (clearance 1.3))
(rule "0.2mm" (clearance 0.2))


regards,

Mark.
<>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[James Jackson]

Jeff,

A definite +1 for that from over here! Thanks for the clarification.

Yours,
James.

On Thu, May 21, 2020 at 1:33 PM Jeff Young  wrote:

> While the prototype is selector-based the “real” implementation is likely
> to be expression-based, so you’ll be able to say something like:
>
> (rule “my special rule” … (condition “A.net == B.net”))
>
> Cheers,
> Jeff.
>
>
> On 21 May 2020, at 12:19, James Jackson 
> wrote:
>
> Hi Jeff,
>
> The background is that I'm looking at a ruleset which has different rules
> depending on whether two neighbouring vias are in the same, or different,
> nets. Running the risk of 'feature creep', of course, I think the
> constraints can indeed be met by what is there, but I suppose my question
> (and apologies for think out loud - the nature of the beast!) can be
> considered as 'Can a rule be matched based on whether the two objects are
> in the same, or different, nets?' Of course, this could be done by matching
> all permutations and combinations of nets, but that would become a
> combinatorial nightmare!
>
> Yours,
> James.
>
>
> On Thu, May 21, 2020 at 11:29 AM Jeff Young  wrote:
>
>> Hi James,
>>
>> It sounds like you’re looking for hole-to-hole min.  That’s in the
>> existing constraints system in 5.99; you don’t need rules for that.
>>
>> Or does your hole-to-hole min depend on the specific via, specific
>> netclass, or something else?  (The current hole-to-hole min is board-wide.)
>>
>> Cheers,
>> Jeff
>>
>>
>> On 21 May 2020, at 10:54, James Jackson 
>> wrote:
>>
>> Hi Jeff,
>>
>> Many thanks for this - looks very powerful, and when it gets hooked in to
>> the PNS router will be killer. An issue I'm currently grappling with a
>> variety of rules considering placements around vias. Some rules require a
>> distance measured from the outside of the annular ring to a track (or
>> another annular ring outer edge), and some from the outside of a hole (i.e.
>> the inside of the annular ring) to the nearest other outside edge of a
>> hole. I suspect the former is achieved with what is currently there, but is
>> the latter possible? It's essentially a question of where via-to-via
>> measurements are made.
>>
>> Thanks,
>> James.
>>
>>
>>
>> On Sat, May 16, 2020 at 4:44 PM Jeff Young  wrote:
>>
>>> I’ve just merged a possible implementation of the DRC rules.  I’d like
>>> to get some feedback on it, and also some testing.  (Because the rules
>>> support such a wide range of possibilities it’s going to need a good deal
>>> of testing.)
>>>
>>> For now, it picks up DRC rules from a file named “drc-rules” in the
>>> project directory.
>>>
>>> There’s no GUI editor at present: use a text editor.
>>>
>>> Grammar is s-expr.  It generally follows the ideas set down here:
>>>
>>>
>>> https://docs.google.com/document/d/1qvCH9aHwCzp5qtKTna4jJXuloNU0b96gAxAHSKPuXpU
>>>
>>> with one major exception: I found the select-a-single-rule didn’t pan
>>> out.  You have to duplicate too much stuff in each rule for that.
>>>
>>> Also, because the DRC engine (and zone filler) don’t currently support
>>> min/opt/max the prototype implements min with Seth’s “relaxed” option.
>>>
>>> Top level is a list; first expression must be (version x) followed by
>>> any number of (selector…) and (rule…) expressions.
>>>
>>> /*
>>>  * Match tokens:
>>>  * match_netclass
>>>  * match_type
>>>  * match_layer
>>>  * match_all
>>>  * match_area  (not yet implemented with the exception of “$board”, 
>>> which matches everything)
>>>  *
>>>  * (selector (match_area "$board") (rule "OSHParkClass3") (priority 
>>> 100))
>>>  *
>>>  * (selector (match_netclass "HV") (rule "HV_internal"))
>>>  * (selector (match_netclass "HV") (match_layer "F_Cu") (rule 
>>> "HV_external"))
>>>  * (selector (match_netclass "HV") (match_layer "B_Cu") (rule 
>>> "HV_external"))
>>>  *
>>>  * (selector (match_netclass "HV") (match_netclass "HV") (rule "HV2HV"))
>>>  * (selector (match_netclass "HV") (match_netclass "HV") (match_layer 
>>> "F_Cu") (rule "HV2HV_external"))
>>>  * (selector (match_netclass "HV") (match_netclass "HV") (match_layer 
>>> "B_Cu") (rule "HV2HV_external"))
>>>  *
>>>  *   TODO: pads for connector pins or wire pads have even larger required 
>>> creepage clearances.  How to encode?
>>>  *   User attributes on parent footprint?
>>>  *
>>>  * (selector (match_netclass "HV") (match_type "pad") (match_netclass 
>>> "HV") (match_type "pad") (rule "pad2PadHV"))
>>>  *
>>>  * (selector (match_netclass "signal") (match_area "BGA") (rule 
>>> "neckdown"))
>>>  *
>>>  * Type tokens:
>>>  * track
>>>  * via
>>>  * micro_via
>>>  * blind_via
>>>  * pad
>>>  * zone
>>>  * text
>>>  * graphic
>>>  * board_edge
>>>  * hole
>>>  * npth
>>>  * pth
>>>  *
>>>  * Rule tokens:
>>>  * allow  (not yet implemented)
>>>  * clearance
>>>  * annulus_width
>>>  * track_width
>>>  * hole
>>>  *
>>>  * Rule modifiers:
>>>  

Re: [Kicad-developers] DRC rules

[Jeff Young]

While the prototype is selector-based the “real” implementation is likely to be 
expression-based, so you’ll be able to say something like:

(rule “my special rule” … (condition “A.net  == B.net 
”))

Cheers,
Jeff.


> On 21 May 2020, at 12:19, James Jackson  wrote:
> 
> Hi Jeff,
> 
> The background is that I'm looking at a ruleset which has different rules 
> depending on whether two neighbouring vias are in the same, or different, 
> nets. Running the risk of 'feature creep', of course, I think the constraints 
> can indeed be met by what is there, but I suppose my question (and apologies 
> for think out loud - the nature of the beast!) can be considered as 'Can a 
> rule be matched based on whether the two objects are in the same, or 
> different, nets?' Of course, this could be done by matching all permutations 
> and combinations of nets, but that would become a combinatorial nightmare!
> 
> Yours,
> James.
> 
> 
> On Thu, May 21, 2020 at 11:29 AM Jeff Young  > wrote:
> Hi James,
> 
> It sounds like you’re looking for hole-to-hole min.  That’s in the existing 
> constraints system in 5.99; you don’t need rules for that.
> 
> Or does your hole-to-hole min depend on the specific via, specific netclass, 
> or something else?  (The current hole-to-hole min is board-wide.)
> 
> Cheers,
> Jeff
> 
> 
>> On 21 May 2020, at 10:54, James Jackson > > wrote:
>> 
>> Hi Jeff,
>> 
>> Many thanks for this - looks very powerful, and when it gets hooked in to 
>> the PNS router will be killer. An issue I'm currently grappling with a 
>> variety of rules considering placements around vias. Some rules require a 
>> distance measured from the outside of the annular ring to a track (or 
>> another annular ring outer edge), and some from the outside of a hole (i.e. 
>> the inside of the annular ring) to the nearest other outside edge of a hole. 
>> I suspect the former is achieved with what is currently there, but is the 
>> latter possible? It's essentially a question of where via-to-via 
>> measurements are made.
>> 
>> Thanks,
>> James.
>> 
>> 
>> 
>> On Sat, May 16, 2020 at 4:44 PM Jeff Young > > wrote:
>> I’ve just merged a possible implementation of the DRC rules.  I’d like to 
>> get some feedback on it, and also some testing.  (Because the rules support 
>> such a wide range of possibilities it’s going to need a good deal of 
>> testing.)
>> 
>> For now, it picks up DRC rules from a file named “drc-rules” in the project 
>> directory.
>> 
>> There’s no GUI editor at present: use a text editor.
>> 
>> Grammar is s-expr.  It generally follows the ideas set down here:
>> 
>> https://docs.google.com/document/d/1qvCH9aHwCzp5qtKTna4jJXuloNU0b96gAxAHSKPuXpU
>>  
>> 
>> 
>> with one major exception: I found the select-a-single-rule didn’t pan out.  
>> You have to duplicate too much stuff in each rule for that.
>> 
>> Also, because the DRC engine (and zone filler) don’t currently support 
>> min/opt/max the prototype implements min with Seth’s “relaxed” option.
>> 
>> Top level is a list; first expression must be (version x) followed by any 
>> number of (selector…) and (rule…) expressions.
>> /*
>>  * Match tokens:
>>  * match_netclass
>>  * match_type
>>  * match_layer
>>  * match_all
>>  * match_area  (not yet implemented with the exception of “$board”, 
>> which matches everything)
>>  *
>>  * (selector (match_area "$board") (rule "OSHParkClass3") (priority 100))
>>  *
>>  * (selector (match_netclass "HV") (rule "HV_internal"))
>>  * (selector (match_netclass "HV") (match_layer "F_Cu") (rule 
>> "HV_external"))
>>  * (selector (match_netclass "HV") (match_layer "B_Cu") (rule 
>> "HV_external"))
>>  *
>>  * (selector (match_netclass "HV") (match_netclass "HV") (rule "HV2HV"))
>>  * (selector (match_netclass "HV") (match_netclass "HV") (match_layer 
>> "F_Cu") (rule "HV2HV_external"))
>>  * (selector (match_netclass "HV") (match_netclass "HV") (match_layer 
>> "B_Cu") (rule "HV2HV_external"))
>>  *
>>  *   TODO: pads for connector pins or wire pads have even larger required 
>> creepage clearances.  How to encode?
>>  *   User attributes on parent footprint?
>>  *
>>  * (selector (match_netclass "HV") (match_type "pad") (match_netclass 
>> "HV") (match_type "pad") (rule "pad2PadHV"))
>>  *
>>  * (selector (match_netclass "signal") (match_area "BGA") (rule 
>> "neckdown"))
>>  *
>>  * Type tokens:
>>  * track
>>  * via
>>  * micro_via
>>  * blind_via
>>  * pad
>>  * zone
>>  * text
>>  * graphic
>>  * board_edge
>>  * hole
>>  * npth
>>  * pth
>>  *
>>  * Rule tokens:
>>  * allow  (not yet implemented)
>>  * clearance
>>  * annulus_width
>>  * track_width
>>  * hole
>>  *
>>  * Rule modifiers:
>>  * 

Re: [Kicad-developers] DRC rules

[James Jackson]

Hi Jeff,

The background is that I'm looking at a ruleset which has different rules
depending on whether two neighbouring vias are in the same, or different,
nets. Running the risk of 'feature creep', of course, I think the
constraints can indeed be met by what is there, but I suppose my question
(and apologies for think out loud - the nature of the beast!) can be
considered as 'Can a rule be matched based on whether the two objects are
in the same, or different, nets?' Of course, this could be done by matching
all permutations and combinations of nets, but that would become a
combinatorial nightmare!

Yours,
James.


On Thu, May 21, 2020 at 11:29 AM Jeff Young  wrote:

> Hi James,
>
> It sounds like you’re looking for hole-to-hole min.  That’s in the
> existing constraints system in 5.99; you don’t need rules for that.
>
> Or does your hole-to-hole min depend on the specific via, specific
> netclass, or something else?  (The current hole-to-hole min is board-wide.)
>
> Cheers,
> Jeff
>
>
> On 21 May 2020, at 10:54, James Jackson 
> wrote:
>
> Hi Jeff,
>
> Many thanks for this - looks very powerful, and when it gets hooked in to
> the PNS router will be killer. An issue I'm currently grappling with a
> variety of rules considering placements around vias. Some rules require a
> distance measured from the outside of the annular ring to a track (or
> another annular ring outer edge), and some from the outside of a hole (i.e.
> the inside of the annular ring) to the nearest other outside edge of a
> hole. I suspect the former is achieved with what is currently there, but is
> the latter possible? It's essentially a question of where via-to-via
> measurements are made.
>
> Thanks,
> James.
>
>
>
> On Sat, May 16, 2020 at 4:44 PM Jeff Young  wrote:
>
>> I’ve just merged a possible implementation of the DRC rules.  I’d like to
>> get some feedback on it, and also some testing.  (Because the rules support
>> such a wide range of possibilities it’s going to need a good deal of
>> testing.)
>>
>> For now, it picks up DRC rules from a file named “drc-rules” in the
>> project directory.
>>
>> There’s no GUI editor at present: use a text editor.
>>
>> Grammar is s-expr.  It generally follows the ideas set down here:
>>
>>
>> https://docs.google.com/document/d/1qvCH9aHwCzp5qtKTna4jJXuloNU0b96gAxAHSKPuXpU
>>
>> with one major exception: I found the select-a-single-rule didn’t pan
>> out.  You have to duplicate too much stuff in each rule for that.
>>
>> Also, because the DRC engine (and zone filler) don’t currently support
>> min/opt/max the prototype implements min with Seth’s “relaxed” option.
>>
>> Top level is a list; first expression must be (version x) followed by any
>> number of (selector…) and (rule…) expressions.
>>
>> /*
>>  * Match tokens:
>>  * match_netclass
>>  * match_type
>>  * match_layer
>>  * match_all
>>  * match_area  (not yet implemented with the exception of “$board”, 
>> which matches everything)
>>  *
>>  * (selector (match_area "$board") (rule "OSHParkClass3") (priority 100))
>>  *
>>  * (selector (match_netclass "HV") (rule "HV_internal"))
>>  * (selector (match_netclass "HV") (match_layer "F_Cu") (rule 
>> "HV_external"))
>>  * (selector (match_netclass "HV") (match_layer "B_Cu") (rule 
>> "HV_external"))
>>  *
>>  * (selector (match_netclass "HV") (match_netclass "HV") (rule "HV2HV"))
>>  * (selector (match_netclass "HV") (match_netclass "HV") (match_layer 
>> "F_Cu") (rule "HV2HV_external"))
>>  * (selector (match_netclass "HV") (match_netclass "HV") (match_layer 
>> "B_Cu") (rule "HV2HV_external"))
>>  *
>>  *   TODO: pads for connector pins or wire pads have even larger required 
>> creepage clearances.  How to encode?
>>  *   User attributes on parent footprint?
>>  *
>>  * (selector (match_netclass "HV") (match_type "pad") (match_netclass 
>> "HV") (match_type "pad") (rule "pad2PadHV"))
>>  *
>>  * (selector (match_netclass "signal") (match_area "BGA") (rule 
>> "neckdown"))
>>  *
>>  * Type tokens:
>>  * track
>>  * via
>>  * micro_via
>>  * blind_via
>>  * pad
>>  * zone
>>  * text
>>  * graphic
>>  * board_edge
>>  * hole
>>  * npth
>>  * pth
>>  *
>>  * Rule tokens:
>>  * allow  (not yet implemented)
>>  * clearance
>>  * annulus_width
>>  * track_width
>>  * hole
>>  *
>>  * Rule modifiers:
>>  * relaxed
>>  *
>>  * (rule "HV" (clearance 200) (priority 200))
>>  * (rule "HV_external" (clearance 400) (priority 200))
>>  * (rule "HV2HV" (clearance 200) (priority 200))
>>  * (rule "HV2HV_external" (clearance 500) (priority 200))
>>  * (rule "pad2padHV" (clearance 500) (priority 200))
>>  *
>>  * (rule "signal" (clearance 20))   // implied 
>> priority of 1
>>  * (rule "neckdown" (clearance relaxed 15) (priority 2))
>>  *
>>  * (rule "allowMicrovias" (allow microvia))
>>  */
>>
>>
>> 

Re: [Kicad-developers] DRC rules

[Jeff Young]

Hi James,

It sounds like you’re looking for hole-to-hole min.  That’s in the existing 
constraints system in 5.99; you don’t need rules for that.

Or does your hole-to-hole min depend on the specific via, specific netclass, or 
something else?  (The current hole-to-hole min is board-wide.)

Cheers,
Jeff


> On 21 May 2020, at 10:54, James Jackson  wrote:
> 
> Hi Jeff,
> 
> Many thanks for this - looks very powerful, and when it gets hooked in to the 
> PNS router will be killer. An issue I'm currently grappling with a variety of 
> rules considering placements around vias. Some rules require a distance 
> measured from the outside of the annular ring to a track (or another annular 
> ring outer edge), and some from the outside of a hole (i.e. the inside of the 
> annular ring) to the nearest other outside edge of a hole. I suspect the 
> former is achieved with what is currently there, but is the latter possible? 
> It's essentially a question of where via-to-via measurements are made.
> 
> Thanks,
> James.
> 
> 
> 
> On Sat, May 16, 2020 at 4:44 PM Jeff Young  > wrote:
> I’ve just merged a possible implementation of the DRC rules.  I’d like to get 
> some feedback on it, and also some testing.  (Because the rules support such 
> a wide range of possibilities it’s going to need a good deal of testing.)
> 
> For now, it picks up DRC rules from a file named “drc-rules” in the project 
> directory.
> 
> There’s no GUI editor at present: use a text editor.
> 
> Grammar is s-expr.  It generally follows the ideas set down here:
> 
> https://docs.google.com/document/d/1qvCH9aHwCzp5qtKTna4jJXuloNU0b96gAxAHSKPuXpU
>  
> 
> 
> with one major exception: I found the select-a-single-rule didn’t pan out.  
> You have to duplicate too much stuff in each rule for that.
> 
> Also, because the DRC engine (and zone filler) don’t currently support 
> min/opt/max the prototype implements min with Seth’s “relaxed” option.
> 
> Top level is a list; first expression must be (version x) followed by any 
> number of (selector…) and (rule…) expressions.
> /*
>  * Match tokens:
>  * match_netclass
>  * match_type
>  * match_layer
>  * match_all
>  * match_area  (not yet implemented with the exception of “$board”, which 
> matches everything)
>  *
>  * (selector (match_area "$board") (rule "OSHParkClass3") (priority 100))
>  *
>  * (selector (match_netclass "HV") (rule "HV_internal"))
>  * (selector (match_netclass "HV") (match_layer "F_Cu") (rule 
> "HV_external"))
>  * (selector (match_netclass "HV") (match_layer "B_Cu") (rule 
> "HV_external"))
>  *
>  * (selector (match_netclass "HV") (match_netclass "HV") (rule "HV2HV"))
>  * (selector (match_netclass "HV") (match_netclass "HV") (match_layer 
> "F_Cu") (rule "HV2HV_external"))
>  * (selector (match_netclass "HV") (match_netclass "HV") (match_layer 
> "B_Cu") (rule "HV2HV_external"))
>  *
>  *   TODO: pads for connector pins or wire pads have even larger required 
> creepage clearances.  How to encode?
>  *   User attributes on parent footprint?
>  *
>  * (selector (match_netclass "HV") (match_type "pad") (match_netclass 
> "HV") (match_type "pad") (rule "pad2PadHV"))
>  *
>  * (selector (match_netclass "signal") (match_area "BGA") (rule 
> "neckdown"))
>  *
>  * Type tokens:
>  * track
>  * via
>  * micro_via
>  * blind_via
>  * pad
>  * zone
>  * text
>  * graphic
>  * board_edge
>  * hole
>  * npth
>  * pth
>  *
>  * Rule tokens:
>  * allow  (not yet implemented)
>  * clearance
>  * annulus_width
>  * track_width
>  * hole
>  *
>  * Rule modifiers:
>  * relaxed
>  *
>  * (rule "HV" (clearance 200) (priority 200))
>  * (rule "HV_external" (clearance 400) (priority 200))
>  * (rule "HV2HV" (clearance 200) (priority 200))
>  * (rule "HV2HV_external" (clearance 500) (priority 200))
>  * (rule "pad2padHV" (clearance 500) (priority 200))
>  *
>  * (rule "signal" (clearance 20))   // implied 
> priority of 1
>  * (rule "neckdown" (clearance relaxed 15) (priority 2))
>  *
>  * (rule "allowMicrovias" (allow microvia))
>  */
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : 

Re: [Kicad-developers] DRC rules

[James Jackson]

Hi Jeff,

Many thanks for this - looks very powerful, and when it gets hooked in to
the PNS router will be killer. An issue I'm currently grappling with a
variety of rules considering placements around vias. Some rules require a
distance measured from the outside of the annular ring to a track (or
another annular ring outer edge), and some from the outside of a hole (i.e.
the inside of the annular ring) to the nearest other outside edge of a
hole. I suspect the former is achieved with what is currently there, but is
the latter possible? It's essentially a question of where via-to-via
measurements are made.

Thanks,
James.



On Sat, May 16, 2020 at 4:44 PM Jeff Young  wrote:

> I’ve just merged a possible implementation of the DRC rules.  I’d like to
> get some feedback on it, and also some testing.  (Because the rules support
> such a wide range of possibilities it’s going to need a good deal of
> testing.)
>
> For now, it picks up DRC rules from a file named “drc-rules” in the
> project directory.
>
> There’s no GUI editor at present: use a text editor.
>
> Grammar is s-expr.  It generally follows the ideas set down here:
>
>
> https://docs.google.com/document/d/1qvCH9aHwCzp5qtKTna4jJXuloNU0b96gAxAHSKPuXpU
>
> with one major exception: I found the select-a-single-rule didn’t pan
> out.  You have to duplicate too much stuff in each rule for that.
>
> Also, because the DRC engine (and zone filler) don’t currently support
> min/opt/max the prototype implements min with Seth’s “relaxed” option.
>
> Top level is a list; first expression must be (version x) followed by any
> number of (selector…) and (rule…) expressions.
>
> /*
>  * Match tokens:
>  * match_netclass
>  * match_type
>  * match_layer
>  * match_all
>  * match_area  (not yet implemented with the exception of “$board”, which 
> matches everything)
>  *
>  * (selector (match_area "$board") (rule "OSHParkClass3") (priority 100))
>  *
>  * (selector (match_netclass "HV") (rule "HV_internal"))
>  * (selector (match_netclass "HV") (match_layer "F_Cu") (rule 
> "HV_external"))
>  * (selector (match_netclass "HV") (match_layer "B_Cu") (rule 
> "HV_external"))
>  *
>  * (selector (match_netclass "HV") (match_netclass "HV") (rule "HV2HV"))
>  * (selector (match_netclass "HV") (match_netclass "HV") (match_layer 
> "F_Cu") (rule "HV2HV_external"))
>  * (selector (match_netclass "HV") (match_netclass "HV") (match_layer 
> "B_Cu") (rule "HV2HV_external"))
>  *
>  *   TODO: pads for connector pins or wire pads have even larger required 
> creepage clearances.  How to encode?
>  *   User attributes on parent footprint?
>  *
>  * (selector (match_netclass "HV") (match_type "pad") (match_netclass 
> "HV") (match_type "pad") (rule "pad2PadHV"))
>  *
>  * (selector (match_netclass "signal") (match_area "BGA") (rule 
> "neckdown"))
>  *
>  * Type tokens:
>  * track
>  * via
>  * micro_via
>  * blind_via
>  * pad
>  * zone
>  * text
>  * graphic
>  * board_edge
>  * hole
>  * npth
>  * pth
>  *
>  * Rule tokens:
>  * allow  (not yet implemented)
>  * clearance
>  * annulus_width
>  * track_width
>  * hole
>  *
>  * Rule modifiers:
>  * relaxed
>  *
>  * (rule "HV" (clearance 200) (priority 200))
>  * (rule "HV_external" (clearance 400) (priority 200))
>  * (rule "HV2HV" (clearance 200) (priority 200))
>  * (rule "HV2HV_external" (clearance 500) (priority 200))
>  * (rule "pad2padHV" (clearance 500) (priority 200))
>  *
>  * (rule "signal" (clearance 20))   // implied 
> priority of 1
>  * (rule "neckdown" (clearance relaxed 15) (priority 2))
>  *
>  * (rule "allowMicrovias" (allow microvia))
>  */
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[Diego Herranz]

If the Inspect > Design Rules Checker dialog is going to be re-done, I'll
wait for that to happen and provide feedback if and when.

Thanks.

On Wed, 20 May 2020, 20:28 Jon Evans,  wrote:

> Copying and pasting Jeff's text from the forum since it wasn't in his
> original email to this list:
>
> "First the small text: the rule syntax WILL CHANGE. What’s there today is
> a PROTOTYPE. There will be NO TOOLS for migrating today’s rules to later
> rules. Think of it as a sandbox, not a work-in-progress."
>
> The kind of feedback we are most interested in at this point is around
> whether this kind of system can meet all your needs in terms of defining
> design rules.
>
> On Wed, May 20, 2020 at 3:24 PM Jon Evans  wrote:
>
>> You can file this as an issue if you'd like, but it's already planned to
>> completely re-do this UI at some point once we know what the actual DRC
>> implementation will be.
>>
>> We're not doing that yet because the new system is still very much in
>> flux.
>>
>> On Wed, May 20, 2020 at 3:22 PM Diego Herranz <
>> diegoherr...@diegoherranz.com> wrote:
>>
>>> Hi,
>>>
>>> It's nice getting a powerful rules system. Thank you for all the work.
>>>
>>> Just because it is slightly related to this. I find misleading that
>>> opening Inspect > Design Rules Checker, you get access to modify Minimum
>>> Track Width, Minimum via size and minimum uVia size. That is a subset of
>>> the Constraints in the revamped Board Setup dialog.
>>> Personally, I would remove them from Inspect > Design Rules Checker.
>>> If this was well received, let me know and I can raise a gitlab issue.
>>>
>>> Thanks,
>>> Diego
>>>
>>> On Wed, 20 May 2020 at 16:04, Evan Shultz  wrote:
>>>
 Awesome! Thanks Jeff!

 I'm just starting to look at this and I have something quick to mention
 regarding the UI: At Design Rules > Constraints in the 'Zone fill strategy'
 section, the options are two checkboxes but they appear to be
 mutually-exclusive. Should they be radio buttons instead?

 On Mon, May 18, 2020 at 12:21 PM  wrote:

> Excellent, now it works :-)
>
> I'll test the big board tomorrow. For me this was the most important
> feature missing from kicad, thanks for making it work.
>
> regards,
>
> Mark.
>
> Jeff Young  wrote:
>
> Congrats on the first bug!
>
> Actually 4 separate ones: the caching mechanism was causing
> the rules to not be loaded when the board was read, the zone cutout stuff
> wasn???t fully hooked up to the new rules engine, there???s no
> "Net-(C1-Pad2)" netclass in the document (only "Net-(C1-Pad1)???), and the
> code responded poorly to failing to find a net (putting subsequent nets
> off-by-one).
>
> The third one is yours. ;)
>
> Fixes for the other three are now in master (if you build your
> own); otherwise you can get them from tonight???s nightly.
>
> Cheers,
> Jeff.
>
> > On 18 May 2020, at 12:01, mdoes...@xs4all.nl wrote:
> >
> > Sorry, forgot to attach the project.
> >
> >
> > 
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[Jon Evans]

Copying and pasting Jeff's text from the forum since it wasn't in his
original email to this list:

"First the small text: the rule syntax WILL CHANGE. What’s there today is a
PROTOTYPE. There will be NO TOOLS for migrating today’s rules to later
rules. Think of it as a sandbox, not a work-in-progress."

The kind of feedback we are most interested in at this point is around
whether this kind of system can meet all your needs in terms of defining
design rules.

On Wed, May 20, 2020 at 3:24 PM Jon Evans  wrote:

> You can file this as an issue if you'd like, but it's already planned to
> completely re-do this UI at some point once we know what the actual DRC
> implementation will be.
>
> We're not doing that yet because the new system is still very much in flux.
>
> On Wed, May 20, 2020 at 3:22 PM Diego Herranz <
> diegoherr...@diegoherranz.com> wrote:
>
>> Hi,
>>
>> It's nice getting a powerful rules system. Thank you for all the work.
>>
>> Just because it is slightly related to this. I find misleading that
>> opening Inspect > Design Rules Checker, you get access to modify Minimum
>> Track Width, Minimum via size and minimum uVia size. That is a subset of
>> the Constraints in the revamped Board Setup dialog.
>> Personally, I would remove them from Inspect > Design Rules Checker.
>> If this was well received, let me know and I can raise a gitlab issue.
>>
>> Thanks,
>> Diego
>>
>> On Wed, 20 May 2020 at 16:04, Evan Shultz  wrote:
>>
>>> Awesome! Thanks Jeff!
>>>
>>> I'm just starting to look at this and I have something quick to mention
>>> regarding the UI: At Design Rules > Constraints in the 'Zone fill strategy'
>>> section, the options are two checkboxes but they appear to be
>>> mutually-exclusive. Should they be radio buttons instead?
>>>
>>> On Mon, May 18, 2020 at 12:21 PM  wrote:
>>>
 Excellent, now it works :-)

 I'll test the big board tomorrow. For me this was the most important
 feature missing from kicad, thanks for making it work.

 regards,

 Mark.

 Jeff Young  wrote:

 Congrats on the first bug!

 Actually 4 separate ones: the caching mechanism was causing the
 rules to not be loaded when the board was read, the zone cutout stuff
 wasn???t fully hooked up to the new rules engine, there???s no
 "Net-(C1-Pad2)" netclass in the document (only "Net-(C1-Pad1)???), and the
 code responded poorly to failing to find a net (putting subsequent nets
 off-by-one).

 The third one is yours. ;)

 Fixes for the other three are now in master (if you build your
 own); otherwise you can get them from tonight???s nightly.

 Cheers,
 Jeff.

 > On 18 May 2020, at 12:01, mdoes...@xs4all.nl wrote:
 >
 > Sorry, forgot to attach the project.
 >
 >
 > 

 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[Jon Evans]

You can file this as an issue if you'd like, but it's already planned to
completely re-do this UI at some point once we know what the actual DRC
implementation will be.

We're not doing that yet because the new system is still very much in flux.

On Wed, May 20, 2020 at 3:22 PM Diego Herranz 
wrote:

> Hi,
>
> It's nice getting a powerful rules system. Thank you for all the work.
>
> Just because it is slightly related to this. I find misleading that
> opening Inspect > Design Rules Checker, you get access to modify Minimum
> Track Width, Minimum via size and minimum uVia size. That is a subset of
> the Constraints in the revamped Board Setup dialog.
> Personally, I would remove them from Inspect > Design Rules Checker.
> If this was well received, let me know and I can raise a gitlab issue.
>
> Thanks,
> Diego
>
> On Wed, 20 May 2020 at 16:04, Evan Shultz  wrote:
>
>> Awesome! Thanks Jeff!
>>
>> I'm just starting to look at this and I have something quick to mention
>> regarding the UI: At Design Rules > Constraints in the 'Zone fill strategy'
>> section, the options are two checkboxes but they appear to be
>> mutually-exclusive. Should they be radio buttons instead?
>>
>> On Mon, May 18, 2020 at 12:21 PM  wrote:
>>
>>> Excellent, now it works :-)
>>>
>>> I'll test the big board tomorrow. For me this was the most important
>>> feature missing from kicad, thanks for making it work.
>>>
>>> regards,
>>>
>>> Mark.
>>>
>>> Jeff Young  wrote:
>>>
>>> Congrats on the first bug!
>>>
>>> Actually 4 separate ones: the caching mechanism was causing the
>>> rules to not be loaded when the board was read, the zone cutout stuff
>>> wasn???t fully hooked up to the new rules engine, there???s no
>>> "Net-(C1-Pad2)" netclass in the document (only "Net-(C1-Pad1)???), and the
>>> code responded poorly to failing to find a net (putting subsequent nets
>>> off-by-one).
>>>
>>> The third one is yours. ;)
>>>
>>> Fixes for the other three are now in master (if you build your
>>> own); otherwise you can get them from tonight???s nightly.
>>>
>>> Cheers,
>>> Jeff.
>>>
>>> > On 18 May 2020, at 12:01, mdoes...@xs4all.nl wrote:
>>> >
>>> > Sorry, forgot to attach the project.
>>> >
>>> >
>>> > 
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[Diego Herranz]

Hi,

It's nice getting a powerful rules system. Thank you for all the work.

Just because it is slightly related to this. I find misleading that opening
Inspect > Design Rules Checker, you get access to modify Minimum Track
Width, Minimum via size and minimum uVia size. That is a subset of the
Constraints in the revamped Board Setup dialog.
Personally, I would remove them from Inspect > Design Rules Checker.
If this was well received, let me know and I can raise a gitlab issue.

Thanks,
Diego

On Wed, 20 May 2020 at 16:04, Evan Shultz  wrote:

> Awesome! Thanks Jeff!
>
> I'm just starting to look at this and I have something quick to mention
> regarding the UI: At Design Rules > Constraints in the 'Zone fill strategy'
> section, the options are two checkboxes but they appear to be
> mutually-exclusive. Should they be radio buttons instead?
>
> On Mon, May 18, 2020 at 12:21 PM  wrote:
>
>> Excellent, now it works :-)
>>
>> I'll test the big board tomorrow. For me this was the most important
>> feature missing from kicad, thanks for making it work.
>>
>> regards,
>>
>> Mark.
>>
>> Jeff Young  wrote:
>>
>> Congrats on the first bug!
>>
>> Actually 4 separate ones: the caching mechanism was causing the
>> rules to not be loaded when the board was read, the zone cutout stuff
>> wasn???t fully hooked up to the new rules engine, there???s no
>> "Net-(C1-Pad2)" netclass in the document (only "Net-(C1-Pad1)???), and the
>> code responded poorly to failing to find a net (putting subsequent nets
>> off-by-one).
>>
>> The third one is yours. ;)
>>
>> Fixes for the other three are now in master (if you build your
>> own); otherwise you can get them from tonight???s nightly.
>>
>> Cheers,
>> Jeff.
>>
>> > On 18 May 2020, at 12:01, mdoes...@xs4all.nl wrote:
>> >
>> > Sorry, forgot to attach the project.
>> >
>> >
>> > 
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[Evan Shultz]

Awesome! Thanks Jeff!

I'm just starting to look at this and I have something quick to mention
regarding the UI: At Design Rules > Constraints in the 'Zone fill strategy'
section, the options are two checkboxes but they appear to be
mutually-exclusive. Should they be radio buttons instead?

On Mon, May 18, 2020 at 12:21 PM  wrote:

> Excellent, now it works :-)
>
> I'll test the big board tomorrow. For me this was the most important
> feature missing from kicad, thanks for making it work.
>
> regards,
>
> Mark.
>
> Jeff Young  wrote:
>
> Congrats on the first bug!
>
> Actually 4 separate ones: the caching mechanism was causing the
> rules to not be loaded when the board was read, the zone cutout stuff
> wasn???t fully hooked up to the new rules engine, there???s no
> "Net-(C1-Pad2)" netclass in the document (only "Net-(C1-Pad1)???), and the
> code responded poorly to failing to find a net (putting subsequent nets
> off-by-one).
>
> The third one is yours. ;)
>
> Fixes for the other three are now in master (if you build your
> own); otherwise you can get them from tonight???s nightly.
>
> Cheers,
> Jeff.
>
> > On 18 May 2020, at 12:01, mdoes...@xs4all.nl wrote:
> >
> > Sorry, forgot to attach the project.
> >
> >
> > 
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[mdoesbur]

Excellent, now it works :-)

I'll test the big board tomorrow. For me this was the most important
feature missing from kicad, thanks for making it work.

regards,

Mark.

Jeff Young  wrote:

Congrats on the first bug!

Actually 4 separate ones: the caching mechanism was causing the rules 
to not be loaded when the board was read, the zone cutout stuff wasn???t fully 
hooked up to the new rules engine, there???s no "Net-(C1-Pad2)" netclass in the 
document (only "Net-(C1-Pad1)???), and the code responded poorly to failing to 
find a net (putting subsequent nets off-by-one).

The third one is yours. ;)

Fixes for the other three are now in master (if you build your own); 
otherwise you can get them from tonight???s nightly.

Cheers,
Jeff.

> On 18 May 2020, at 12:01, mdoes...@xs4all.nl wrote:
> 
> Sorry, forgot to attach the project.
> 
> 
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[Jeff Young]

Congrats on the first bug!

Actually 4 separate ones: the caching mechanism was causing the rules to not be 
loaded when the board was read, the zone cutout stuff wasn’t fully hooked up to 
the new rules engine, there’s no "Net-(C1-Pad2)" netclass in the document (only 
"Net-(C1-Pad1)”), and the code responded poorly to failing to find a net 
(putting subsequent nets off-by-one).

The third one is yours. ;)

Fixes for the other three are now in master (if you build your own); otherwise 
you can get them from tonight’s nightly.

Cheers,
Jeff.

> On 18 May 2020, at 12:01, mdoes...@xs4all.nl wrote:
> 
> Sorry, forgot to attach the project.
> 
> 
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[mdoesbur]

Sorry, forgot to attach the project.


<>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[mdoesbur]

Hello Jeff,

Seems easy to reproduce, so here is a test project.  There are just two
netclasses and three nets. I expected the cutout in the zone to create
a 1.3mm clearance for Net-(R1-Pad2).

regards,

Mark.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[Jeff Young]

Hi Mark,

Clearances are in mm, so your clearances are *really* big.  At a guess I’d say 
all the clearances are overflow when we multiply them by mm-to-nm, but I’d 
think that would give random results not no results.

You shouldn’t need to set a priority unless you’re authoring a “relaxed” 
constraint (for instance, spacing can be decreased near a BGA).  But in any 
case (priority x) goes in the selector, not the rule.

I see some lines of the form: (match_netclass "Net-(R79-Pad2)”).  Did you 
create netclass to match the net names, or are you trying to match against a 
specific net?  (The later isn’t implemented, although maybe it needs to be.)

Let me know how it goes with smaller clearances.  If it still doesn’t work I 
may need a copy of your project to debug.

Cheers,
Jeff.


> On 18 May 2020, at 10:18, mdoes...@xs4all.nl wrote:
> 
> I've just tested this on a design and the drc-rules is read, which I
> know because if I don't add "(version 1)" at the first line I get an
> error message. Other than that I doesn't seem to do anything.
> 
> I tried to add "(priority 100)" to the rules, but that is refused when
> reading the drc file. It's also not clear to me what the clearance
> dimension is, so I assumed nanometers.
> 
> I've been using a hack to get clearance rules working for some time, so
> the design is already pretty large and uses 209 different netclasses. I
> did a clean built of 0658d297e528616e233b4074c27f1bdcb870dede,created
> drc-rules and edited the pcb file to create all the netclasses. I then
> loaded the board and rebuilt the planes, but all the rules seem to
> be ignored. I've attached the drc-rules file for reference.
> 
> regards,
> 
> Mark
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[mdoesbur]

I've just tested this on a design and the drc-rules is read, which I
know because if I don't add "(version 1)" at the first line I get an
error message. Other than that I doesn't seem to do anything.

I tried to add "(priority 100)" to the rules, but that is refused when
reading the drc file. It's also not clear to me what the clearance
dimension is, so I assumed nanometers.

I've been using a hack to get clearance rules working for some time, so
the design is already pretty large and uses 209 different netclasses. I
did a clean built of 0658d297e528616e233b4074c27f1bdcb870dede,created
drc-rules and edited the pcb file to create all the netclasses. I then
loaded the board and rebuilt the planes, but all the rules seem to
be ignored. I've attached the drc-rules file for reference.

regards,

Mark
(version 1)
(selector (match_netclass "+12V_ui") (match_netclass "+16P") (rule "5.5mm"))
(selector (match_netclass "+12V_ui") (match_netclass "+800V") (rule "5.5mm"))
(selector (match_netclass "+12V_ui") (match_netclass "+SOLAR") (rule "5.5mm"))
(selector (match_netclass "+12V_ui") (match_netclass "/battery/B+") (rule 
"5.5mm"))
(selector (match_netclass "+12V_ui") (match_netclass "/battery/B-") (rule 
"5.5mm"))
(selector (match_netclass "+12V_ui") (match_netclass 
"/battery/Flyback_control/DISABLE") (rule "5.5mm"))
(selector (match_netclass "+12V_ui") (match_netclass 
"/battery/Flyback_control/sw") (rule "5.5mm"))
(selector (match_netclass "+12V_ui") (match_netclass "/battery/M+") (rule 
"5.5mm"))
(selector (match_netclass "+12V_ui") (match_netclass "/battery/M-") (rule 
"5.5mm"))
(selector (match_netclass "+12V_ui") (match_netclass "/control/CAN1_N") (rule 
"1mm"))
(selector (match_netclass "+12V_ui") (match_netclass "Net-(J45-Pad1)") (rule 
"5.5mm"))
(selector (match_netclass "+12V_ui") (match_netclass "Net-(J46-Pad1)") (rule 
"5.5mm"))
(selector (match_netclass "+12V_ui") (match_netclass "Net-(J47-Pad1)") (rule 
"5.5mm"))
(selector (match_netclass "+12V_ui") (match_netclass "Net-(J48-Pad1)") (rule 
"5.5mm"))
(selector (match_netclass "+12V_ui") (match_netclass "Net-(R15-Pad2)") (rule 
"1.3mm"))
(selector (match_netclass "+12V_ui") (match_netclass "Net-(R25-Pad2)") (rule 
"1.3mm"))
(selector (match_netclass "+12V_ui") (match_netclass "Net-(R269-Pad2)") (rule 
"1.3mm"))
(selector (match_netclass "+12V_ui") (match_netclass "Net-(R270-Pad2)") (rule 
"1.3mm"))
(selector (match_netclass "+12V_ui") (match_netclass "Net-(R28-Pad2)") (rule 
"1.3mm"))
(selector (match_netclass "+12V_ui") (match_netclass "Net-(R306-Pad2)") (rule 
"1.3mm"))
(selector (match_netclass "+12V_ui") (match_netclass "Net-(R426-Pad2)") (rule 
"1.3mm"))
(selector (match_netclass "+12V_ui") (match_netclass "Net-(R429-Pad2)") (rule 
"1.3mm"))
(selector (match_netclass "+12V_ui") (match_netclass "Net-(R432-Pad2)") (rule 
"1.3mm"))
(selector (match_netclass "+12V_ui") (match_netclass "Net-(R435-Pad2)") (rule 
"1.3mm"))
(selector (match_netclass "+12V_ui") (match_netclass "Net-(R438-Pad2)") (rule 
"1.3mm"))
(selector (match_netclass "+12V_ui") (match_netclass "Net-(R440-Pad2)") (rule 
"1.3mm"))
(selector (match_netclass "+12V_ui") (match_netclass "Net-(R45-Pad2)") (rule 
"1.3mm"))
(selector (match_netclass "+12V_ui") (match_netclass "Net-(R78-Pad2)") (rule 
"1.3mm"))
(selector (match_netclass "+12V_ui") (match_netclass "Net-(R79-Pad2)") (rule 
"1.3mm"))
(selector (match_netclass "+16P") (match_netclass "+800V") (rule "2.4mm"))
(selector (match_netclass "+16P") (match_netclass "/NEUTRAL_out") (rule 
"1.3mm"))
(selector (match_netclass "+16P") (match_netclass "/Vin-") (rule "5.5mm"))
(selector (match_netclass "+16P") (match_netclass "/balancer/GH+") (rule 
"2.4mm"))
(selector (match_netclass "+16P") (match_netclass "/battery/B-") (rule "5.5mm"))
(selector (match_netclass "+16P") (match_netclass "/battery/Flyback/sw") (rule 
"5.5mm"))
(selector (match_netclass "+16P") (match_netclass "/battery/M+") (rule "5.5mm"))
(selector (match_netclass "+16P") (match_netclass "/battery/M-") (rule "2.4mm"))
(selector (match_netclass "+16P") (match_netclass "/flyback_mains/sw") (rule 
"5.5mm"))
(selector (match_netclass "+16P") (match_netclass "/half-bridge1/-5V_hs") (rule 
"2.4mm"))
(selector (match_netclass "+16P") (match_netclass "/half-bridge2/-5V_hs") (rule 
"2.4mm"))
(selector (match_netclass "+16P") (match_netclass "/half-bridge3/-5V_hs") (rule 
"2.4mm"))
(selector (match_netclass "+16P") (match_netclass "/solar0/hv") (rule "2.4mm"))
(selector (match_netclass "+16P") (match_netclass "/solar0/pf1") (rule "2.4mm"))
(selector (match_netclass "+16P") (match_netclass "/solar0/pf2") (rule "2.4mm"))
(selector (match_netclass "+16P") (match_netclass "/solar0/sw1") (rule "2.4mm"))
(selector (match_netclass "+16P") (match_netclass "/solar0/sw2") (rule "2.4mm"))
(selector (match_netclass "+16P") (match_netclass "/solar1/hv") (rule "2.4mm"))
(selector (match_netclass "+16P") (match_netclass "/solar1/pf1") (rule "2.4mm"))
(selector (match_netclass "+16P") (match_netclass 

Re: [Kicad-developers] DRC rules

[Jeff Young]

I got tired of my text editor not highlighting matching parens so there’s now a 
basic rule editor in Board Setup > Design Rules > Rules.

> On 16 May 2020, at 17:02, Jon Evans  wrote:
> 
> Thanks Jeff, this is awesome.  I look forward to trying it out.
> 
> On Sat, May 16, 2020 at 12:00 PM Jeff Young  > wrote:
> Here’s a really dumb test file just so you can get an idea of what it looks 
> like:
> 
> (version 1)
> (selector (match_netclass "Default") (rule "Big Gap"))
> (selector (match_type track) (rule "Big Gap"))
> (rule "Big Gap" (clearance 1.5))
> (selector (match_type blind_via) (rule "Big Hole"))
> (rule "Big Hole" (hole 2))
> (rule "Small Edge" (clearance 2))
> (rule "Big Edge" (clearance 3))
> (selector (match_type board_edge) (rule "Small Edge"))
> (selector (match_layer "In1.Cu") (match_type board_edge) (rule "Big Edge") 
> (priority 2))
> 
> 
>> On 16 May 2020, at 16:43, Jeff Young > > wrote:
>> 
>> I’ve just merged a possible implementation of the DRC rules.  I’d like to 
>> get some feedback on it, and also some testing.  (Because the rules support 
>> such a wide range of possibilities it’s going to need a good deal of 
>> testing.)
>> 
>> For now, it picks up DRC rules from a file named “drc-rules” in the project 
>> directory.
>> 
>> There’s no GUI editor at present: use a text editor.
>> 
>> Grammar is s-expr.  It generally follows the ideas set down here:
>> 
>> https://docs.google.com/document/d/1qvCH9aHwCzp5qtKTna4jJXuloNU0b96gAxAHSKPuXpU
>>  
>> 
>> 
>> with one major exception: I found the select-a-single-rule didn’t pan out.  
>> You have to duplicate too much stuff in each rule for that.
>> 
>> Also, because the DRC engine (and zone filler) don’t currently support 
>> min/opt/max the prototype implements min with Seth’s “relaxed” option.
>> 
>> Top level is a list; first expression must be (version x) followed by any 
>> number of (selector…) and (rule…) expressions.
>> /*
>>  * Match tokens:
>>  * match_netclass
>>  * match_type
>>  * match_layer
>>  * match_all
>>  * match_area  (not yet implemented with the exception of “$board”, 
>> which matches everything)
>>  *
>>  * (selector (match_area "$board") (rule "OSHParkClass3") (priority 100))
>>  *
>>  * (selector (match_netclass "HV") (rule "HV_internal"))
>>  * (selector (match_netclass "HV") (match_layer "F_Cu") (rule 
>> "HV_external"))
>>  * (selector (match_netclass "HV") (match_layer "B_Cu") (rule 
>> "HV_external"))
>>  *
>>  * (selector (match_netclass "HV") (match_netclass "HV") (rule "HV2HV"))
>>  * (selector (match_netclass "HV") (match_netclass "HV") (match_layer 
>> "F_Cu") (rule "HV2HV_external"))
>>  * (selector (match_netclass "HV") (match_netclass "HV") (match_layer 
>> "B_Cu") (rule "HV2HV_external"))
>>  *
>>  *   TODO: pads for connector pins or wire pads have even larger required 
>> creepage clearances.  How to encode?
>>  *   User attributes on parent footprint?
>>  *
>>  * (selector (match_netclass "HV") (match_type "pad") (match_netclass 
>> "HV") (match_type "pad") (rule "pad2PadHV"))
>>  *
>>  * (selector (match_netclass "signal") (match_area "BGA") (rule 
>> "neckdown"))
>>  *
>>  * Type tokens:
>>  * track
>>  * via
>>  * micro_via
>>  * blind_via
>>  * pad
>>  * zone
>>  * text
>>  * graphic
>>  * board_edge
>>  * hole
>>  * npth
>>  * pth
>>  *
>>  * Rule tokens:
>>  * allow  (not yet implemented)
>>  * clearance
>>  * annulus_width
>>  * track_width
>>  * hole
>>  *
>>  * Rule modifiers:
>>  * relaxed
>>  *
>>  * (rule "HV" (clearance 200) (priority 200))
>>  * (rule "HV_external" (clearance 400) (priority 200))
>>  * (rule "HV2HV" (clearance 200) (priority 200))
>>  * (rule "HV2HV_external" (clearance 500) (priority 200))
>>  * (rule "pad2padHV" (clearance 500) (priority 200))
>>  *
>>  * (rule "signal" (clearance 20))   // implied 
>> priority of 1
>>  * (rule "neckdown" (clearance relaxed 15) (priority 2))
>>  *
>>  * (rule "allowMicrovias" (allow microvia))
>>  */
>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> 
>> Post to : kicad-developers@lists.launchpad.net 
>> 
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> 
>> More help   : https://help.launchpad.net/ListHelp 
>> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : 

Re: [Kicad-developers] DRC rules

[Jon Evans]

Thanks Jeff, this is awesome.  I look forward to trying it out.

On Sat, May 16, 2020 at 12:00 PM Jeff Young  wrote:

> Here’s a really dumb test file just so you can get an idea of what it
> looks like:
>
> (version 1)
> (selector (match_netclass "Default") (rule "Big Gap"))
> (selector (match_type track) (rule "Big Gap"))
> (rule "Big Gap" (clearance 1.5))
> (selector (match_type blind_via) (rule "Big Hole"))
> (rule "Big Hole" (hole 2))
> (rule "Small Edge" (clearance 2))
> (rule "Big Edge" (clearance 3))
> (selector (match_type board_edge) (rule "Small Edge"))
> (selector (match_layer "In1.Cu") (match_type board_edge) (rule "Big Edge")
> (priority 2))
>
>
> On 16 May 2020, at 16:43, Jeff Young  wrote:
>
> I’ve just merged a possible implementation of the DRC rules.  I’d like to
> get some feedback on it, and also some testing.  (Because the rules support
> such a wide range of possibilities it’s going to need a good deal of
> testing.)
>
> For now, it picks up DRC rules from a file named “drc-rules” in the
> project directory.
>
> There’s no GUI editor at present: use a text editor.
>
> Grammar is s-expr.  It generally follows the ideas set down here:
>
>
> https://docs.google.com/document/d/1qvCH9aHwCzp5qtKTna4jJXuloNU0b96gAxAHSKPuXpU
>
> with one major exception: I found the select-a-single-rule didn’t pan
> out.  You have to duplicate too much stuff in each rule for that.
>
> Also, because the DRC engine (and zone filler) don’t currently support
> min/opt/max the prototype implements min with Seth’s “relaxed” option.
>
> Top level is a list; first expression must be (version x) followed by any
> number of (selector…) and (rule…) expressions.
>
> /*
>  * Match tokens:
>  * match_netclass
>  * match_type
>  * match_layer
>  * match_all
>  * match_area  (not yet implemented with the exception of “$board”, which 
> matches everything)
>  *
>  * (selector (match_area "$board") (rule "OSHParkClass3") (priority 100))
>  *
>  * (selector (match_netclass "HV") (rule "HV_internal"))
>  * (selector (match_netclass "HV") (match_layer "F_Cu") (rule 
> "HV_external"))
>  * (selector (match_netclass "HV") (match_layer "B_Cu") (rule 
> "HV_external"))
>  *
>  * (selector (match_netclass "HV") (match_netclass "HV") (rule "HV2HV"))
>  * (selector (match_netclass "HV") (match_netclass "HV") (match_layer 
> "F_Cu") (rule "HV2HV_external"))
>  * (selector (match_netclass "HV") (match_netclass "HV") (match_layer 
> "B_Cu") (rule "HV2HV_external"))
>  *
>  *   TODO: pads for connector pins or wire pads have even larger required 
> creepage clearances.  How to encode?
>  *   User attributes on parent footprint?
>  *
>  * (selector (match_netclass "HV") (match_type "pad") (match_netclass 
> "HV") (match_type "pad") (rule "pad2PadHV"))
>  *
>  * (selector (match_netclass "signal") (match_area "BGA") (rule 
> "neckdown"))
>  *
>  * Type tokens:
>  * track
>  * via
>  * micro_via
>  * blind_via
>  * pad
>  * zone
>  * text
>  * graphic
>  * board_edge
>  * hole
>  * npth
>  * pth
>  *
>  * Rule tokens:
>  * allow  (not yet implemented)
>  * clearance
>  * annulus_width
>  * track_width
>  * hole
>  *
>  * Rule modifiers:
>  * relaxed
>  *
>  * (rule "HV" (clearance 200) (priority 200))
>  * (rule "HV_external" (clearance 400) (priority 200))
>  * (rule "HV2HV" (clearance 200) (priority 200))
>  * (rule "HV2HV_external" (clearance 500) (priority 200))
>  * (rule "pad2padHV" (clearance 500) (priority 200))
>  *
>  * (rule "signal" (clearance 20))   // implied 
> priority of 1
>  * (rule "neckdown" (clearance relaxed 15) (priority 2))
>  *
>  * (rule "allowMicrovias" (allow microvia))
>  */
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[Jeff Young]

Here’s a really dumb test file just so you can get an idea of what it looks 
like:

(version 1)
(selector (match_netclass "Default") (rule "Big Gap"))
(selector (match_type track) (rule "Big Gap"))
(rule "Big Gap" (clearance 1.5))
(selector (match_type blind_via) (rule "Big Hole"))
(rule "Big Hole" (hole 2))
(rule "Small Edge" (clearance 2))
(rule "Big Edge" (clearance 3))
(selector (match_type board_edge) (rule "Small Edge"))
(selector (match_layer "In1.Cu") (match_type board_edge) (rule "Big Edge") 
(priority 2))


> On 16 May 2020, at 16:43, Jeff Young  wrote:
> 
> I’ve just merged a possible implementation of the DRC rules.  I’d like to get 
> some feedback on it, and also some testing.  (Because the rules support such 
> a wide range of possibilities it’s going to need a good deal of testing.)
> 
> For now, it picks up DRC rules from a file named “drc-rules” in the project 
> directory.
> 
> There’s no GUI editor at present: use a text editor.
> 
> Grammar is s-expr.  It generally follows the ideas set down here:
> 
> https://docs.google.com/document/d/1qvCH9aHwCzp5qtKTna4jJXuloNU0b96gAxAHSKPuXpU
>  
> 
> 
> with one major exception: I found the select-a-single-rule didn’t pan out.  
> You have to duplicate too much stuff in each rule for that.
> 
> Also, because the DRC engine (and zone filler) don’t currently support 
> min/opt/max the prototype implements min with Seth’s “relaxed” option.
> 
> Top level is a list; first expression must be (version x) followed by any 
> number of (selector…) and (rule…) expressions.
> /*
>  * Match tokens:
>  * match_netclass
>  * match_type
>  * match_layer
>  * match_all
>  * match_area  (not yet implemented with the exception of “$board”, which 
> matches everything)
>  *
>  * (selector (match_area "$board") (rule "OSHParkClass3") (priority 100))
>  *
>  * (selector (match_netclass "HV") (rule "HV_internal"))
>  * (selector (match_netclass "HV") (match_layer "F_Cu") (rule 
> "HV_external"))
>  * (selector (match_netclass "HV") (match_layer "B_Cu") (rule 
> "HV_external"))
>  *
>  * (selector (match_netclass "HV") (match_netclass "HV") (rule "HV2HV"))
>  * (selector (match_netclass "HV") (match_netclass "HV") (match_layer 
> "F_Cu") (rule "HV2HV_external"))
>  * (selector (match_netclass "HV") (match_netclass "HV") (match_layer 
> "B_Cu") (rule "HV2HV_external"))
>  *
>  *   TODO: pads for connector pins or wire pads have even larger required 
> creepage clearances.  How to encode?
>  *   User attributes on parent footprint?
>  *
>  * (selector (match_netclass "HV") (match_type "pad") (match_netclass 
> "HV") (match_type "pad") (rule "pad2PadHV"))
>  *
>  * (selector (match_netclass "signal") (match_area "BGA") (rule 
> "neckdown"))
>  *
>  * Type tokens:
>  * track
>  * via
>  * micro_via
>  * blind_via
>  * pad
>  * zone
>  * text
>  * graphic
>  * board_edge
>  * hole
>  * npth
>  * pth
>  *
>  * Rule tokens:
>  * allow  (not yet implemented)
>  * clearance
>  * annulus_width
>  * track_width
>  * hole
>  *
>  * Rule modifiers:
>  * relaxed
>  *
>  * (rule "HV" (clearance 200) (priority 200))
>  * (rule "HV_external" (clearance 400) (priority 200))
>  * (rule "HV2HV" (clearance 200) (priority 200))
>  * (rule "HV2HV_external" (clearance 500) (priority 200))
>  * (rule "pad2padHV" (clearance 500) (priority 200))
>  *
>  * (rule "signal" (clearance 20))   // implied 
> priority of 1
>  * (rule "neckdown" (clearance relaxed 15) (priority 2))
>  *
>  * (rule "allowMicrovias" (allow microvia))
>  */
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp