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 <[email protected]> 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > > > <mailto:[email protected]>> 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 <[email protected] > > >>> <mailto:[email protected]>> 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 <[email protected] > > >>>> <mailto:[email protected]>> 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 > > >>>> <https://launchpad.net/~kicad-developers> > > >>>> Post to : [email protected] > > >>>> <mailto:[email protected]> > > >>>> Unsubscribe : https://launchpad.net/~kicad-developers > > >>>> <https://launchpad.net/~kicad-developers> > > >>>> More help : https://help.launchpad.net/ListHelp > > >>>> <https://help.launchpad.net/ListHelp> > > >>> > > >>> > > >>> _______________________________________________ > > >>> Mailing list: https://launchpad.net/~kicad-developers > > >>> <https://launchpad.net/~kicad-developers> > > >>> Post to : [email protected] > > >>> <mailto:[email protected]> > > >>> Unsubscribe : https://launchpad.net/~kicad-developers > > >>> <https://launchpad.net/~kicad-developers> > > >>> More help : https://help.launchpad.net/ListHelp > > >>> <https://help.launchpad.net/ListHelp> > > >> > > > > > > _______________________________________________ > > > Mailing list: https://launchpad.net/~kicad-developers > > > <https://launchpad.net/~kicad-developers> > > > Post to : [email protected] > > > <mailto:[email protected]> > > > Unsubscribe : https://launchpad.net/~kicad-developers > > > <https://launchpad.net/~kicad-developers> > > > More help : https://help.launchpad.net/ListHelp > > > <https://help.launchpad.net/ListHelp> > > > > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~kicad-developers > > <https://launchpad.net/~kicad-developers> > > Post to : [email protected] > > <mailto:[email protected]> > > Unsubscribe : https://launchpad.net/~kicad-developers > > <https://launchpad.net/~kicad-developers> > > More help : https://help.launchpad.net/ListHelp > > <https://help.launchpad.net/ListHelp> > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > <https://launchpad.net/~kicad-developers> > Post to : [email protected] > <mailto:[email protected]> > Unsubscribe : https://launchpad.net/~kicad-developers > <https://launchpad.net/~kicad-developers> > More help : https://help.launchpad.net/ListHelp > <https://help.launchpad.net/ListHelp> > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
