Re: [Kicad-developers] Granularity of DRC error code

[Jeff Young]

It’ll work; there are just more special cases than there are non-special cases. 
 I felt it reduced the SNR, but I’m not against someone else giving it a go.

Are you doing it with the priority system we worked out?

> On 11 Jun 2020, at 21:43, Tomasz Wlostowski  wrote:
> 
> On 11/06/2020 22:27, Jeff Young wrote:
>> I had also originally planned on “compiling” the classic system into 
>> behind-the-scenes rules, but I don’t think that’s going to work out.  It’s 
>> pretty easy to agree on priority of all the edge case (pad override, 
>> footprint overrides, netclasses vs. board settings, etc.), but there’s 
>> nothing uniform about them.
> 
> Hi Jeff,
> 
> I'm actually coding it right now... Why do you think it will not work?
> 
> Tom


___
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] Granularity of DRC error code

[Tomasz Wlostowski]

On 11/06/2020 22:27, Jeff Young wrote:
> I had also originally planned on “compiling” the classic system into 
> behind-the-scenes rules, but I don’t think that’s going to work out.  It’s 
> pretty easy to agree on priority of all the edge case (pad override, 
> footprint overrides, netclasses vs. board settings, etc.), but there’s 
> nothing uniform about them.

Hi Jeff,

I'm actually coding it right now... Why do you think it will not work?

Tom

___
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] Granularity of DRC error code

[Jon Evans]

OK.  I think since we agreed to not remove the "basic" rules system,
it doesn't make sense to try to shoehorn it into the new rules engine.
The basic system makes some decisions that are pretty hard to undo
without blowing it up, so if we have the goal of preserving "classic"
behavior we should probably just accept that will mean a bit of extra
code complexity.

On Thu, Jun 11, 2020 at 4:27 PM Jeff Young  wrote:
>
> I had also originally planned on “compiling” the classic system into 
> behind-the-scenes rules, but I don’t think that’s going to work out.  It’s 
> pretty easy to agree on priority of all the edge case (pad override, 
> footprint overrides, netclasses vs. board settings, etc.), but there’s 
> nothing uniform about them.
>
> > On 11 Jun 2020, at 19:35, Jon Evans  wrote:
> >
> > That has yet to be determined, IIRC.  Jeff expressed a preference for
> > keeping around the current "basic rules" GUI we have, but that doesn't
> > answer whether those rules are internally represented in the new rules
> > engine or via a different path.
> >
> > I think it makes sense to express them as part of the new rules engine
> > internally so that we don't have two parallel paths of tests.  I don't
> > think it's a good idea to express them that way externally (i.e. put
> > them in a rules file as a template).
> >
> > For one, putting them in the file would break the proposed priority
> > system Jeff and I were talking about earlier, where netclass rules
> > beat/combine with basic rules and file rules beat netclass rules.
> > This would open back up that whole can of worms which I'd rather not
> > at this point :)
> >
> > So, I think what I'm suggesting is:
> >
> > - A way to assign a severity to each of the basic and netclass rules
> > (and also adding severity to the custom rules syntax)
> > - Decoupling severity from DRC error code
> > - Simplifying and consolidating DRC error codes as much as possible,
> > since now they will mostly just be categories for grouping things in
> > reports.
> >
> > I can handle these three things as part of the project settings branch
> > I'm working on now.  I do not want to try to tackle moving the basic
> > rules over to a new engine as part of that, but it could happen
> > afterwards.
> >
> > -Jon
> >
> >
> > On Thu, Jun 11, 2020 at 2:25 PM Ian McInerney  
> > wrote:
> >>
> >> I might have missed something, but how are the basic rules being 
> >> specified? Are we going to ship them as pre-built selectors that run 
> >> through the same DRC engine as the custom rules (so we only have one 
> >> engine to worry about), or are they being done differently? It would seem 
> >> better to ship them as pre-built selectors and use the same mechanisms for 
> >> specifying the severity of them as custom rules would. I think that is 
> >> also nicer, because it essentially provides an example rules file.
> >>
> >> -Ian
> >>
> >> On Thu, Jun 11, 2020 at 6:40 PM Jon Evans  wrote:
> >>>
> >>> Yeah I like this.
> >>>
> >>> For the basic rules, we could still make it so that each basic rule had 
> >>> independent severity while generating common error codes, although that 
> >>> increases complexity. It might be better to keep one error code per 
> >>> "basic" rule, except for the ones we are already in agreement can be 
> >>> consolidated.
> >>>
> >>> Then for net class and custom rules, we can just have the severity be a 
> >>> rule property, not an error code property.
> >>>
> >>> -Jon
> >>>
> >>> On Thu, Jun 11, 2020, 13:36 Ian McInerney  
> >>> wrote:
> 
>  Another example I just thought of (not involving costs): differential 
>  pair rules. We could have a category "Trace length mismatch" (or some 
>  other name...), and then someone could define rules such that:
>  Rule 1) If mismatch > x, flag the "Trace length mismatch" as an error
>  Rule 2) If mismatch > y, flag the "Trace length mismatch" as a warning
> 
>  When x > y and rule 1 is a higher priority, this can then basically 
>  allow for a zone for the DRC to flag the length mismatch where the 
>  design will still work, but is not ideal as a warning, and any larger 
>  values where the design would fail as an error.
> 
>  -Ian
> 
>  On Thu, Jun 11, 2020 at 6:25 PM Ian McInerney  
>  wrote:
> >>
> >> On Thu, Jun 11, 2020 at 1:13 PM Jeff Young  wrote:
> >>>
> >>> Imagine that violating the micro-via min bumps me up a classification 
> >>> but violating the through-via min drops me out of pooling.  There’s a 
> >>> big cost difference between those two.
> >>>
> >
> >
> > This is why I think switching to the severities coming from the rules 
> > would be a better way than defining them by the category of the 
> > violation. By doing that we can limit the need for a lot of categories 
> > of violations. We can for instance have a single code for "Minimum 
> > drill violated", and then have two different rules for 

Re: [Kicad-developers] Granularity of DRC error code

[Jeff Young]

I had also originally planned on “compiling” the classic system into 
behind-the-scenes rules, but I don’t think that’s going to work out.  It’s 
pretty easy to agree on priority of all the edge case (pad override, footprint 
overrides, netclasses vs. board settings, etc.), but there’s nothing uniform 
about them.

> On 11 Jun 2020, at 19:35, Jon Evans  wrote:
> 
> That has yet to be determined, IIRC.  Jeff expressed a preference for
> keeping around the current "basic rules" GUI we have, but that doesn't
> answer whether those rules are internally represented in the new rules
> engine or via a different path.
> 
> I think it makes sense to express them as part of the new rules engine
> internally so that we don't have two parallel paths of tests.  I don't
> think it's a good idea to express them that way externally (i.e. put
> them in a rules file as a template).
> 
> For one, putting them in the file would break the proposed priority
> system Jeff and I were talking about earlier, where netclass rules
> beat/combine with basic rules and file rules beat netclass rules.
> This would open back up that whole can of worms which I'd rather not
> at this point :)
> 
> So, I think what I'm suggesting is:
> 
> - A way to assign a severity to each of the basic and netclass rules
> (and also adding severity to the custom rules syntax)
> - Decoupling severity from DRC error code
> - Simplifying and consolidating DRC error codes as much as possible,
> since now they will mostly just be categories for grouping things in
> reports.
> 
> I can handle these three things as part of the project settings branch
> I'm working on now.  I do not want to try to tackle moving the basic
> rules over to a new engine as part of that, but it could happen
> afterwards.
> 
> -Jon
> 
> 
> On Thu, Jun 11, 2020 at 2:25 PM Ian McInerney  
> wrote:
>> 
>> I might have missed something, but how are the basic rules being specified? 
>> Are we going to ship them as pre-built selectors that run through the same 
>> DRC engine as the custom rules (so we only have one engine to worry about), 
>> or are they being done differently? It would seem better to ship them as 
>> pre-built selectors and use the same mechanisms for specifying the severity 
>> of them as custom rules would. I think that is also nicer, because it 
>> essentially provides an example rules file.
>> 
>> -Ian
>> 
>> On Thu, Jun 11, 2020 at 6:40 PM Jon Evans  wrote:
>>> 
>>> Yeah I like this.
>>> 
>>> For the basic rules, we could still make it so that each basic rule had 
>>> independent severity while generating common error codes, although that 
>>> increases complexity. It might be better to keep one error code per "basic" 
>>> rule, except for the ones we are already in agreement can be consolidated.
>>> 
>>> Then for net class and custom rules, we can just have the severity be a 
>>> rule property, not an error code property.
>>> 
>>> -Jon
>>> 
>>> On Thu, Jun 11, 2020, 13:36 Ian McInerney  wrote:
 
 Another example I just thought of (not involving costs): differential pair 
 rules. We could have a category "Trace length mismatch" (or some other 
 name...), and then someone could define rules such that:
 Rule 1) If mismatch > x, flag the "Trace length mismatch" as an error
 Rule 2) If mismatch > y, flag the "Trace length mismatch" as a warning
 
 When x > y and rule 1 is a higher priority, this can then basically allow 
 for a zone for the DRC to flag the length mismatch where the design will 
 still work, but is not ideal as a warning, and any larger values where the 
 design would fail as an error.
 
 -Ian
 
 On Thu, Jun 11, 2020 at 6:25 PM Ian McInerney  
 wrote:
>> 
>> On Thu, Jun 11, 2020 at 1:13 PM Jeff Young  wrote:
>>> 
>>> Imagine that violating the micro-via min bumps me up a classification 
>>> but violating the through-via min drops me out of pooling.  There’s a 
>>> big cost difference between those two.
>>> 
> 
> 
> This is why I think switching to the severities coming from the rules 
> would be a better way than defining them by the category of the 
> violation. By doing that we can limit the need for a lot of categories of 
> violations. We can for instance have a single code for "Minimum drill 
> violated", and then have two different rules for the minimum u-via drill 
> and the minimum through-via drill. Then those rules can treat the code 
> "Minimum drill violated" as either a warning or an error as they see fit.
> 
> -Ian
> 


___
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] Granularity of DRC error code

[Niki Guldbrand]

On Thu, 2020-06-11 at 11:51 +0100, Jeff Young wrote:

> But other things I’d be less in favour of.  I want a warning about
> NPTHs in courtyards; I don’t want one for PTHs (the former likely has
> a mechanical fixing, the later likely doesn't).

Will it be able to deferenciate between NPTH originating from a
footprint or a user added one ?
Because some footprints require/have a NPTH for alignment pins which is
which is part of the plastic housing.

--

Niki


___
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] Granularity of DRC error code

[Jon Evans]

That has yet to be determined, IIRC.  Jeff expressed a preference for
keeping around the current "basic rules" GUI we have, but that doesn't
answer whether those rules are internally represented in the new rules
engine or via a different path.

I think it makes sense to express them as part of the new rules engine
internally so that we don't have two parallel paths of tests.  I don't
think it's a good idea to express them that way externally (i.e. put
them in a rules file as a template).

For one, putting them in the file would break the proposed priority
system Jeff and I were talking about earlier, where netclass rules
beat/combine with basic rules and file rules beat netclass rules.
This would open back up that whole can of worms which I'd rather not
at this point :)

So, I think what I'm suggesting is:

- A way to assign a severity to each of the basic and netclass rules
(and also adding severity to the custom rules syntax)
- Decoupling severity from DRC error code
- Simplifying and consolidating DRC error codes as much as possible,
since now they will mostly just be categories for grouping things in
reports.

I can handle these three things as part of the project settings branch
I'm working on now.  I do not want to try to tackle moving the basic
rules over to a new engine as part of that, but it could happen
afterwards.

-Jon


On Thu, Jun 11, 2020 at 2:25 PM Ian McInerney  wrote:
>
> I might have missed something, but how are the basic rules being specified? 
> Are we going to ship them as pre-built selectors that run through the same 
> DRC engine as the custom rules (so we only have one engine to worry about), 
> or are they being done differently? It would seem better to ship them as 
> pre-built selectors and use the same mechanisms for specifying the severity 
> of them as custom rules would. I think that is also nicer, because it 
> essentially provides an example rules file.
>
> -Ian
>
> On Thu, Jun 11, 2020 at 6:40 PM Jon Evans  wrote:
>>
>> Yeah I like this.
>>
>> For the basic rules, we could still make it so that each basic rule had 
>> independent severity while generating common error codes, although that 
>> increases complexity. It might be better to keep one error code per "basic" 
>> rule, except for the ones we are already in agreement can be consolidated.
>>
>> Then for net class and custom rules, we can just have the severity be a rule 
>> property, not an error code property.
>>
>> -Jon
>>
>> On Thu, Jun 11, 2020, 13:36 Ian McInerney  wrote:
>>>
>>> Another example I just thought of (not involving costs): differential pair 
>>> rules. We could have a category "Trace length mismatch" (or some other 
>>> name...), and then someone could define rules such that:
>>> Rule 1) If mismatch > x, flag the "Trace length mismatch" as an error
>>> Rule 2) If mismatch > y, flag the "Trace length mismatch" as a warning
>>>
>>> When x > y and rule 1 is a higher priority, this can then basically allow 
>>> for a zone for the DRC to flag the length mismatch where the design will 
>>> still work, but is not ideal as a warning, and any larger values where the 
>>> design would fail as an error.
>>>
>>> -Ian
>>>
>>> On Thu, Jun 11, 2020 at 6:25 PM Ian McInerney  
>>> wrote:
>
> On Thu, Jun 11, 2020 at 1:13 PM Jeff Young  wrote:
> >
> > Imagine that violating the micro-via min bumps me up a classification 
> > but violating the through-via min drops me out of pooling.  There’s a 
> > big cost difference between those two.
> >


 This is why I think switching to the severities coming from the rules 
 would be a better way than defining them by the category of the violation. 
 By doing that we can limit the need for a lot of categories of violations. 
 We can for instance have a single code for "Minimum drill violated", and 
 then have two different rules for the minimum u-via drill and the minimum 
 through-via drill. Then those rules can treat the code "Minimum drill 
 violated" as either a warning or an error as they see fit.

 -Ian


