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. Keeping annulus separate from via diameter is fine. Can you explain a situation where it makes sense to have e.g. through-via drill be a warning but uVia drill be an error or vice-versa? This is what I don't understand. On Thu, Jun 11, 2020 at 11:24 AM Jeff Young <[email protected]> wrote: > > 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 production > constraint) and via size (possibly just a current/heat constraint). > > I’m still on the fence with throughVia drill vs. uVia drill. The rest I can > agree with. > > Cheers, > Jeff. > > > > On 11 Jun 2020, at 15:56, Jon Evans <[email protected]> wrote: > > > > 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 it harder to > > sort through that information (for me at least). > > > > I don't think we need to be able to set severities independently for > > each rule in the "classic" system, we just need enough different > > severity settings to make sense. > > > > For example, going down the classic DRC rules dialog: > > > > Allowed features: both checkboxes generate DRCE_ALLOWED_FEATURES > > Arc/circle and zone fill: these aren't actually DRC checks > > Copper min clearance: generates DRCE_CLEARANCE > > Min track width: generates DRCE_WIDTH > > Min via annulus: generates DRCE_VIA_SIZE > > Min via diameter: generates DRCE_VIA_SIZE > > Copper edge clearance: generates DRCE_CLEARANCE > > Min through hole: generates DRCE_HOLE_SIZE > > Hole to hole: generates DRCE_HOLE_CLEARANCE > > uVia diameter: generates DRCE_VIA_SIZE > > uVia drill: generates DRCE_HOLE_SIZE > > > > > > > > On Thu, Jun 11, 2020 at 10:42 AM Jeff Young <[email protected]> wrote: > >> > >> 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 <[email protected]> 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 <[email protected]> wrote: > >>>> > >>>> (But I do like being able to assign a severity to a rule.) > >>>> > >>>> On 11 Jun 2020, at 15:22, Jeff Young <[email protected]> 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 <[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]> 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]> > >>>>> 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]> 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]> 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]> 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 : [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 > >>>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> 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 > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >>>> > >>>> > >>>> > >> > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
