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

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, Je

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

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.

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

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 pro

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

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 unif

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

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 originat

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

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

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

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

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

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

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

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, f

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

> 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

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

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 dif

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

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 Yo

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

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

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

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 d

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

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 mod

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

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

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

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

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

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

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

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 prod

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

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.

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

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 b

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

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

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

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

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

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

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

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 t

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

(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 > > wrot

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

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 importa

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

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 betwee

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

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

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

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 err

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

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

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

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 diffe

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

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 affec

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

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

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

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 e