___
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] Granularity of DRC error code

[Ian McInerney]

I might have missed something, but how are the basic rules being specified?
Are we going to ship them as pre-built selectors that run through the same
DRC engine as the custom rules (so we only have one engine to worry about),
or are they being done differently? It would seem better to ship them as
pre-built selectors and use the same mechanisms for specifying the severity
of them as custom rules would. I think that is also nicer, because it
essentially provides an example rules file.

-Ian

On Thu, Jun 11, 2020 at 6:40 PM Jon Evans  wrote:

> Yeah I like this.
>
> For the basic rules, we could still make it so that each basic rule had
> independent severity while generating common error codes, although that
> increases complexity. It might be better to keep one error code per "basic"
> rule, except for the ones we are already in agreement can be consolidated.
>
> Then for net class and custom rules, we can just have the severity be a
> rule property, not an error code property.
>
> -Jon
>
> On Thu, Jun 11, 2020, 13:36 Ian McInerney 
> wrote:
>
>> Another example I just thought of (not involving costs): differential
>> pair rules. We could have a category "Trace length mismatch" (or some other
>> name...), and then someone could define rules such that:
>> Rule 1) If mismatch > x, flag the "Trace length mismatch" as an error
>> Rule 2) If mismatch > y, flag the "Trace length mismatch" as a warning
>>
>> When x > y and rule 1 is a higher priority, this can then basically allow
>> for a zone for the DRC to flag the length mismatch where the design will
>> still work, but is not ideal as a warning, and any larger values where the
>> design would fail as an error.
>>
>> -Ian
>>
>> On Thu, Jun 11, 2020 at 6:25 PM Ian McInerney 
>> wrote:
>>
>>> On Thu, Jun 11, 2020 at 1:13 PM Jeff Young  wrote:
 >
 > Imagine that violating the micro-via min bumps me up a classification
 but violating the through-via min drops me out of pooling.  There’s a big
 cost difference between those two.
 >

>>>
>>> This is why I think switching to the severities coming from the rules
>>> would be a better way than defining them by the category of the violation.
>>> By doing that we can limit the need for a lot of categories of violations.
>>> We can for instance have a single code for "Minimum drill violated", and
>>> then have two different rules for the minimum u-via drill and the minimum
>>> through-via drill. Then those rules can treat the code "Minimum drill
>>> violated" as either a warning or an error as they see fit.
>>>
>>> -Ian
>>>
>>>
___
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] Granularity of DRC error code

[Jon Evans]

Yeah I like this.

For the basic rules, we could still make it so that each basic rule had
independent severity while generating common error codes, although that
increases complexity. It might be better to keep one error code per "basic"
rule, except for the ones we are already in agreement can be consolidated.

Then for net class and custom rules, we can just have the severity be a
rule property, not an error code property.

-Jon

On Thu, Jun 11, 2020, 13:36 Ian McInerney  wrote:

> Another example I just thought of (not involving costs): differential pair
> rules. We could have a category "Trace length mismatch" (or some other
> name...), and then someone could define rules such that:
> Rule 1) If mismatch > x, flag the "Trace length mismatch" as an error
> Rule 2) If mismatch > y, flag the "Trace length mismatch" as a warning
>
> When x > y and rule 1 is a higher priority, this can then basically allow
> for a zone for the DRC to flag the length mismatch where the design will
> still work, but is not ideal as a warning, and any larger values where the
> design would fail as an error.
>
> -Ian
>
> On Thu, Jun 11, 2020 at 6:25 PM Ian McInerney 
> wrote:
>
>> On Thu, Jun 11, 2020 at 1:13 PM Jeff Young  wrote:
>>> >
>>> > Imagine that violating the micro-via min bumps me up a classification
>>> but violating the through-via min drops me out of pooling.  There’s a big
>>> cost difference between those two.
>>> >
>>>
>>
>> This is why I think switching to the severities coming from the rules
>> would be a better way than defining them by the category of the violation.
>> By doing that we can limit the need for a lot of categories of violations.
>> We can for instance have a single code for "Minimum drill violated", and
>> then have two different rules for the minimum u-via drill and the minimum
>> through-via drill. Then those rules can treat the code "Minimum drill
>> violated" as either a warning or an error as they see fit.
>>
>> -Ian
>>
>>
___
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] Granularity of DRC error code

[Ian McInerney]

Another example I just thought of (not involving costs): differential pair
rules. We could have a category "Trace length mismatch" (or some other
name...), and then someone could define rules such that:
Rule 1) If mismatch > x, flag the "Trace length mismatch" as an error
Rule 2) If mismatch > y, flag the "Trace length mismatch" as a warning

When x > y and rule 1 is a higher priority, this can then basically allow
for a zone for the DRC to flag the length mismatch where the design will
still work, but is not ideal as a warning, and any larger values where the
design would fail as an error.

-Ian

On Thu, Jun 11, 2020 at 6:25 PM Ian McInerney 
wrote:

> On Thu, Jun 11, 2020 at 1:13 PM Jeff Young  wrote:
>> >
>> > Imagine that violating the micro-via min bumps me up a classification
>> but violating the through-via min drops me out of pooling.  There’s a big
>> cost difference between those two.
>> >
>>
>
> This is why I think switching to the severities coming from the rules
> would be a better way than defining them by the category of the violation.
> By doing that we can limit the need for a lot of categories of violations.
> We can for instance have a single code for "Minimum drill violated", and
> then have two different rules for the minimum u-via drill and the minimum
> through-via drill. Then those rules can treat the code "Minimum drill
> violated" as either a warning or an error as they see fit.
>
> -Ian
>
>
___
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] Granularity of DRC error code

[Ian McInerney]

> On Thu, Jun 11, 2020 at 1:13 PM Jeff Young  wrote:
> >
> > Imagine that violating the micro-via min bumps me up a classification
> but violating the through-via min drops me out of pooling.  There’s a big
> cost difference between those two.
> >
>

This is why I think switching to the severities coming from the rules would
be a better way than defining them by the category of the violation. By
doing that we can limit the need for a lot of categories of violations. We
can for instance have a single code for "Minimum drill violated", and then
have two different rules for the minimum u-via drill and the minimum
through-via drill. Then those rules can treat the code "Minimum drill
violated" as either a warning or an error as they see fit.

-Ian
___
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] Granularity of DRC error code

[Jeff Young]

Yeah, I want to know if the cost is going to increase (so it’s a warning), but 
I only want an error if it’s going to drop me out of pooling.

> On 11 Jun 2020, at 18:18, Jon Evans  wrote:
> 
> I guess we just think about this differently.  I would not use
> "errors" for anything that is a cost difference.  I would only use
> errors to mean "this can't be built at any cost from my preferred
> manufacturer" or "this design won't work if I try to build it"
> 
> On Thu, Jun 11, 2020 at 1:13 PM Jeff Young  wrote:
>> 
>> Imagine that violating the micro-via min bumps me up a classification but 
>> violating the through-via min drops me out of pooling.  There’s a big cost 
>> difference between those two.
>> 
>> 
>>> On 11 Jun 2020, at 16:47, Jon Evans  wrote:
>>> 
>>> Unconnected copper can also have electrical impacts.  I agree it makes
>>> sense to have some separation between copper and non-copper (not
>>> connected vs. non-connected).
>>> 
>>> I'm okay in general with the idea of trying to have different
>>> severities for production vs. design performance constraints and so
>>> on.  Keeping annulus separate from via diameter is fine.
>>> 
>>> Can you explain a situation where it makes sense to have e.g.
>>> through-via drill be a warning but uVia drill be an error or
>>> vice-versa?  This is what I don't understand.
>>> 
>>> On Thu, Jun 11, 2020 at 11:24 AM Jeff Young  wrote:
 
 I’d definitely want to set edge clearance apart from other clearance.
 
 And I’d definitely want to set connected-item clearance (an electrical 
 constraint) apart from non-connected-copper-item clearance (a production 
 constraint).
 
 And I’d definitely want different violations for via annulus (a production 
 constraint) and via size (possibly just a current/heat constraint).
 
 I’m still on the fence with throughVia drill vs. uVia drill.  The rest I 
 can agree with.
 
 Cheers,
 Jeff.
 
 
> On 11 Jun 2020, at 15:56, Jon Evans  wrote:
> 
> I think having fewer codes is something to strive for, especially
> since we are auto-generating severity options from the list of codes.
> 
> Having a bunch of severity settings where people wouldn't reasonably
> need to change them clutters the UI.
> 
> Having excessive categorization in the DRC window makes it harder to
> sort through that information (for me at least).
> 
> I don't think we need to be able to set severities independently for
> each rule in the "classic" system, we just need enough different
> severity settings to make sense.
> 
> For example, going down the classic DRC rules dialog:
> 
> Allowed features: both checkboxes generate DRCE_ALLOWED_FEATURES
> Arc/circle and zone fill: these aren't actually DRC checks
> Copper min clearance: generates DRCE_CLEARANCE
> Min track width: generates DRCE_WIDTH
> Min via annulus: generates DRCE_VIA_SIZE
> Min via diameter: generates DRCE_VIA_SIZE
> Copper edge clearance: generates DRCE_CLEARANCE
> Min through hole: generates DRCE_HOLE_SIZE
> Hole to hole: generates DRCE_HOLE_CLEARANCE
> uVia diameter: generates DRCE_VIA_SIZE
> uVia drill: generates DRCE_HOLE_SIZE
> 
> 
> 
> On Thu, Jun 11, 2020 at 10:42 AM Jeff Young  wrote:
>> 
>> What does that buy us?  The only things the error code gives us is a 
>> string and a severity.   The data storage (items, locations, etc.) is 
>> already completely orthogonal.
>> 
>>> On 11 Jun 2020, at 15:36, Jon Evans  wrote:
>>> 
>>> But couldn't this taxonomy be separate from the DRC_ITEM (i.e. error
>>> code) taxonomy?
>>> 
>>> For example you could have a "classic minimum clearance" severity 
>>> setting.
>>> This would set the severity of any DRCE_CLEARANCE items generated
>>> where the rule source is the classic system.
>>> This would replace all of the "X too close to Y" error codes
>>> 
>>> I think if we did this, the minimum set of error codes would look
>>> something like one error code per setting in the Constraints setup
>>> dialog.
>>> Maybe even smaller than that number of settings, because you can set
>>> separate numbers for vias and microvias and I still don't think you
>>> need separate severities for those.
>>> 
>>> On Thu, Jun 11, 2020 at 10:24 AM Jeff Young  wrote:
 
 (But I do like being able to assign a severity to a rule.)
 
 On 11 Jun 2020, at 15:22, Jeff Young  wrote:
 
 I think we’d still need some sort of taxonomy to put the severities on 
 for the “classic” system.
 
 On 11 Jun 2020, at 15:01, Ian McInerney  
 wrote:
 
 Why not make the severity attached to the rule being used instead of 
 the error code type. I think being able to say "this rule is very 
 important and should 

Re: [Kicad-developers] Granularity of DRC error code

[Jon Evans]

I guess we just think about this differently.  I would not use
"errors" for anything that is a cost difference.  I would only use
errors to mean "this can't be built at any cost from my preferred
manufacturer" or "this design won't work if I try to build it"

On Thu, Jun 11, 2020 at 1:13 PM Jeff Young  wrote:
>
> Imagine that violating the micro-via min bumps me up a classification but 
> violating the through-via min drops me out of pooling.  There’s a big cost 
> difference between those two.
>
>
> > On 11 Jun 2020, at 16:47, Jon Evans  wrote:
> >
> > Unconnected copper can also have electrical impacts.  I agree it makes
> > sense to have some separation between copper and non-copper (not
> > connected vs. non-connected).
> >
> > I'm okay in general with the idea of trying to have different
> > severities for production vs. design performance constraints and so
> > on.  Keeping annulus separate from via diameter is fine.
> >
> > Can you explain a situation where it makes sense to have e.g.
> > through-via drill be a warning but uVia drill be an error or
> > vice-versa?  This is what I don't understand.
> >
> > On Thu, Jun 11, 2020 at 11:24 AM Jeff Young  wrote:
> >>
> >> I’d definitely want to set edge clearance apart from other clearance.
> >>
> >> And I’d definitely want to set connected-item clearance (an electrical 
> >> constraint) apart from non-connected-copper-item clearance (a production 
> >> constraint).
> >>
> >> And I’d definitely want different violations for via annulus (a production 
> >> constraint) and via size (possibly just a current/heat constraint).
> >>
> >> I’m still on the fence with throughVia drill vs. uVia drill.  The rest I 
> >> can agree with.
> >>
> >> Cheers,
> >> Jeff.
> >>
> >>
> >>> On 11 Jun 2020, at 15:56, Jon Evans  wrote:
> >>>
> >>> I think having fewer codes is something to strive for, especially
> >>> since we are auto-generating severity options from the list of codes.
> >>>
> >>> Having a bunch of severity settings where people wouldn't reasonably
> >>> need to change them clutters the UI.
> >>>
> >>> Having excessive categorization in the DRC window makes it harder to
> >>> sort through that information (for me at least).
> >>>
> >>> I don't think we need to be able to set severities independently for
> >>> each rule in the "classic" system, we just need enough different
> >>> severity settings to make sense.
> >>>
> >>> For example, going down the classic DRC rules dialog:
> >>>
> >>> Allowed features: both checkboxes generate DRCE_ALLOWED_FEATURES
> >>> Arc/circle and zone fill: these aren't actually DRC checks
> >>> Copper min clearance: generates DRCE_CLEARANCE
> >>> Min track width: generates DRCE_WIDTH
> >>> Min via annulus: generates DRCE_VIA_SIZE
> >>> Min via diameter: generates DRCE_VIA_SIZE
> >>> Copper edge clearance: generates DRCE_CLEARANCE
> >>> Min through hole: generates DRCE_HOLE_SIZE
> >>> Hole to hole: generates DRCE_HOLE_CLEARANCE
> >>> uVia diameter: generates DRCE_VIA_SIZE
> >>> uVia drill: generates DRCE_HOLE_SIZE
> >>>
> >>>
> >>>
> >>> On Thu, Jun 11, 2020 at 10:42 AM Jeff Young  wrote:
> 
>  What does that buy us?  The only things the error code gives us is a 
>  string and a severity.   The data storage (items, locations, etc.) is 
>  already completely orthogonal.
> 
> > On 11 Jun 2020, at 15:36, Jon Evans  wrote:
> >
> > But couldn't this taxonomy be separate from the DRC_ITEM (i.e. error
> > code) taxonomy?
> >
> > For example you could have a "classic minimum clearance" severity 
> > setting.
> > This would set the severity of any DRCE_CLEARANCE items generated
> > where the rule source is the classic system.
> > This would replace all of the "X too close to Y" error codes
> >
> > I think if we did this, the minimum set of error codes would look
> > something like one error code per setting in the Constraints setup
> > dialog.
> > Maybe even smaller than that number of settings, because you can set
> > separate numbers for vias and microvias and I still don't think you
> > need separate severities for those.
> >
> > On Thu, Jun 11, 2020 at 10:24 AM Jeff Young  wrote:
> >>
> >> (But I do like being able to assign a severity to a rule.)
> >>
> >> On 11 Jun 2020, at 15:22, Jeff Young  wrote:
> >>
> >> I think we’d still need some sort of taxonomy to put the severities on 
> >> for the “classic” system.
> >>
> >> On 11 Jun 2020, at 15:01, Ian McInerney  
> >> wrote:
> >>
> >> Why not make the severity attached to the rule being used instead of 
> >> the error code type. I think being able to say "this rule is very 
> >> important and should be treated as an error" and "this rule is just a 
> >> guideline and can be treated as a warning" while they are both the 
> >> same error code would make more sense.
> >>
> >> -Ian
> >>
> >> On Thu, Jun 11, 2020 at 2:53 

