On 26.07.2017 22:01, Wayne Stambaugh wrote: > On 7/26/2017 9:47 AM, hauptmech wrote: >> This is a nice concept. A more generic constraint system. >> >> What I'll be doing and was asking if there was others needing, is the >> pre-net-class approach of a single clearance that is easily adjusted >> while laying tracks. > > What you want is a change to the router to allow you do this not change > the actual netclass. Changing the netclass in the middle of a route if > fraught with peril. If you start out with a netclass with a larger > clearance and then change to a netclass with a smaller clearance, the > DRC will fail every time. I suppose you could add a context menu action > to allow you to increase the route clearance specified by the current > netclass (along with trace width, via, via drill etc as long as the > project minimums are not violated). Allowing the user to decrease the > clearance would result in a DRC violation. > Hi Wayne,
I don't think changing just the router would fix that. Of course I could allow temporary changes of the clearance of some part of a particular track being routed (e.g. through a context menu, as you suggested) - but once the track has been placed, the whole information about its reduced/increased clearance will be lost. Hence, the DRC would not detect it. Cheers, Tom >> >> I think this used to be there. Having it would not affect netclass >> behaviour or drc behaviour, but would allow manual control of clearance >> for the situations where useful. >> >> On 27/07/17 01:17, Maciej Sumiński wrote: >>> Hi hauptmech, >>> >>> I am sure there are many users who would benefit from the suggested DRC >>> improvements, so I would say it is an interesting idea. There is a plan >>> to upgrade it, but I am afraid you will have you board finished before >>> this happens. >>> >>> It is not entirely clear to me what do you propose. At the moment there >>> is an option to set clearance per net class, so I assume you want to be >>> able to set clearance per [net class,layer] pair. How do you want to >>> modify the user interface (Design Rules Editor dialog)? >>> >>> I am not sure how much time are you willing to spend on this, but if I >>> were to implement such feature, then I would: >>> - in the "Net Classes Editor" remove the grid widget where you specify >>> the constraints (clearance, track width, etc.) >>> - add a new tab "Constraints" with a list widget and two buttons: "Add" >>> and "Remove" >>> - the "Add" button invokes a dialog where you can specify the target for >>> the rule (Net/Net Class/Layer) and the type of constraint you want to >>> apply (clearance, track width, etc). For each category used to specify >>> the target (Net/Net Class/Layer) one selects 'Any' or a concrete value. >>> >>> This way the design rules definition become very flexible as you may >>> easily specify exact targets. In case there is more than one rule for an >>> item, the strictest one applies. For items that do not trigger any of >>> the rules, the global design rules are used. >>> >>> To give an rule set example with your case: >>> - global design rules: whatever your PCB house is able to manufacture >>> - inner layers, any net: 0.1 mm width >>> - outer layers, any net: 0.3 mm width >>> >>> Regards, >>> Orson >>> >>> On 07/26/2017 10:05 AM, hauptmech wrote: >>>> I have nets that have different clearance requirements depending on >>>> where they are. There are two situations that are in my designs: >>>> >>>> 1) Technical/Manufacturing limitations: Trace and space limitations >>>> depend on layer copper thickness and whether it's an inner layer or >>>> outer layer. For instance, my current project has 0.1mm trace and space >>>> and a 15um thick copper layer on one pair of inner layers. Outer layers >>>> are 30um and use 0.125mm minimum trace and space because 0.1 can't be >>>> done at that copper thickness. >>>> >>>> 2) Designers preference: I like to move to larger traces and spaces when >>>> the component spacing allows. Apart from a mild optimization on current >>>> carrying capacity and capacitive coupling, there is not a big technical >>>> reason; it's just the way I like to do things. >>>> >>>> Both of these things have me manually changing the default netclass >>>> clearance constantly, and when I forget to change it back to the larger >>>> trace and space I have to redo chunks of layout. Happens more often that >>>> I'd like to admit. A sign of aging I guess. >>>> >>>> Running the DRC I first do a pass at the lowest clearance, and then >>>> (doing this now) run the same DRC on a larger clearance and check each >>>> error to see if it's real (many are) or allowed for the layer and >>>> location manually. >>>> >>>> There's a lot of ways to approach this issue and a 'good' way to do this >>>> has not occured to me yet. Meanwhile I have work to do. I'm seeing a big >>>> chunk of work in 2013 by Dick on the netclass and vaguely remember >>>> clearance being as settable as trace width once upon a time. >>>> >>>> Pulling forward the old clearance setting widgets and possibly allow >>>> specifying layers for the DRC are what I'm looking at doing in my >>>> personal branch. Probably add a 'netclass' default entry in the >>>> clearance dropdown I am remembering >>>> >>>> All this to ask, does anyone else have issues with the netclass approach >>>> to clearance and would the mainline want an integration of both netclass >>>> and manually set clearances? >>>> >>>> -hauptmech >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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
