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