Re: [Kicad-developers] Granularity of DRC error code

[Jeff Young]

Imagine that violating the micro-via min bumps me up a classification but 
violating the through-via min drops me out of pooling.  There’s a big cost 
difference between those two.


> On 11 Jun 2020, at 16:47, Jon Evans  wrote:
> 
> Unconnected copper can also have electrical impacts.  I agree it makes
> sense to have some separation between copper and non-copper (not
> connected vs. non-connected).
> 
> I'm okay in general with the idea of trying to have different
> severities for production vs. design performance constraints and so
> on.  Keeping annulus separate from via diameter is fine.
> 
> Can you explain a situation where it makes sense to have e.g.
> through-via drill be a warning but uVia drill be an error or
> vice-versa?  This is what I don't understand.
> 
> On Thu, Jun 11, 2020 at 11:24 AM Jeff Young  wrote:
>> 
>> I’d definitely want to set edge clearance apart from other clearance.
>> 
>> And I’d definitely want to set connected-item clearance (an electrical 
>> constraint) apart from non-connected-copper-item clearance (a production 
>> constraint).
>> 
>> And I’d definitely want different violations for via annulus (a production 
>> constraint) and via size (possibly just a current/heat constraint).
>> 
>> I’m still on the fence with throughVia drill vs. uVia drill.  The rest I can 
>> agree with.
>> 
>> Cheers,
>> Jeff.
>> 
>> 
>>> On 11 Jun 2020, at 15:56, Jon Evans  wrote:
>>> 
>>> I think having fewer codes is something to strive for, especially
>>> since we are auto-generating severity options from the list of codes.
>>> 
>>> Having a bunch of severity settings where people wouldn't reasonably
>>> need to change them clutters the UI.
>>> 
>>> Having excessive categorization in the DRC window makes it harder to
>>> sort through that information (for me at least).
>>> 
>>> I don't think we need to be able to set severities independently for
>>> each rule in the "classic" system, we just need enough different
>>> severity settings to make sense.
>>> 
>>> For example, going down the classic DRC rules dialog:
>>> 
>>> Allowed features: both checkboxes generate DRCE_ALLOWED_FEATURES
>>> Arc/circle and zone fill: these aren't actually DRC checks
>>> Copper min clearance: generates DRCE_CLEARANCE
>>> Min track width: generates DRCE_WIDTH
>>> Min via annulus: generates DRCE_VIA_SIZE
>>> Min via diameter: generates DRCE_VIA_SIZE
>>> Copper edge clearance: generates DRCE_CLEARANCE
>>> Min through hole: generates DRCE_HOLE_SIZE
>>> Hole to hole: generates DRCE_HOLE_CLEARANCE
>>> uVia diameter: generates DRCE_VIA_SIZE
>>> uVia drill: generates DRCE_HOLE_SIZE
>>> 
>>> 
>>> 
>>> On Thu, Jun 11, 2020 at 10:42 AM Jeff Young  wrote:
 
 What does that buy us?  The only things the error code gives us is a 
 string and a severity.   The data storage (items, locations, etc.) is 
 already completely orthogonal.
 
> On 11 Jun 2020, at 15:36, Jon Evans  wrote:
> 
> But couldn't this taxonomy be separate from the DRC_ITEM (i.e. error
> code) taxonomy?
> 
> For example you could have a "classic minimum clearance" severity setting.
> This would set the severity of any DRCE_CLEARANCE items generated
> where the rule source is the classic system.
> This would replace all of the "X too close to Y" error codes
> 
> I think if we did this, the minimum set of error codes would look
> something like one error code per setting in the Constraints setup
> dialog.
> Maybe even smaller than that number of settings, because you can set
> separate numbers for vias and microvias and I still don't think you
> need separate severities for those.
> 
> On Thu, Jun 11, 2020 at 10:24 AM Jeff Young  wrote:
>> 
>> (But I do like being able to assign a severity to a rule.)
>> 
>> On 11 Jun 2020, at 15:22, Jeff Young  wrote:
>> 
>> I think we’d still need some sort of taxonomy to put the severities on 
>> for the “classic” system.
>> 
>> On 11 Jun 2020, at 15:01, Ian McInerney  wrote:
>> 
>> Why not make the severity attached to the rule being used instead of the 
>> error code type. I think being able to say "this rule is very important 
>> and should be treated as an error" and "this rule is just a guideline 
>> and can be treated as a warning" while they are both the same error code 
>> would make more sense.
>> 
>> -Ian
>> 
>> On Thu, Jun 11, 2020 at 2:53 PM Jon Evans  wrote:
>>> 
>>> The only reasons to have multiple violation error codes is to be able
>>> to set a different severity for them, or to be able to filter/sort
>>> them.
>>> 
>>> I can't think of a situation in which I would want to do either of
>>> those things for different via types.
>>> 
>>> On Thu, Jun 11, 2020 at 9:48 AM Wayne Stambaugh  
>>> wrote:
 
 I was thinking along the same lines.  Wouldn't it make more sense to
 define the 

Re: [Kicad-developers] How do we envision Pad Stacks?

[Seth Hillbrand]

On 2020-06-11 08:35, Jeff Young wrote:

>> On 11 Jun 2020, at 16:16, Wayne Stambaugh  wrote: 
>> If not, we
>> need to create one to make sure we have it well defined before any
>> implementation can be done.
> 
> Just to be clear: I'm not looking at implementing it.  But I'd need to know 
> what direction we were moving in *if* I were to implement a WYSIWYG custom 
> pad editor. 
> 
> If we're going to allow a shape per layer, then it pretty much needs to be a 
> repurposed PCB_BASE_FRAME.  If we're going to do something like Altium then 
> we probably just want a canvas with shape tools and the point editor.

Hi Jeff- 

I think I'd vote for us doing something like Altium and allow the shape
to be assigned to one or multiple layers (outside of the shape editor). 
In that sense, I think we can use just the canvas with tools/editor. 
Once the shape is defined in this editor, we could allow it to be named
and used in multiple padstacks and multiple layers.  This makes a
clearer mapping to the various file formats that do implement padstacks.


-Seth

Seth Hillbrand
KiCad Services Corporation
https://www.kipro-pcb.com
+1 530 302 5483 | +1 212 603 9372___
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] How do we envision Pad Stacks?

[Rene Pöschl]

Hi, my answers below

On 11/06/2020 16:54, Jeff Young wrote:
I had been assuming that you could define a separate shape for each 
layer.  Full flexibility, but time-consuming to edit (even with 
commands such as “push current layer to other layers”).


One could have a simple mode and advanced mode. The simple mode allows 
defining your typical run of the mill stuff and the advanced mode gives 
full flexibility. In this case the simple mode could be the same shape 
on all layers and advanced mode would allow defining differing shapes on 
all layers.





Most users are looking to route traces on inner layers between tight 
pads.  This is commonly done with the definition of a “capture pad”. 
 The constraint on inner layers that have connecting tracks is simply 
not to have a butt joint between the track and the plated hole.  A 
capture pad is therefore a circular pad with an annulus width of the 
drill wander plus 1 or 2 mils; other capture pad shapes get you 
nothing more.


This sounds like a good idea in general. But especially for vias.




There were also a few requests for SMD pads on a single inner layer 
(or perhaps multiple) — but importantly not for different shapes on 
different layers.



SMD pads on a inner layer (or lets call them a "pad on the inside 
without a hole") make sense for some usecases. However currently they 
are mostly requested as a workaround for missing features. Like a lack 
of support of area defined layer differences (for example in rigid flex 
or 2.5D technology where some components are inset into the board) and 
even for net-ties. I suspect a lot of these workarounds will be made 
obsolete as kicad develops further.





So one could imagine allowing the pad shape to be placed on any number 
of layers, and a capture annulus width for any other connected layers. 
 While it doesn’t have same flexibility, it would be a /lot/ easier to 
edit.


This really only works if your base shape is circular. All current kicad 
THT footprints however have at least one non circular pad as we mark pad 
1 that way. (We use rounded rect or rect for this purpose)


And footprints meant for handsoldering are often made with elongated 
pads (oval pads).





Another possible complication is wanting a different shape for mask 
(or paste) layers.  Is this ever required?


Paste and mask layers can already be made different by having paste or 
mask only pads placed and removing these layers from the normal pad. I 
am not sure we win much by having this as part of a single pad but can 
see the appeal.


There is however something that would be awesome. If such a feature 
could also create split paste pads and allow specifying the amount of 
paste coverage then this feature would make a lot of sense especially if 
the user can then easily change the coverage during the layout phase. 
Even better would be if it could also add "vias" in some limited grid 
patterns and have paste avoid being placed on top of them (or have every 
paste section be influenced in the same manner by vias created that way 
for consistency) then this would be even more powerful. However i would 
assume this is more than a simple pad stack feature.


As an inspration take a look at the exposed pad class of our footprint 
generator: 
https://github.com/pointhi/kicad-footprint-generator/blob/master/KicadModTree/nodes/specialized/ExposedPad.py 
and for resulting footprints take any QFN footprint generated. One good 
example from the official lib is 
QFN-76-1EP_9x9mm_P0.4mm_EP3.8x3.8mm_ThermalVias


And regarding mask. well in most cases clearance specification is 
enough. But especially for mask defined pads clearance is not really the 
setting one cares about. So a way to enter the requested final size 
would help a lot here (right now we workaround here by making a mask 
only pad that allows us to enter the required final size).


Where true mask control could come in handy would be a top tenting 
option for vias inside a center (or exposed) pad (i think cypress still 
suggests top tenting in their application notes).



___
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] Granularity of DRC error code

[Jon Evans]

Unconnected copper can also have electrical impacts.  I agree it makes
sense to have some separation between copper and non-copper (not
connected vs. non-connected).

I'm okay in general with the idea of trying to have different
severities for production vs. design performance constraints and so
on.  Keeping annulus separate from via diameter is fine.

Can you explain a situation where it makes sense to have e.g.
through-via drill be a warning but uVia drill be an error or
vice-versa?  This is what I don't understand.

On Thu, Jun 11, 2020 at 11:24 AM Jeff Young  wrote:
>
> I’d definitely want to set edge clearance apart from other clearance.
>
> And I’d definitely want to set connected-item clearance (an electrical 
> constraint) apart from non-connected-copper-item clearance (a production 
> constraint).
>
> And I’d definitely want different violations for via annulus (a production 
> constraint) and via size (possibly just a current/heat constraint).
>
> I’m still on the fence with throughVia drill vs. uVia drill.  The rest I can 
> agree with.
>
> Cheers,
> Jeff.
>
>
> > On 11 Jun 2020, at 15:56, Jon Evans  wrote:
> >
> > I think having fewer codes is something to strive for, especially
> > since we are auto-generating severity options from the list of codes.
> >
> > Having a bunch of severity settings where people wouldn't reasonably
> > need to change them clutters the UI.
> >
> > Having excessive categorization in the DRC window makes it harder to
> > sort through that information (for me at least).
> >
> > I don't think we need to be able to set severities independently for
> > each rule in the "classic" system, we just need enough different
> > severity settings to make sense.
> >
> > For example, going down the classic DRC rules dialog:
> >
> > Allowed features: both checkboxes generate DRCE_ALLOWED_FEATURES
> > Arc/circle and zone fill: these aren't actually DRC checks
> > Copper min clearance: generates DRCE_CLEARANCE
> > Min track width: generates DRCE_WIDTH
> > Min via annulus: generates DRCE_VIA_SIZE
> > Min via diameter: generates DRCE_VIA_SIZE
> > Copper edge clearance: generates DRCE_CLEARANCE
> > Min through hole: generates DRCE_HOLE_SIZE
> > Hole to hole: generates DRCE_HOLE_CLEARANCE
> > uVia diameter: generates DRCE_VIA_SIZE
> > uVia drill: generates DRCE_HOLE_SIZE
> >
> >
> >
> > On Thu, Jun 11, 2020 at 10:42 AM Jeff Young  wrote:
> >>
> >> What does that buy us?  The only things the error code gives us is a 
> >> string and a severity.   The data storage (items, locations, etc.) is 
> >> already completely orthogonal.
> >>
> >>> On 11 Jun 2020, at 15:36, Jon Evans  wrote:
> >>>
> >>> But couldn't this taxonomy be separate from the DRC_ITEM (i.e. error
> >>> code) taxonomy?
> >>>
> >>> For example you could have a "classic minimum clearance" severity setting.
> >>> This would set the severity of any DRCE_CLEARANCE items generated
> >>> where the rule source is the classic system.
> >>> This would replace all of the "X too close to Y" error codes
> >>>
> >>> I think if we did this, the minimum set of error codes would look
> >>> something like one error code per setting in the Constraints setup
> >>> dialog.
> >>> Maybe even smaller than that number of settings, because you can set
> >>> separate numbers for vias and microvias and I still don't think you
> >>> need separate severities for those.
> >>>
> >>> On Thu, Jun 11, 2020 at 10:24 AM Jeff Young  wrote:
> 
>  (But I do like being able to assign a severity to a rule.)
> 
>  On 11 Jun 2020, at 15:22, Jeff Young  wrote:
> 
>  I think we’d still need some sort of taxonomy to put the severities on 
>  for the “classic” system.
> 
>  On 11 Jun 2020, at 15:01, Ian McInerney  wrote:
> 
>  Why not make the severity attached to the rule being used instead of the 
>  error code type. I think being able to say "this rule is very important 
>  and should be treated as an error" and "this rule is just a guideline 
>  and can be treated as a warning" while they are both the same error code 
>  would make more sense.
> 
>  -Ian
> 
>  On Thu, Jun 11, 2020 at 2:53 PM Jon Evans  wrote:
> >
> > The only reasons to have multiple violation error codes is to be able
> > to set a different severity for them, or to be able to filter/sort
> > them.
> >
> > I can't think of a situation in which I would want to do either of
> > those things for different via types.
> >
> > On Thu, Jun 11, 2020 at 9:48 AM Wayne Stambaugh  
> > wrote:
> >>
> >> I was thinking along the same lines.  Wouldn't it make more sense to
> >> define the objects that violate a DRC rule and generate the error
> >> message on the fly rather than adding violation error codes for every
> >> possible error?
> >>
> >> On 6/11/20 9:26 AM, Jon Evans wrote:
> >>> I think microvias and vias using different technologies means they
> >>> need 

