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 <ian.s.mciner...@ieee.org> 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 <j...@craftyjon.com> 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 <stambau...@gmail.com> 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 <j...@rokeby.ie> 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 <ecomput...@yahoo.com> 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 <j...@craftyjon.com> 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 : kicad-developers@lists.launchpad.net >> > > Unsubscribe : https://launchpad.net/~kicad-developers >> > > More help : https://help.launchpad.net/ListHelp >> > > >> > >> > _______________________________________________ >> > Mailing list: https://launchpad.net/~kicad-developers >> > Post to : kicad-developers@lists.launchpad.net >> > Unsubscribe : https://launchpad.net/~kicad-developers >> > More help : https://help.launchpad.net/ListHelp >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
