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 <j...@craftyjon.com> 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 <j...@rokeby.ie> wrote: >> >> (But I do like being able to assign a severity to a rule.) >> >> On 11 Jun 2020, at 15:22, Jeff Young <j...@rokeby.ie> 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 <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 >> >> >> _______________________________________________ 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