Re: [Kicad-developers] How do we envision Pad Stacks?

[ja...@veith.net]

On 11.06.20 17:16, Wayne Stambaugh wrote:

I thought at one time we had an initial proposal document written for
pad stacks but I cannot seem to find it.  I thought it was either Orson
or Tom who wrote it but maybe I'm remembering this wrong.  If not, we
need to create one to make sure we have it well defined before any
implementation can be done.


When I asked Orson some weeks ago, he responded that there is no
such document

Expedition supports a separate pad stack library what contains drills,
drill symbols, THT and SMD pads and combinations of them (pad stacks). 
All footprints link to this padstacks similar Kicad link from symbol to 
footprint. This way padstacks are not defined in footprints what allows 
footprints to  change pads automatically (wave, reflow or other needs). 
Once placed, the footprint link to padastack can be altered to special 
design needs


___
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] How do we envision Pad Stacks?

[Jeff Young]

> On 11 Jun 2020, at 16:16, Wayne Stambaugh  wrote:
> 
> If not, we
> need to create one to make sure we have it well defined before any
> implementation can be done.

Just to be clear: I’m not looking at implementing it.  But I’d need to know 
what direction we were moving in *if* I were to implement a WYSIWYG custom pad 
editor.

If we’re going to allow a shape per layer, then it pretty much needs to be a 
repurposed PCB_BASE_FRAME.  If we’re going to do something like Altium then we 
probably just want a canvas with shape tools and the point editor.___
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] Granularity of DRC error code

[Jeff Young]

I’d definitely want to set edge clearance apart from other clearance.

And I’d definitely want to set connected-item clearance (an electrical 
constraint) apart from non-connected-copper-item clearance (a production 
constraint).

And I’d definitely want different violations for via annulus (a production 
constraint) and via size (possibly just a current/heat constraint).

I’m still on the fence with throughVia drill vs. uVia drill.  The rest I can 
agree with.

Cheers,
Jeff.


> On 11 Jun 2020, at 15:56, Jon Evans  wrote:
> 
> I think having fewer codes is something to strive for, especially
> since we are auto-generating severity options from the list of codes.
> 
> Having a bunch of severity settings where people wouldn't reasonably
> need to change them clutters the UI.
> 
> Having excessive categorization in the DRC window makes it harder to
> sort through that information (for me at least).
> 
> I don't think we need to be able to set severities independently for
> each rule in the "classic" system, we just need enough different
> severity settings to make sense.
> 
> For example, going down the classic DRC rules dialog:
> 
> Allowed features: both checkboxes generate DRCE_ALLOWED_FEATURES
> Arc/circle and zone fill: these aren't actually DRC checks
> Copper min clearance: generates DRCE_CLEARANCE
> Min track width: generates DRCE_WIDTH
> Min via annulus: generates DRCE_VIA_SIZE
> Min via diameter: generates DRCE_VIA_SIZE
> Copper edge clearance: generates DRCE_CLEARANCE
> Min through hole: generates DRCE_HOLE_SIZE
> Hole to hole: generates DRCE_HOLE_CLEARANCE
> uVia diameter: generates DRCE_VIA_SIZE
> uVia drill: generates DRCE_HOLE_SIZE
> 
> 
> 
> On Thu, Jun 11, 2020 at 10:42 AM Jeff Young  wrote:
>> 
>> What does that buy us?  The only things the error code gives us is a string 
>> and a severity.   The data storage (items, locations, etc.) is already 
>> completely orthogonal.
>> 
>>> On 11 Jun 2020, at 15:36, Jon Evans  wrote:
>>> 
>>> But couldn't this taxonomy be separate from the DRC_ITEM (i.e. error
>>> code) taxonomy?
>>> 
>>> For example you could have a "classic minimum clearance" severity setting.
>>> This would set the severity of any DRCE_CLEARANCE items generated
>>> where the rule source is the classic system.
>>> This would replace all of the "X too close to Y" error codes
>>> 
>>> I think if we did this, the minimum set of error codes would look
>>> something like one error code per setting in the Constraints setup
>>> dialog.
>>> Maybe even smaller than that number of settings, because you can set
>>> separate numbers for vias and microvias and I still don't think you
>>> need separate severities for those.
>>> 
>>> On Thu, Jun 11, 2020 at 10:24 AM Jeff Young  wrote:
 
 (But I do like being able to assign a severity to a rule.)
 
 On 11 Jun 2020, at 15:22, Jeff Young  wrote:
 
 I think we’d still need some sort of taxonomy to put the severities on for 
 the “classic” system.
 
 On 11 Jun 2020, at 15:01, Ian McInerney  wrote:
 
 Why not make the severity attached to the rule being used instead of the 
 error code type. I think being able to say "this rule is very important 
 and should be treated as an error" and "this rule is just a guideline and 
 can be treated as a warning" while they are both the same error code would 
 make more sense.
 
 -Ian
 
 On Thu, Jun 11, 2020 at 2:53 PM Jon Evans  wrote:
> 
> The only reasons to have multiple violation error codes is to be able
> to set a different severity for them, or to be able to filter/sort
> them.
> 
> I can't think of a situation in which I would want to do either of
> those things for different via types.
> 
> On Thu, Jun 11, 2020 at 9:48 AM Wayne Stambaugh  
> wrote:
>> 
>> I was thinking along the same lines.  Wouldn't it make more sense to
>> define the objects that violate a DRC rule and generate the error
>> message on the fly rather than adding violation error codes for every
>> possible error?
>> 
>> On 6/11/20 9:26 AM, Jon Evans wrote:
>>> I think microvias and vias using different technologies means they
>>> need different *rules*, not different error codes.
>>> 
>>> Whether a hole is laser or mechanically drilled, it will have some
>>> rules, and those rules could generate an error "hole size is outside
>>> allowed range".
>>> 
>>> You can tell from the affected items whether the hole in question is a
>>> via, microvia, blind via, buried via.
>>> You can tell from the rule source whether this came from a microvia
>>> rule, normal via rule, custom rule, etc.
>>> 
>>> Why should we have separate violations per via type?  (not separate
>>> *rules* but separate violations)  I still don't get the use case.
>>> 
>>> As mentioned in the last taxonomy discussion, I still think we could
>>> get rid of the tons of 

Re: [Kicad-developers] How do we envision Pad Stacks?

[Jon Evans]

In Altium (and I suspect in other commercial tools) there are two
different types of pad behavior:  when creating/editing/viewing
footprints, and when working on the board.

When editing footprints, you only have the concept of top, middle, and
bottom layers.  You don't know the full board stackup. So, for a PTH
pad, you can set what you want to happen on *all* inner layers, and it
can be different from the top and bottom layers if you'd like. Altium
lets you have different shapes for each of these (maybe you want a
square pad on the top for identification purposes, but round on inner
layers).  Altium doesn't let you do this for SMD pads, I guess because
it doesn't make sense to pre-assign a SMD pad to a particular inner
layer in the footprint editor when you don't know on what board
stackup it will be used.

When you place a footprint or free pad on the board, you can edit that
pad in the context of the board.  This means things like moving a SMD
pad to a particular inner layer, or removing the pad from one or all
inner layers on a PTH pad.

There is a toggle for stackup mode in Altium:  Simple,
Top-Middle-Bottom, and Full Stack.  These give you one, three, or N
sets of pad size/shape options respectively, where N is your PCB
copper layer count.

Some SMD pads require different shapes for paste layers (I've never
seen mask be anything other than an offset, positive or negative, from
the copper shape)

On Thu, Jun 11, 2020 at 10:54 AM Jeff Young  wrote:
>
> I had been assuming that you could define a separate shape for each layer.  
> Full flexibility, but time-consuming to edit (even with commands such as 
> “push current layer to other layers”).
>
> Most users are looking to route traces on inner layers between tight pads.  
> This is commonly done with the definition of a “capture pad”.  The constraint 
> on inner layers that have connecting tracks is simply not to have a butt 
> joint between the track and the plated hole.  A capture pad is therefore a 
> circular pad with an annulus width of the drill wander plus 1 or 2 mils; 
> other capture pad shapes get you nothing more.
>
> There were also a few requests for SMD pads on a single inner layer (or 
> perhaps multiple) — but importantly not for different shapes on different 
> layers.
>
> So one could imagine allowing the pad shape to be placed on any number of 
> layers, and a capture annulus width for any other connected layers.  While it 
> doesn’t have same flexibility, it would be a lot easier to edit.
>
> Another possible complication is wanting a different shape for mask (or 
> paste) layers.  Is this ever required?
>
> Thoughts?
> ___
> 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] How do we envision Pad Stacks?

[Wayne Stambaugh]

I thought at one time we had an initial proposal document written for
pad stacks but I cannot seem to find it.  I thought it was either Orson
or Tom who wrote it but maybe I'm remembering this wrong.  If not, we
need to create one to make sure we have it well defined before any
implementation can be done.

I think most EDA pad stack editors allow for different shapes per layer
so we should probably follow suite.  I would think a pad stack would be
used for allowing SMD pads to be placed on inner layers although I have
not idea how this is handled by other EDAs.

On 6/11/20 10:54 AM, Jeff Young wrote:
> I had been assuming that you could define a separate shape for each
> layer.  Full flexibility, but time-consuming to edit (even with commands
> such as “push current layer to other layers”).
> 
> Most users are looking to route traces on inner layers between tight
> pads.  This is commonly done with the definition of a “capture pad”.
>  The constraint on inner layers that have connecting tracks is simply
> not to have a butt joint between the track and the plated hole.  A
> capture pad is therefore a circular pad with an annulus width of the
> drill wander plus 1 or 2 mils; other capture pad shapes get you nothing
> more.
> 
> There were also a few requests for SMD pads on a single inner layer (or
> perhaps multiple) — but importantly not for different shapes on
> different layers.
> 
> So one could imagine allowing the pad shape to be placed on any number
> of layers, and a capture annulus width for any other connected layers.
>  While it doesn’t have same flexibility, it would be a /lot/ easier to edit.
> 
> Another possible complication is wanting a different shape for mask (or
> paste) layers.  Is this ever required?
> 
> Thoughts?
> 
> ___
> 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] Granularity of DRC error code

[Jon Evans]

I think having fewer codes is something to strive for, especially
since we are auto-generating severity options from the list of codes.

Having a bunch of severity settings where people wouldn't reasonably
need to change them clutters the UI.

Having excessive categorization in the DRC window makes it harder to
sort through that information (for me at least).

I don't think we need to be able to set severities independently for
each rule in the "classic" system, we just need enough different
severity settings to make sense.

For example, going down the classic DRC rules dialog:

Allowed features: both checkboxes generate DRCE_ALLOWED_FEATURES
Arc/circle and zone fill: these aren't actually DRC checks
Copper min clearance: generates DRCE_CLEARANCE
Min track width: generates DRCE_WIDTH
Min via annulus: generates DRCE_VIA_SIZE
Min via diameter: generates DRCE_VIA_SIZE
Copper edge clearance: generates DRCE_CLEARANCE
Min through hole: generates DRCE_HOLE_SIZE
Hole to hole: generates DRCE_HOLE_CLEARANCE
uVia diameter: generates DRCE_VIA_SIZE
uVia drill: generates DRCE_HOLE_SIZE



On Thu, Jun 11, 2020 at 10:42 AM Jeff Young  wrote:
>
> What does that buy us?  The only things the error code gives us is a string 
> and a severity.   The data storage (items, locations, etc.) is already 
> completely orthogonal.
>
> > On 11 Jun 2020, at 15:36, Jon Evans  wrote:
> >
> > But couldn't this taxonomy be separate from the DRC_ITEM (i.e. error
> > code) taxonomy?
> >
> > For example you could have a "classic minimum clearance" severity setting.
> > This would set the severity of any DRCE_CLEARANCE items generated
> > where the rule source is the classic system.
> > This would replace all of the "X too close to Y" error codes
> >
> > I think if we did this, the minimum set of error codes would look
> > something like one error code per setting in the Constraints setup
> > dialog.
> > Maybe even smaller than that number of settings, because you can set
> > separate numbers for vias and microvias and I still don't think you
> > need separate severities for those.
> >
> > On Thu, Jun 11, 2020 at 10:24 AM Jeff Young  wrote:
> >>
> >> (But I do like being able to assign a severity to a rule.)
> >>
> >> On 11 Jun 2020, at 15:22, Jeff Young  wrote:
> >>
> >> I think we’d still need some sort of taxonomy to put the severities on for 
> >> the “classic” system.
> >>
> >> On 11 Jun 2020, at 15:01, Ian McInerney  wrote:
> >>
> >> Why not make the severity attached to the rule being used instead of the 
> >> error code type. I think being able to say "this rule is very important 
> >> and should be treated as an error" and "this rule is just a guideline and 
> >> can be treated as a warning" while they are both the same error code would 
> >> make more sense.
> >>
> >> -Ian
> >>
> >> On Thu, Jun 11, 2020 at 2:53 PM Jon Evans  wrote:
> >>>
> >>> The only reasons to have multiple violation error codes is to be able
> >>> to set a different severity for them, or to be able to filter/sort
> >>> them.
> >>>
> >>> I can't think of a situation in which I would want to do either of
> >>> those things for different via types.
> >>>
> >>> On Thu, Jun 11, 2020 at 9:48 AM Wayne Stambaugh  
> >>> wrote:
> 
>  I was thinking along the same lines.  Wouldn't it make more sense to
>  define the objects that violate a DRC rule and generate the error
>  message on the fly rather than adding violation error codes for every
>  possible error?
> 
>  On 6/11/20 9:26 AM, Jon Evans wrote:
> > I think microvias and vias using different technologies means they
> > need different *rules*, not different error codes.
> >
> > Whether a hole is laser or mechanically drilled, it will have some
> > rules, and those rules could generate an error "hole size is outside
> > allowed range".
> >
> > You can tell from the affected items whether the hole in question is a
> > via, microvia, blind via, buried via.
> > You can tell from the rule source whether this came from a microvia
> > rule, normal via rule, custom rule, etc.
> >
> > Why should we have separate violations per via type?  (not separate
> > *rules* but separate violations)  I still don't get the use case.
> >
> > As mentioned in the last taxonomy discussion, I still think we could
> > get rid of the tons of different "X close to Y" errors and just call
> > it a "clearance error", but I understand that might be more
> > contentious so I'd like to focus for now on just the keepouts and
> > vias.
> >
> > -Jon
> >
> > On Thu, Jun 11, 2020 at 6:51 AM Jeff Young  wrote:
> >>
> >> The “Inside Keepout” issue might be a bad example.  I’d definitely be 
> >> in favour of folding all of those into a single violation because a 
> >> keepout already specifies which types of things are excluded.
> >>
> >> But other things I’d be less in favour of.  I want a warning about 
> 

[Kicad-developers] How do we envision Pad Stacks?

[Jeff Young]

I had been assuming that you could define a separate shape for each layer.  
Full flexibility, but time-consuming to edit (even with commands such as “push 
current layer to other layers”).

Most users are looking to route traces on inner layers between tight pads.  
This is commonly done with the definition of a “capture pad”.  The constraint 
on inner layers that have connecting tracks is simply not to have a butt joint 
between the track and the plated hole.  A capture pad is therefore a circular 
pad with an annulus width of the drill wander plus 1 or 2 mils; other capture 
pad shapes get you nothing more.

There were also a few requests for SMD pads on a single inner layer (or perhaps 
multiple) — but importantly not for different shapes on different layers.

So one could imagine allowing the pad shape to be placed on any number of 
layers, and a capture annulus width for any other connected layers.  While it 
doesn’t have same flexibility, it would be a lot easier to edit.

Another possible complication is wanting a different shape for mask (or paste) 
layers.  Is this ever required?

Thoughts?___
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] Granularity of DRC error code

[Jeff Young]

What does that buy us?  The only things the error code gives us is a string and 
a severity.   The data storage (items, locations, etc.) is already completely 
orthogonal.

> On 11 Jun 2020, at 15:36, Jon Evans  wrote:
> 
> But couldn't this taxonomy be separate from the DRC_ITEM (i.e. error
> code) taxonomy?
> 
> For example you could have a "classic minimum clearance" severity setting.
> This would set the severity of any DRCE_CLEARANCE items generated
> where the rule source is the classic system.
> This would replace all of the "X too close to Y" error codes
> 
> I think if we did this, the minimum set of error codes would look
> something like one error code per setting in the Constraints setup
> dialog.
> Maybe even smaller than that number of settings, because you can set
> separate numbers for vias and microvias and I still don't think you
> need separate severities for those.
> 
> On Thu, Jun 11, 2020 at 10:24 AM Jeff Young  wrote:
>> 
>> (But I do like being able to assign a severity to a rule.)
>> 
>> On 11 Jun 2020, at 15:22, Jeff Young  wrote:
>> 
>> I think we’d still need some sort of taxonomy to put the severities on for 
>> the “classic” system.
>> 
>> On 11 Jun 2020, at 15:01, Ian McInerney  wrote:
>> 
>> Why not make the severity attached to the rule being used instead of the 
>> error code type. I think being able to say "this rule is very important and 
>> should be treated as an error" and "this rule is just a guideline and can be 
>> treated as a warning" while they are both the same error code would make 
>> more sense.
>> 
>> -Ian
>> 
>> On Thu, Jun 11, 2020 at 2:53 PM Jon Evans  wrote:
>>> 
>>> The only reasons to have multiple violation error codes is to be able
>>> to set a different severity for them, or to be able to filter/sort
>>> them.
>>> 
>>> I can't think of a situation in which I would want to do either of
>>> those things for different via types.
>>> 
>>> On Thu, Jun 11, 2020 at 9:48 AM Wayne Stambaugh  
>>> wrote:
 
 I was thinking along the same lines.  Wouldn't it make more sense to
 define the objects that violate a DRC rule and generate the error
 message on the fly rather than adding violation error codes for every
 possible error?
 
 On 6/11/20 9:26 AM, Jon Evans wrote:
> I think microvias and vias using different technologies means they
> need different *rules*, not different error codes.
> 
> Whether a hole is laser or mechanically drilled, it will have some
> rules, and those rules could generate an error "hole size is outside
> allowed range".
> 
> You can tell from the affected items whether the hole in question is a
> via, microvia, blind via, buried via.
> You can tell from the rule source whether this came from a microvia
> rule, normal via rule, custom rule, etc.
> 
> Why should we have separate violations per via type?  (not separate
> *rules* but separate violations)  I still don't get the use case.
> 
> As mentioned in the last taxonomy discussion, I still think we could
> get rid of the tons of different "X close to Y" errors and just call
> it a "clearance error", but I understand that might be more
> contentious so I'd like to focus for now on just the keepouts and
> vias.
> 
> -Jon
> 
> On Thu, Jun 11, 2020 at 6:51 AM Jeff Young  wrote:
>> 
>> The “Inside Keepout” issue might be a bad example.  I’d definitely be in 
>> favour of folding all of those into a single violation because a keepout 
>> already specifies which types of things are excluded.
>> 
>> But other things I’d be less in favour of.  I want a warning about NPTHs 
>> in courtyards; I don’t want one for PTHs (the former likely has a 
>> mechanical fixing, the later likely doesn't).
>> 
>> While I don’t personally use uVias, I’d certainly think we’d want 
>> separate violations for their holes (as they’re made with different 
>> technologies).  On the flip side, I’m not sure there’s any value in 
>> distinguishing between throughVia holes and pad holes.
>> 
>> But that gives us a different taxonomy for size vs. hole, as the 
>> difference between uVia and throughVia size may not be important.  (We 
>> already have this to some extent as I didn’t bother with separate 
>> annulus violations for via types, although there’s a TODO in the code).
>> 
>> This all begs the question “how bad is an uneven taxonomy”?  Is it just 
>> an ivory-tower kind of thing, or will it actually cause confusion?
>> 
>> Back to specific instances, I like being able to treat 
>> track-too-close-to-connected-item separately from 
>> track-to-close-to-unconnected-item, but I’m less fussed about the 
>> differences between the type of connected item (track-to-close-to-via vs 
>> track-to-close-to-track).  (For what it’s worth, unconnected items are 
>> already grouped as we don’t 

Re: [Kicad-developers] Granularity of DRC error code

[Jon Evans]

But couldn't this taxonomy be separate from the DRC_ITEM (i.e. error
code) taxonomy?

For example you could have a "classic minimum clearance" severity setting.
This would set the severity of any DRCE_CLEARANCE items generated
where the rule source is the classic system.
This would replace all of the "X too close to Y" error codes

I think if we did this, the minimum set of error codes would look
something like one error code per setting in the Constraints setup
dialog.
Maybe even smaller than that number of settings, because you can set
separate numbers for vias and microvias and I still don't think you
need separate severities for those.

On Thu, Jun 11, 2020 at 10:24 AM Jeff Young  wrote:
>
> (But I do like being able to assign a severity to a rule.)
>
> On 11 Jun 2020, at 15:22, Jeff Young  wrote:
>
> I think we’d still need some sort of taxonomy to put the severities on for 
> the “classic” system.
>
> On 11 Jun 2020, at 15:01, Ian McInerney  wrote:
>
> Why not make the severity attached to the rule being used instead of the 
> error code type. I think being able to say "this rule is very important and 
> should be treated as an error" and "this rule is just a guideline and can be 
> treated as a warning" while they are both the same error code would make more 
> sense.
>
> -Ian
>
> On Thu, Jun 11, 2020 at 2:53 PM Jon Evans  wrote:
>>
>> The only reasons to have multiple violation error codes is to be able
>> to set a different severity for them, or to be able to filter/sort
>> them.
>>
>> I can't think of a situation in which I would want to do either of
>> those things for different via types.
>>
>> On Thu, Jun 11, 2020 at 9:48 AM Wayne Stambaugh  wrote:
>> >
>> > I was thinking along the same lines.  Wouldn't it make more sense to
>> > define the objects that violate a DRC rule and generate the error
>> > message on the fly rather than adding violation error codes for every
>> > possible error?
>> >
>> > On 6/11/20 9:26 AM, Jon Evans wrote:
>> > > I think microvias and vias using different technologies means they
>> > > need different *rules*, not different error codes.
>> > >
>> > > Whether a hole is laser or mechanically drilled, it will have some
>> > > rules, and those rules could generate an error "hole size is outside
>> > > allowed range".
>> > >
>> > > You can tell from the affected items whether the hole in question is a
>> > > via, microvia, blind via, buried via.
>> > > You can tell from the rule source whether this came from a microvia
>> > > rule, normal via rule, custom rule, etc.
>> > >
>> > > Why should we have separate violations per via type?  (not separate
>> > > *rules* but separate violations)  I still don't get the use case.
>> > >
>> > > As mentioned in the last taxonomy discussion, I still think we could
>> > > get rid of the tons of different "X close to Y" errors and just call
>> > > it a "clearance error", but I understand that might be more
>> > > contentious so I'd like to focus for now on just the keepouts and
>> > > vias.
>> > >
>> > > -Jon
>> > >
>> > > On Thu, Jun 11, 2020 at 6:51 AM Jeff Young  wrote:
>> > >>
>> > >> The “Inside Keepout” issue might be a bad example.  I’d definitely be 
>> > >> in favour of folding all of those into a single violation because a 
>> > >> keepout already specifies which types of things are excluded.
>> > >>
>> > >> But other things I’d be less in favour of.  I want a warning about 
>> > >> NPTHs in courtyards; I don’t want one for PTHs (the former likely has a 
>> > >> mechanical fixing, the later likely doesn't).
>> > >>
>> > >> While I don’t personally use uVias, I’d certainly think we’d want 
>> > >> separate violations for their holes (as they’re made with different 
>> > >> technologies).  On the flip side, I’m not sure there’s any value in 
>> > >> distinguishing between throughVia holes and pad holes.
>> > >>
>> > >> But that gives us a different taxonomy for size vs. hole, as the 
>> > >> difference between uVia and throughVia size may not be important.  (We 
>> > >> already have this to some extent as I didn’t bother with separate 
>> > >> annulus violations for via types, although there’s a TODO in the code).
>> > >>
>> > >> This all begs the question “how bad is an uneven taxonomy”?  Is it just 
>> > >> an ivory-tower kind of thing, or will it actually cause confusion?
>> > >>
>> > >> Back to specific instances, I like being able to treat 
>> > >> track-too-close-to-connected-item separately from 
>> > >> track-to-close-to-unconnected-item, but I’m less fussed about the 
>> > >> differences between the type of connected item (track-to-close-to-via 
>> > >> vs track-to-close-to-track).  (For what it’s worth, unconnected items 
>> > >> are already grouped as we don’t have separate errors for 
>> > >> track-to-close-to-graphics vs track-to-close-to-text.  Yet another bit 
>> > >> of unevenness in the existing taxonomy.)
>> > >>
>> > >> Oddly I find the parallel-tracks vs crossing-tracks useful, but I have 
>> > >> no idea 

Re: [Kicad-developers] Granularity of DRC error code

[Jeff Young]

(But I do like being able to assign a severity to a rule.)

> On 11 Jun 2020, at 15:22, Jeff Young  wrote:
> 
> I think we’d still need some sort of taxonomy to put the severities on for 
> the “classic” system.
> 
>> On 11 Jun 2020, at 15:01, Ian McInerney > > wrote:
>> 
>> Why not make the severity attached to the rule being used instead of the 
>> error code type. I think being able to say "this rule is very important and 
>> should be treated as an error" and "this rule is just a guideline and can be 
>> treated as a warning" while they are both the same error code would make 
>> more sense.
>> 
>> -Ian
>> 
>> On Thu, Jun 11, 2020 at 2:53 PM Jon Evans > > wrote:
>> The only reasons to have multiple violation error codes is to be able
>> to set a different severity for them, or to be able to filter/sort
>> them.
>> 
>> I can't think of a situation in which I would want to do either of
>> those things for different via types.
>> 
>> On Thu, Jun 11, 2020 at 9:48 AM Wayne Stambaugh > > wrote:
>> >
>> > I was thinking along the same lines.  Wouldn't it make more sense to
>> > define the objects that violate a DRC rule and generate the error
>> > message on the fly rather than adding violation error codes for every
>> > possible error?
>> >
>> > On 6/11/20 9:26 AM, Jon Evans wrote:
>> > > I think microvias and vias using different technologies means they
>> > > need different *rules*, not different error codes.
>> > >
>> > > Whether a hole is laser or mechanically drilled, it will have some
>> > > rules, and those rules could generate an error "hole size is outside
>> > > allowed range".
>> > >
>> > > You can tell from the affected items whether the hole in question is a
>> > > via, microvia, blind via, buried via.
>> > > You can tell from the rule source whether this came from a microvia
>> > > rule, normal via rule, custom rule, etc.
>> > >
>> > > Why should we have separate violations per via type?  (not separate
>> > > *rules* but separate violations)  I still don't get the use case.
>> > >
>> > > As mentioned in the last taxonomy discussion, I still think we could
>> > > get rid of the tons of different "X close to Y" errors and just call
>> > > it a "clearance error", but I understand that might be more
>> > > contentious so I'd like to focus for now on just the keepouts and
>> > > vias.
>> > >
>> > > -Jon
>> > >
>> > > On Thu, Jun 11, 2020 at 6:51 AM Jeff Young > > > > wrote:
>> > >>
>> > >> The “Inside Keepout” issue might be a bad example.  I’d definitely be 
>> > >> in favour of folding all of those into a single violation because a 
>> > >> keepout already specifies which types of things are excluded.
>> > >>
>> > >> But other things I’d be less in favour of.  I want a warning about 
>> > >> NPTHs in courtyards; I don’t want one for PTHs (the former likely has a 
>> > >> mechanical fixing, the later likely doesn't).
>> > >>
>> > >> While I don’t personally use uVias, I’d certainly think we’d want 
>> > >> separate violations for their holes (as they’re made with different 
>> > >> technologies).  On the flip side, I’m not sure there’s any value in 
>> > >> distinguishing between throughVia holes and pad holes.
>> > >>
>> > >> But that gives us a different taxonomy for size vs. hole, as the 
>> > >> difference between uVia and throughVia size may not be important.  (We 
>> > >> already have this to some extent as I didn’t bother with separate 
>> > >> annulus violations for via types, although there’s a TODO in the code).
>> > >>
>> > >> This all begs the question “how bad is an uneven taxonomy”?  Is it just 
>> > >> an ivory-tower kind of thing, or will it actually cause confusion?
>> > >>
>> > >> Back to specific instances, I like being able to treat 
>> > >> track-too-close-to-connected-item separately from 
>> > >> track-to-close-to-unconnected-item, but I’m less fussed about the 
>> > >> differences between the type of connected item (track-to-close-to-via 
>> > >> vs track-to-close-to-track).  (For what it’s worth, unconnected items 
>> > >> are already grouped as we don’t have separate errors for 
>> > >> track-to-close-to-graphics vs track-to-close-to-text.  Yet another bit 
>> > >> of unevenness in the existing taxonomy.)
>> > >>
>> > >> Oddly I find the parallel-tracks vs crossing-tracks useful, but I have 
>> > >> no idea why.  I guess it just gives me a better idea of what I’m 
>> > >> looking for on the board?
>> > >>
>> > >> One last note: Greg’s request for specific exclusions is already in the 
>> > >> nightlies.
>> > >>
>> > >> Cheers,
>> > >> Jeff
>> > >>
>> > >>
>> > >>
>> > >>> On 11 Jun 2020, at 06:19, Greg Smith > > >>> > wrote:
>> > >>>
>> > >>> I think more grouping in general categories is good. I also think that 
>> > >>> it would be nice to exclude *specific* DRCs that once a designer 
>> > >>> checks the error, they can flag it to 

Re: [Kicad-developers] Granularity of DRC error code

[Jeff Young]

I think we’d still need some sort of taxonomy to put the severities on for the 
“classic” system.

> On 11 Jun 2020, at 15:01, Ian McInerney  wrote:
> 
> Why not make the severity attached to the rule being used instead of the 
> error code type. I think being able to say "this rule is very important and 
> should be treated as an error" and "this rule is just a guideline and can be 
> treated as a warning" while they are both the same error code would make more 
> sense.
> 
> -Ian
> 
> On Thu, Jun 11, 2020 at 2:53 PM Jon Evans  > wrote:
> The only reasons to have multiple violation error codes is to be able
> to set a different severity for them, or to be able to filter/sort
> them.
> 
> I can't think of a situation in which I would want to do either of
> those things for different via types.
> 
> On Thu, Jun 11, 2020 at 9:48 AM Wayne Stambaugh  > wrote:
> >
> > I was thinking along the same lines.  Wouldn't it make more sense to
> > define the objects that violate a DRC rule and generate the error
> > message on the fly rather than adding violation error codes for every
> > possible error?
> >
> > On 6/11/20 9:26 AM, Jon Evans wrote:
> > > I think microvias and vias using different technologies means they
> > > need different *rules*, not different error codes.
> > >
> > > Whether a hole is laser or mechanically drilled, it will have some
> > > rules, and those rules could generate an error "hole size is outside
> > > allowed range".
> > >
> > > You can tell from the affected items whether the hole in question is a
> > > via, microvia, blind via, buried via.
> > > You can tell from the rule source whether this came from a microvia
> > > rule, normal via rule, custom rule, etc.
> > >
> > > Why should we have separate violations per via type?  (not separate
> > > *rules* but separate violations)  I still don't get the use case.
> > >
> > > As mentioned in the last taxonomy discussion, I still think we could
> > > get rid of the tons of different "X close to Y" errors and just call
> > > it a "clearance error", but I understand that might be more
> > > contentious so I'd like to focus for now on just the keepouts and
> > > vias.
> > >
> > > -Jon
> > >
> > > On Thu, Jun 11, 2020 at 6:51 AM Jeff Young  > > > wrote:
> > >>
> > >> The “Inside Keepout” issue might be a bad example.  I’d definitely be in 
> > >> favour of folding all of those into a single violation because a keepout 
> > >> already specifies which types of things are excluded.
> > >>
> > >> But other things I’d be less in favour of.  I want a warning about NPTHs 
> > >> in courtyards; I don’t want one for PTHs (the former likely has a 
> > >> mechanical fixing, the later likely doesn't).
> > >>
> > >> While I don’t personally use uVias, I’d certainly think we’d want 
> > >> separate violations for their holes (as they’re made with different 
> > >> technologies).  On the flip side, I’m not sure there’s any value in 
> > >> distinguishing between throughVia holes and pad holes.
> > >>
> > >> But that gives us a different taxonomy for size vs. hole, as the 
> > >> difference between uVia and throughVia size may not be important.  (We 
> > >> already have this to some extent as I didn’t bother with separate 
> > >> annulus violations for via types, although there’s a TODO in the code).
> > >>
> > >> This all begs the question “how bad is an uneven taxonomy”?  Is it just 
> > >> an ivory-tower kind of thing, or will it actually cause confusion?
> > >>
> > >> Back to specific instances, I like being able to treat 
> > >> track-too-close-to-connected-item separately from 
> > >> track-to-close-to-unconnected-item, but I’m less fussed about the 
> > >> differences between the type of connected item (track-to-close-to-via vs 
> > >> track-to-close-to-track).  (For what it’s worth, unconnected items are 
> > >> already grouped as we don’t have separate errors for 
> > >> track-to-close-to-graphics vs track-to-close-to-text.  Yet another bit 
> > >> of unevenness in the existing taxonomy.)
> > >>
> > >> Oddly I find the parallel-tracks vs crossing-tracks useful, but I have 
> > >> no idea why.  I guess it just gives me a better idea of what I’m looking 
> > >> for on the board?
> > >>
> > >> One last note: Greg’s request for specific exclusions is already in the 
> > >> nightlies.
> > >>
> > >> Cheers,
> > >> Jeff
> > >>
> > >>
> > >>
> > >>> On 11 Jun 2020, at 06:19, Greg Smith  > >>> > wrote:
> > >>>
> > >>> I think more grouping in general categories is good. I also think that 
> > >>> it would be nice to exclude *specific* DRCs that once a designer checks 
> > >>> the error, they can flag it to ignore in the future. The specific check 
> > >>> could be identified by a unique id: a hash of specific information, 
> > >>> like unique error and objects involved (identified by geometries and 
> > >>> properties involved). If anything changes, then 

Re: [Kicad-developers] Granularity of DRC error code

[Jon Evans]

Jeff - what do you think about this?

I think it's an interesting thought.

Previously, we've had very close to a 1:1 mapping between rule and error code.
So, it made sense to assign severities to error codes.

Now with the expanded rules system in the works, I think it will be a
N:1 mapping between rule and error code.  I think what Wayne and Ian
mention makes a lot of sense to me.

-Jon



On Thu, Jun 11, 2020 at 10:01 AM Ian McInerney  wrote:
>
> Why not make the severity attached to the rule being used instead of the 
> error code type. I think being able to say "this rule is very important and 
> should be treated as an error" and "this rule is just a guideline and can be 
> treated as a warning" while they are both the same error code would make more 
> sense.
>
> -Ian
>
> On Thu, Jun 11, 2020 at 2:53 PM Jon Evans  wrote:
>>
>> The only reasons to have multiple violation error codes is to be able
>> to set a different severity for them, or to be able to filter/sort
>> them.
>>
>> I can't think of a situation in which I would want to do either of
>> those things for different via types.
>>
>> On Thu, Jun 11, 2020 at 9:48 AM Wayne Stambaugh  wrote:
>> >
>> > I was thinking along the same lines.  Wouldn't it make more sense to
>> > define the objects that violate a DRC rule and generate the error
>> > message on the fly rather than adding violation error codes for every
>> > possible error?
>> >
>> > On 6/11/20 9:26 AM, Jon Evans wrote:
>> > > I think microvias and vias using different technologies means they
>> > > need different *rules*, not different error codes.
>> > >
>> > > Whether a hole is laser or mechanically drilled, it will have some
>> > > rules, and those rules could generate an error "hole size is outside
>> > > allowed range".
>> > >
>> > > You can tell from the affected items whether the hole in question is a
>> > > via, microvia, blind via, buried via.
>> > > You can tell from the rule source whether this came from a microvia
>> > > rule, normal via rule, custom rule, etc.
>> > >
>> > > Why should we have separate violations per via type?  (not separate
>> > > *rules* but separate violations)  I still don't get the use case.
>> > >
>> > > As mentioned in the last taxonomy discussion, I still think we could
>> > > get rid of the tons of different "X close to Y" errors and just call
>> > > it a "clearance error", but I understand that might be more
>> > > contentious so I'd like to focus for now on just the keepouts and
>> > > vias.
>> > >
>> > > -Jon
>> > >
>> > > On Thu, Jun 11, 2020 at 6:51 AM Jeff Young  wrote:
>> > >>
>> > >> The “Inside Keepout” issue might be a bad example.  I’d definitely be 
>> > >> in favour of folding all of those into a single violation because a 
>> > >> keepout already specifies which types of things are excluded.
>> > >>
>> > >> But other things I’d be less in favour of.  I want a warning about 
>> > >> NPTHs in courtyards; I don’t want one for PTHs (the former likely has a 
>> > >> mechanical fixing, the later likely doesn't).
>> > >>
>> > >> While I don’t personally use uVias, I’d certainly think we’d want 
>> > >> separate violations for their holes (as they’re made with different 
>> > >> technologies).  On the flip side, I’m not sure there’s any value in 
>> > >> distinguishing between throughVia holes and pad holes.
>> > >>
>> > >> But that gives us a different taxonomy for size vs. hole, as the 
>> > >> difference between uVia and throughVia size may not be important.  (We 
>> > >> already have this to some extent as I didn’t bother with separate 
>> > >> annulus violations for via types, although there’s a TODO in the code).
>> > >>
>> > >> This all begs the question “how bad is an uneven taxonomy”?  Is it just 
>> > >> an ivory-tower kind of thing, or will it actually cause confusion?
>> > >>
>> > >> Back to specific instances, I like being able to treat 
>> > >> track-too-close-to-connected-item separately from 
>> > >> track-to-close-to-unconnected-item, but I’m less fussed about the 
>> > >> differences between the type of connected item (track-to-close-to-via 
>> > >> vs track-to-close-to-track).  (For what it’s worth, unconnected items 
>> > >> are already grouped as we don’t have separate errors for 
>> > >> track-to-close-to-graphics vs track-to-close-to-text.  Yet another bit 
>> > >> of unevenness in the existing taxonomy.)
>> > >>
>> > >> Oddly I find the parallel-tracks vs crossing-tracks useful, but I have 
>> > >> no idea why.  I guess it just gives me a better idea of what I’m 
>> > >> looking for on the board?
>> > >>
>> > >> One last note: Greg’s request for specific exclusions is already in the 
>> > >> nightlies.
>> > >>
>> > >> Cheers,
>> > >> Jeff
>> > >>
>> > >>
>> > >>
>> > >>> On 11 Jun 2020, at 06:19, Greg Smith  wrote:
>> > >>>
>> > >>> I think more grouping in general categories is good. I also think that 
>> > >>> it would be nice to exclude *specific* DRCs that once a designer 
>> > >>> checks the error, they can flag 

Re: [Kicad-developers] Granularity of DRC error code

[Ian McInerney]

Why not make the severity attached to the rule being used instead of the
error code type. I think being able to say "this rule is very important and
should be treated as an error" and "this rule is just a guideline and can
be treated as a warning" while they are both the same error code would make
more sense.

-Ian

On Thu, Jun 11, 2020 at 2:53 PM Jon Evans  wrote:

> The only reasons to have multiple violation error codes is to be able
> to set a different severity for them, or to be able to filter/sort
> them.
>
> I can't think of a situation in which I would want to do either of
> those things for different via types.
>
> On Thu, Jun 11, 2020 at 9:48 AM Wayne Stambaugh 
> wrote:
> >
> > I was thinking along the same lines.  Wouldn't it make more sense to
> > define the objects that violate a DRC rule and generate the error
> > message on the fly rather than adding violation error codes for every
> > possible error?
> >
> > On 6/11/20 9:26 AM, Jon Evans wrote:
> > > I think microvias and vias using different technologies means they
> > > need different *rules*, not different error codes.
> > >
> > > Whether a hole is laser or mechanically drilled, it will have some
> > > rules, and those rules could generate an error "hole size is outside
> > > allowed range".
> > >
> > > You can tell from the affected items whether the hole in question is a
> > > via, microvia, blind via, buried via.
> > > You can tell from the rule source whether this came from a microvia
> > > rule, normal via rule, custom rule, etc.
> > >
> > > Why should we have separate violations per via type?  (not separate
> > > *rules* but separate violations)  I still don't get the use case.
> > >
> > > As mentioned in the last taxonomy discussion, I still think we could
> > > get rid of the tons of different "X close to Y" errors and just call
> > > it a "clearance error", but I understand that might be more
> > > contentious so I'd like to focus for now on just the keepouts and
> > > vias.
> > >
> > > -Jon
> > >
> > > On Thu, Jun 11, 2020 at 6:51 AM Jeff Young  wrote:
> > >>
> > >> The “Inside Keepout” issue might be a bad example.  I’d definitely be
> in favour of folding all of those into a single violation because a keepout
> already specifies which types of things are excluded.
> > >>
> > >> But other things I’d be less in favour of.  I want a warning about
> NPTHs in courtyards; I don’t want one for PTHs (the former likely has a
> mechanical fixing, the later likely doesn't).
> > >>
> > >> While I don’t personally use uVias, I’d certainly think we’d want
> separate violations for their holes (as they’re made with different
> technologies).  On the flip side, I’m not sure there’s any value in
> distinguishing between throughVia holes and pad holes.
> > >>
> > >> But that gives us a different taxonomy for size vs. hole, as the
> difference between uVia and throughVia size may not be important.  (We
> already have this to some extent as I didn’t bother with separate annulus
> violations for via types, although there’s a TODO in the code).
> > >>
> > >> This all begs the question “how bad is an uneven taxonomy”?  Is it
> just an ivory-tower kind of thing, or will it actually cause confusion?
> > >>
> > >> Back to specific instances, I like being able to treat
> track-too-close-to-connected-item separately from
> track-to-close-to-unconnected-item, but I’m less fussed about the
> differences between the type of connected item (track-to-close-to-via vs
> track-to-close-to-track).  (For what it’s worth, unconnected items are
> already grouped as we don’t have separate errors for
> track-to-close-to-graphics vs track-to-close-to-text.  Yet another bit of
> unevenness in the existing taxonomy.)
> > >>
> > >> Oddly I find the parallel-tracks vs crossing-tracks useful, but I
> have no idea why.  I guess it just gives me a better idea of what I’m
> looking for on the board?
> > >>
> > >> One last note: Greg’s request for specific exclusions is already in
> the nightlies.
> > >>
> > >> Cheers,
> > >> Jeff
> > >>
> > >>
> > >>
> > >>> On 11 Jun 2020, at 06:19, Greg Smith  wrote:
> > >>>
> > >>> I think more grouping in general categories is good. I also think
> that it would be nice to exclude *specific* DRCs that once a designer
> checks the error, they can flag it to ignore in the future. The specific
> check could be identified by a unique id: a hash of specific information,
> like unique error and objects involved (identified by geometries and
> properties involved). If anything changes, then the rule violation
> reappears under a different unique id. I think this would help greatly on
> near-tapeout activities where sifting over the same DRC errors becomes
> tedious and prone to missing valid DRC violations in the midst of “designer
> checked and allowed” ones.
> > >>>
> > >>> Greg S.
> > >>>
> >  On Jun 10, 2020, at 7:59 PM, Jon Evans  wrote:
> > 
> >  Hi all,
> > 
> >  A DRC error code is something like "Via inside keepout 

Re: [Kicad-developers] Granularity of DRC error code

[Wayne Stambaugh]

Shouldn't the severity be tied to the rule rather than an external
entity?  If the severity is tied to the error code, then you would
always have to maintain the error codes as you add, remove, and change
rules.

On 6/11/20 9:52 AM, Jon Evans wrote:
> The only reasons to have multiple violation error codes is to be able
> to set a different severity for them, or to be able to filter/sort
> them.
> 
> I can't think of a situation in which I would want to do either of
> those things for different via types.
> 
> On Thu, Jun 11, 2020 at 9:48 AM Wayne Stambaugh  wrote:
>>
>> I was thinking along the same lines.  Wouldn't it make more sense to
>> define the objects that violate a DRC rule and generate the error
>> message on the fly rather than adding violation error codes for every
>> possible error?
>>
>> On 6/11/20 9:26 AM, Jon Evans wrote:
>>> I think microvias and vias using different technologies means they
>>> need different *rules*, not different error codes.
>>>
>>> Whether a hole is laser or mechanically drilled, it will have some
>>> rules, and those rules could generate an error "hole size is outside
>>> allowed range".
>>>
>>> You can tell from the affected items whether the hole in question is a
>>> via, microvia, blind via, buried via.
>>> You can tell from the rule source whether this came from a microvia
>>> rule, normal via rule, custom rule, etc.
>>>
>>> Why should we have separate violations per via type?  (not separate
>>> *rules* but separate violations)  I still don't get the use case.
>>>
>>> As mentioned in the last taxonomy discussion, I still think we could
>>> get rid of the tons of different "X close to Y" errors and just call
>>> it a "clearance error", but I understand that might be more
>>> contentious so I'd like to focus for now on just the keepouts and
>>> vias.
>>>
>>> -Jon
>>>
>>> On Thu, Jun 11, 2020 at 6:51 AM Jeff Young  wrote:

 The “Inside Keepout” issue might be a bad example.  I’d definitely be in 
 favour of folding all of those into a single violation because a keepout 
 already specifies which types of things are excluded.

 But other things I’d be less in favour of.  I want a warning about NPTHs 
 in courtyards; I don’t want one for PTHs (the former likely has a 
 mechanical fixing, the later likely doesn't).

 While I don’t personally use uVias, I’d certainly think we’d want separate 
 violations for their holes (as they’re made with different technologies).  
 On the flip side, I’m not sure there’s any value in distinguishing between 
 throughVia holes and pad holes.

 But that gives us a different taxonomy for size vs. hole, as the 
 difference between uVia and throughVia size may not be important.  (We 
 already have this to some extent as I didn’t bother with separate annulus 
 violations for via types, although there’s a TODO in the code).

 This all begs the question “how bad is an uneven taxonomy”?  Is it just an 
 ivory-tower kind of thing, or will it actually cause confusion?

 Back to specific instances, I like being able to treat 
 track-too-close-to-connected-item separately from 
 track-to-close-to-unconnected-item, but I’m less fussed about the 
 differences between the type of connected item (track-to-close-to-via vs 
 track-to-close-to-track).  (For what it’s worth, unconnected items are 
 already grouped as we don’t have separate errors for 
 track-to-close-to-graphics vs track-to-close-to-text.  Yet another bit of 
 unevenness in the existing taxonomy.)

 Oddly I find the parallel-tracks vs crossing-tracks useful, but I have no 
 idea why.  I guess it just gives me a better idea of what I’m looking for 
 on the board?

 One last note: Greg’s request for specific exclusions is already in the 
 nightlies.

 Cheers,
 Jeff



> On 11 Jun 2020, at 06:19, Greg Smith  wrote:
>
> I think more grouping in general categories is good. I also think that it 
> would be nice to exclude *specific* DRCs that once a designer checks the 
> error, they can flag it to ignore in the future. The specific check could 
> be identified by a unique id: a hash of specific information, like unique 
> error and objects involved (identified by geometries and properties 
> involved). If anything changes, then the rule violation reappears under a 
> different unique id. I think this would help greatly on near-tapeout 
> activities where sifting over the same DRC errors becomes tedious and 
> prone to missing valid DRC violations in the midst of “designer checked 
> and allowed” ones.
>
> Greg S.
>
>> On Jun 10, 2020, at 7:59 PM, Jon Evans  wrote:
>>
>> Hi all,
>>
>> A DRC error code is something like "Via inside keepout area", or in
>> the code, DRCE_VIA_INSIDE_KEEPOUT.  It describes a "type" of DRC
>> error.  This type 

Re: [Kicad-developers] Granularity of DRC error code

[Jon Evans]

The only reasons to have multiple violation error codes is to be able
to set a different severity for them, or to be able to filter/sort
them.

I can't think of a situation in which I would want to do either of
those things for different via types.

On Thu, Jun 11, 2020 at 9:48 AM Wayne Stambaugh  wrote:
>
> I was thinking along the same lines.  Wouldn't it make more sense to
> define the objects that violate a DRC rule and generate the error
> message on the fly rather than adding violation error codes for every
> possible error?
>
> On 6/11/20 9:26 AM, Jon Evans wrote:
> > I think microvias and vias using different technologies means they
> > need different *rules*, not different error codes.
> >
> > Whether a hole is laser or mechanically drilled, it will have some
> > rules, and those rules could generate an error "hole size is outside
> > allowed range".
> >
> > You can tell from the affected items whether the hole in question is a
> > via, microvia, blind via, buried via.
> > You can tell from the rule source whether this came from a microvia
> > rule, normal via rule, custom rule, etc.
> >
> > Why should we have separate violations per via type?  (not separate
> > *rules* but separate violations)  I still don't get the use case.
> >
> > As mentioned in the last taxonomy discussion, I still think we could
> > get rid of the tons of different "X close to Y" errors and just call
> > it a "clearance error", but I understand that might be more
> > contentious so I'd like to focus for now on just the keepouts and
> > vias.
> >
> > -Jon
> >
> > On Thu, Jun 11, 2020 at 6:51 AM Jeff Young  wrote:
> >>
> >> The “Inside Keepout” issue might be a bad example.  I’d definitely be in 
> >> favour of folding all of those into a single violation because a keepout 
> >> already specifies which types of things are excluded.
> >>
> >> But other things I’d be less in favour of.  I want a warning about NPTHs 
> >> in courtyards; I don’t want one for PTHs (the former likely has a 
> >> mechanical fixing, the later likely doesn't).
> >>
> >> While I don’t personally use uVias, I’d certainly think we’d want separate 
> >> violations for their holes (as they’re made with different technologies).  
> >> On the flip side, I’m not sure there’s any value in distinguishing between 
> >> throughVia holes and pad holes.
> >>
> >> But that gives us a different taxonomy for size vs. hole, as the 
> >> difference between uVia and throughVia size may not be important.  (We 
> >> already have this to some extent as I didn’t bother with separate annulus 
> >> violations for via types, although there’s a TODO in the code).
> >>
> >> This all begs the question “how bad is an uneven taxonomy”?  Is it just an 
> >> ivory-tower kind of thing, or will it actually cause confusion?
> >>
> >> Back to specific instances, I like being able to treat 
> >> track-too-close-to-connected-item separately from 
> >> track-to-close-to-unconnected-item, but I’m less fussed about the 
> >> differences between the type of connected item (track-to-close-to-via vs 
> >> track-to-close-to-track).  (For what it’s worth, unconnected items are 
> >> already grouped as we don’t have separate errors for 
> >> track-to-close-to-graphics vs track-to-close-to-text.  Yet another bit of 
> >> unevenness in the existing taxonomy.)
> >>
> >> Oddly I find the parallel-tracks vs crossing-tracks useful, but I have no 
> >> idea why.  I guess it just gives me a better idea of what I’m looking for 
> >> on the board?
> >>
> >> One last note: Greg’s request for specific exclusions is already in the 
> >> nightlies.
> >>
> >> Cheers,
> >> Jeff
> >>
> >>
> >>
> >>> On 11 Jun 2020, at 06:19, Greg Smith  wrote:
> >>>
> >>> I think more grouping in general categories is good. I also think that it 
> >>> would be nice to exclude *specific* DRCs that once a designer checks the 
> >>> error, they can flag it to ignore in the future. The specific check could 
> >>> be identified by a unique id: a hash of specific information, like unique 
> >>> error and objects involved (identified by geometries and properties 
> >>> involved). If anything changes, then the rule violation reappears under a 
> >>> different unique id. I think this would help greatly on near-tapeout 
> >>> activities where sifting over the same DRC errors becomes tedious and 
> >>> prone to missing valid DRC violations in the midst of “designer checked 
> >>> and allowed” ones.
> >>>
> >>> Greg S.
> >>>
>  On Jun 10, 2020, at 7:59 PM, Jon Evans  wrote:
> 
>  Hi all,
> 
>  A DRC error code is something like "Via inside keepout area", or in
>  the code, DRCE_VIA_INSIDE_KEEPOUT.  It describes a "type" of DRC
>  error.  This type is used for organizing the errors in the DRC report,
>  and more recently, for letting you set a severity
>  (error/warning/ignore) for each code.
> 
>  Currently we have a lot of DRC violation types, probably because the
>  violation types match up to 

Re: [Kicad-developers] Granularity of DRC error code

[Wayne Stambaugh]

I was thinking along the same lines.  Wouldn't it make more sense to
define the objects that violate a DRC rule and generate the error
message on the fly rather than adding violation error codes for every
possible error?

On 6/11/20 9:26 AM, Jon Evans wrote:
> I think microvias and vias using different technologies means they
> need different *rules*, not different error codes.
> 
> Whether a hole is laser or mechanically drilled, it will have some
> rules, and those rules could generate an error "hole size is outside
> allowed range".
> 
> You can tell from the affected items whether the hole in question is a
> via, microvia, blind via, buried via.
> You can tell from the rule source whether this came from a microvia
> rule, normal via rule, custom rule, etc.
> 
> Why should we have separate violations per via type?  (not separate
> *rules* but separate violations)  I still don't get the use case.
> 
> As mentioned in the last taxonomy discussion, I still think we could
> get rid of the tons of different "X close to Y" errors and just call
> it a "clearance error", but I understand that might be more
> contentious so I'd like to focus for now on just the keepouts and
> vias.
> 
> -Jon
> 
> On Thu, Jun 11, 2020 at 6:51 AM Jeff Young  wrote:
>>
>> The “Inside Keepout” issue might be a bad example.  I’d definitely be in 
>> favour of folding all of those into a single violation because a keepout 
>> already specifies which types of things are excluded.
>>
>> But other things I’d be less in favour of.  I want a warning about NPTHs in 
>> courtyards; I don’t want one for PTHs (the former likely has a mechanical 
>> fixing, the later likely doesn't).
>>
>> While I don’t personally use uVias, I’d certainly think we’d want separate 
>> violations for their holes (as they’re made with different technologies).  
>> On the flip side, I’m not sure there’s any value in distinguishing between 
>> throughVia holes and pad holes.
>>
>> But that gives us a different taxonomy for size vs. hole, as the difference 
>> between uVia and throughVia size may not be important.  (We already have 
>> this to some extent as I didn’t bother with separate annulus violations for 
>> via types, although there’s a TODO in the code).
>>
>> This all begs the question “how bad is an uneven taxonomy”?  Is it just an 
>> ivory-tower kind of thing, or will it actually cause confusion?
>>
>> Back to specific instances, I like being able to treat 
>> track-too-close-to-connected-item separately from 
>> track-to-close-to-unconnected-item, but I’m less fussed about the 
>> differences between the type of connected item (track-to-close-to-via vs 
>> track-to-close-to-track).  (For what it’s worth, unconnected items are 
>> already grouped as we don’t have separate errors for 
>> track-to-close-to-graphics vs track-to-close-to-text.  Yet another bit of 
>> unevenness in the existing taxonomy.)
>>
>> Oddly I find the parallel-tracks vs crossing-tracks useful, but I have no 
>> idea why.  I guess it just gives me a better idea of what I’m looking for on 
>> the board?
>>
>> One last note: Greg’s request for specific exclusions is already in the 
>> nightlies.
>>
>> Cheers,
>> Jeff
>>
>>
>>
>>> On 11 Jun 2020, at 06:19, Greg Smith  wrote:
>>>
>>> I think more grouping in general categories is good. I also think that it 
>>> would be nice to exclude *specific* DRCs that once a designer checks the 
>>> error, they can flag it to ignore in the future. The specific check could 
>>> be identified by a unique id: a hash of specific information, like unique 
>>> error and objects involved (identified by geometries and properties 
>>> involved). If anything changes, then the rule violation reappears under a 
>>> different unique id. I think this would help greatly on near-tapeout 
>>> activities where sifting over the same DRC errors becomes tedious and prone 
>>> to missing valid DRC violations in the midst of “designer checked and 
>>> allowed” ones.
>>>
>>> Greg S.
>>>
 On Jun 10, 2020, at 7:59 PM, Jon Evans  wrote:

 Hi all,

 A DRC error code is something like "Via inside keepout area", or in
 the code, DRCE_VIA_INSIDE_KEEPOUT.  It describes a "type" of DRC
 error.  This type is used for organizing the errors in the DRC report,
 and more recently, for letting you set a severity
 (error/warning/ignore) for each code.

 Currently we have a lot of DRC violation types, probably because the
 violation types match up to the underlying code that is doing the
 checking.  So, we also have a DRCE_MICROVIA_INSIDE_KEEPOUT and
 DRCE_BBVIA_INSIDE_KEEPOUT, because a lot of KiCad code has separate
 paths for those three types of vias.

 Do people find this useful?  I think it is too specific: I would
 rather see a single code DRCE_VIA_INSIDE_KEEPOUT to include all types
 of vias.  I could even see having a single code for any object inside
 a keepout that isn't supposed to be there.  I 

Re: [Kicad-developers] Granularity of DRC error code

[Jon Evans]

I think microvias and vias using different technologies means they
need different *rules*, not different error codes.

Whether a hole is laser or mechanically drilled, it will have some
rules, and those rules could generate an error "hole size is outside
allowed range".

You can tell from the affected items whether the hole in question is a
via, microvia, blind via, buried via.
You can tell from the rule source whether this came from a microvia
rule, normal via rule, custom rule, etc.

Why should we have separate violations per via type?  (not separate
*rules* but separate violations)  I still don't get the use case.

As mentioned in the last taxonomy discussion, I still think we could
get rid of the tons of different "X close to Y" errors and just call
it a "clearance error", but I understand that might be more
contentious so I'd like to focus for now on just the keepouts and
vias.

-Jon

On Thu, Jun 11, 2020 at 6:51 AM Jeff Young  wrote:
>
> The “Inside Keepout” issue might be a bad example.  I’d definitely be in 
> favour of folding all of those into a single violation because a keepout 
> already specifies which types of things are excluded.
>
> But other things I’d be less in favour of.  I want a warning about NPTHs in 
> courtyards; I don’t want one for PTHs (the former likely has a mechanical 
> fixing, the later likely doesn't).
>
> While I don’t personally use uVias, I’d certainly think we’d want separate 
> violations for their holes (as they’re made with different technologies).  On 
> the flip side, I’m not sure there’s any value in distinguishing between 
> throughVia holes and pad holes.
>
> But that gives us a different taxonomy for size vs. hole, as the difference 
> between uVia and throughVia size may not be important.  (We already have this 
> to some extent as I didn’t bother with separate annulus violations for via 
> types, although there’s a TODO in the code).
>
> This all begs the question “how bad is an uneven taxonomy”?  Is it just an 
> ivory-tower kind of thing, or will it actually cause confusion?
>
> Back to specific instances, I like being able to treat 
> track-too-close-to-connected-item separately from 
> track-to-close-to-unconnected-item, but I’m less fussed about the differences 
> between the type of connected item (track-to-close-to-via vs 
> track-to-close-to-track).  (For what it’s worth, unconnected items are 
> already grouped as we don’t have separate errors for 
> track-to-close-to-graphics vs track-to-close-to-text.  Yet another bit of 
> unevenness in the existing taxonomy.)
>
> Oddly I find the parallel-tracks vs crossing-tracks useful, but I have no 
> idea why.  I guess it just gives me a better idea of what I’m looking for on 
> the board?
>
> One last note: Greg’s request for specific exclusions is already in the 
> nightlies.
>
> Cheers,
> Jeff
>
>
>
> > On 11 Jun 2020, at 06:19, Greg Smith  wrote:
> >
> > I think more grouping in general categories is good. I also think that it 
> > would be nice to exclude *specific* DRCs that once a designer checks the 
> > error, they can flag it to ignore in the future. The specific check could 
> > be identified by a unique id: a hash of specific information, like unique 
> > error and objects involved (identified by geometries and properties 
> > involved). If anything changes, then the rule violation reappears under a 
> > different unique id. I think this would help greatly on near-tapeout 
> > activities where sifting over the same DRC errors becomes tedious and prone 
> > to missing valid DRC violations in the midst of “designer checked and 
> > allowed” ones.
> >
> > Greg S.
> >
> >> On Jun 10, 2020, at 7:59 PM, Jon Evans  wrote:
> >>
> >> Hi all,
> >>
> >> A DRC error code is something like "Via inside keepout area", or in
> >> the code, DRCE_VIA_INSIDE_KEEPOUT.  It describes a "type" of DRC
> >> error.  This type is used for organizing the errors in the DRC report,
> >> and more recently, for letting you set a severity
> >> (error/warning/ignore) for each code.
> >>
> >> Currently we have a lot of DRC violation types, probably because the
> >> violation types match up to the underlying code that is doing the
> >> checking.  So, we also have a DRCE_MICROVIA_INSIDE_KEEPOUT and
> >> DRCE_BBVIA_INSIDE_KEEPOUT, because a lot of KiCad code has separate
> >> paths for those three types of vias.
> >>
> >> Do people find this useful?  I think it is too specific: I would
> >> rather see a single code DRCE_VIA_INSIDE_KEEPOUT to include all types
> >> of vias.  I could even see having a single code for any object inside
> >> a keepout that isn't supposed to be there.  I can't imagine a
> >> situation where I would want to have a via inside a keepout be an
> >> error, but a microvia inside a keepout be a warning or an ignore
> >> (having the separate error codes means you can have seperate severity
> >> settings).  If I wanted to know if a particular DRC error referred to
> >> a via or a microvia, I can do that from 

Re: [Kicad-developers] Granularity of DRC error code

[Jeff Young]

The “Inside Keepout” issue might be a bad example.  I’d definitely be in favour 
of folding all of those into a single violation because a keepout already 
specifies which types of things are excluded.

But other things I’d be less in favour of.  I want a warning about NPTHs in 
courtyards; I don’t want one for PTHs (the former likely has a mechanical 
fixing, the later likely doesn't).

While I don’t personally use uVias, I’d certainly think we’d want separate 
violations for their holes (as they’re made with different technologies).  On 
the flip side, I’m not sure there’s any value in distinguishing between 
throughVia holes and pad holes.

But that gives us a different taxonomy for size vs. hole, as the difference 
between uVia and throughVia size may not be important.  (We already have this 
to some extent as I didn’t bother with separate annulus violations for via 
types, although there’s a TODO in the code).

This all begs the question “how bad is an uneven taxonomy”?  Is it just an 
ivory-tower kind of thing, or will it actually cause confusion?

Back to specific instances, I like being able to treat 
track-too-close-to-connected-item separately from 
track-to-close-to-unconnected-item, but I’m less fussed about the differences 
between the type of connected item (track-to-close-to-via vs 
track-to-close-to-track).  (For what it’s worth, unconnected items are already 
grouped as we don’t have separate errors for track-to-close-to-graphics vs 
track-to-close-to-text.  Yet another bit of unevenness in the existing 
taxonomy.)

Oddly I find the parallel-tracks vs crossing-tracks useful, but I have no idea 
why.  I guess it just gives me a better idea of what I’m looking for on the 
board?

One last note: Greg’s request for specific exclusions is already in the 
nightlies.

Cheers,
Jeff



> On 11 Jun 2020, at 06:19, Greg Smith  wrote:
> 
> I think more grouping in general categories is good. I also think that it 
> would be nice to exclude *specific* DRCs that once a designer checks the 
> error, they can flag it to ignore in the future. The specific check could be 
> identified by a unique id: a hash of specific information, like unique error 
> and objects involved (identified by geometries and properties involved). If 
> anything changes, then the rule violation reappears under a different unique 
> id. I think this would help greatly on near-tapeout activities where sifting 
> over the same DRC errors becomes tedious and prone to missing valid DRC 
> violations in the midst of “designer checked and allowed” ones.
> 
> Greg S.
> 
>> On Jun 10, 2020, at 7:59 PM, Jon Evans  wrote:
>> 
>> Hi all,
>> 
>> A DRC error code is something like "Via inside keepout area", or in
>> the code, DRCE_VIA_INSIDE_KEEPOUT.  It describes a "type" of DRC
>> error.  This type is used for organizing the errors in the DRC report,
>> and more recently, for letting you set a severity
>> (error/warning/ignore) for each code.
>> 
>> Currently we have a lot of DRC violation types, probably because the
>> violation types match up to the underlying code that is doing the
>> checking.  So, we also have a DRCE_MICROVIA_INSIDE_KEEPOUT and
>> DRCE_BBVIA_INSIDE_KEEPOUT, because a lot of KiCad code has separate
>> paths for those three types of vias.
>> 
>> Do people find this useful?  I think it is too specific: I would
>> rather see a single code DRCE_VIA_INSIDE_KEEPOUT to include all types
>> of vias.  I could even see having a single code for any object inside
>> a keepout that isn't supposed to be there.  I can't imagine a
>> situation where I would want to have a via inside a keepout be an
>> error, but a microvia inside a keepout be a warning or an ignore
>> (having the separate error codes means you can have seperate severity
>> settings).  If I wanted to know if a particular DRC error referred to
>> a via or a microvia, I can do that from the linked item information --
>> I don't need a category to tell me that.
>> 
>> What do you think?  Does having a lot of very specific error codes
>> help your workflow?  Would you miss these categories if some of them
>> got consolidated like the example I gave?  If so, are there other
>> changes we could make (or features we could add) that would make it
>> easier to deal with having less specific error codes?
>> 
>> Thanks,
>> Jon
>> 
>> ___
>> 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 : 

Re: [Kicad-developers] Granularity of DRC error code

[Greg Smith]

I think more grouping in general categories is good. I also think that it would 
be nice to exclude *specific* DRCs that once a designer checks the error, they 
can flag it to ignore in the future. The specific check could be identified by 
a unique id: a hash of specific information, like unique error and objects 
involved (identified by geometries and properties involved). If anything 
changes, then the rule violation reappears under a different unique id. I think 
this would help greatly on near-tapeout activities where sifting over the same 
DRC errors becomes tedious and prone to missing valid DRC violations in the 
midst of “designer checked and allowed” ones.

Greg S.

> On Jun 10, 2020, at 7:59 PM, Jon Evans  wrote:
> 
> Hi all,
> 
> A DRC error code is something like "Via inside keepout area", or in
> the code, DRCE_VIA_INSIDE_KEEPOUT.  It describes a "type" of DRC
> error.  This type is used for organizing the errors in the DRC report,
> and more recently, for letting you set a severity
> (error/warning/ignore) for each code.
> 
> Currently we have a lot of DRC violation types, probably because the
> violation types match up to the underlying code that is doing the
> checking.  So, we also have a DRCE_MICROVIA_INSIDE_KEEPOUT and
> DRCE_BBVIA_INSIDE_KEEPOUT, because a lot of KiCad code has separate
> paths for those three types of vias.
> 
> Do people find this useful?  I think it is too specific: I would
> rather see a single code DRCE_VIA_INSIDE_KEEPOUT to include all types
> of vias.  I could even see having a single code for any object inside
> a keepout that isn't supposed to be there.  I can't imagine a
> situation where I would want to have a via inside a keepout be an
> error, but a microvia inside a keepout be a warning or an ignore
> (having the separate error codes means you can have seperate severity
> settings).  If I wanted to know if a particular DRC error referred to
> a via or a microvia, I can do that from the linked item information --
> I don't need a category to tell me that.
> 
> What do you think?  Does having a lot of very specific error codes
> help your workflow?  Would you miss these categories if some of them
> got consolidated like the example I gave?  If so, are there other
> changes we could make (or features we could add) that would make it
> easier to deal with having less specific error codes?
> 
> Thanks,
> Jon
> 
> ___
> 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