Jeff, A definite +1 for that from over here! Thanks for the clarification.
Yours, James. On Thu, May 21, 2020 at 1:33 PM Jeff Young <j...@rokeby.ie> wrote: > While the prototype is selector-based the “real” implementation is likely > to be expression-based, so you’ll be able to say something like: > > (rule “my special rule” … (condition “A.net == B.net”)) > > Cheers, > Jeff. > > > On 21 May 2020, at 12:19, James Jackson <james.a.f.jackso...@gmail.com> > wrote: > > Hi Jeff, > > The background is that I'm looking at a ruleset which has different rules > depending on whether two neighbouring vias are in the same, or different, > nets. Running the risk of 'feature creep', of course, I think the > constraints can indeed be met by what is there, but I suppose my question > (and apologies for think out loud - the nature of the beast!) can be > considered as 'Can a rule be matched based on whether the two objects are > in the same, or different, nets?' Of course, this could be done by matching > all permutations and combinations of nets, but that would become a > combinatorial nightmare! > > Yours, > James. > > > On Thu, May 21, 2020 at 11:29 AM Jeff Young <j...@rokeby.ie> wrote: > >> Hi James, >> >> It sounds like you’re looking for hole-to-hole min. That’s in the >> existing constraints system in 5.99; you don’t need rules for that. >> >> Or does your hole-to-hole min depend on the specific via, specific >> netclass, or something else? (The current hole-to-hole min is board-wide.) >> >> Cheers, >> Jeff >> >> >> On 21 May 2020, at 10:54, James Jackson <james.a.f.jackso...@gmail.com> >> wrote: >> >> Hi Jeff, >> >> Many thanks for this - looks very powerful, and when it gets hooked in to >> the PNS router will be killer. An issue I'm currently grappling with a >> variety of rules considering placements around vias. Some rules require a >> distance measured from the outside of the annular ring to a track (or >> another annular ring outer edge), and some from the outside of a hole (i.e. >> the inside of the annular ring) to the nearest other outside edge of a >> hole. I suspect the former is achieved with what is currently there, but is >> the latter possible? It's essentially a question of where via-to-via >> measurements are made. >> >> Thanks, >> James. >> >> >> >> On Sat, May 16, 2020 at 4:44 PM Jeff Young <j...@rokeby.ie> wrote: >> >>> I’ve just merged a possible implementation of the DRC rules. I’d like >>> to get some feedback on it, and also some testing. (Because the rules >>> support such a wide range of possibilities it’s going to need a good deal >>> of testing.) >>> >>> For now, it picks up DRC rules from a file named “drc-rules” in the >>> project directory. >>> >>> There’s no GUI editor at present: use a text editor. >>> >>> Grammar is s-expr. It generally follows the ideas set down here: >>> >>> >>> https://docs.google.com/document/d/1qvCH9aHwCzp5qtKTna4jJXuloNU0b96gAxAHSKPuXpU >>> >>> with one major exception: I found the select-a-single-rule didn’t pan >>> out. You have to duplicate too much stuff in each rule for that. >>> >>> Also, because the DRC engine (and zone filler) don’t currently support >>> min/opt/max the prototype implements min with Seth’s “relaxed” option. >>> >>> Top level is a list; first expression must be (version x) followed by >>> any number of (selector…) and (rule…) expressions. >>> >>> /* >>> * Match tokens: >>> * match_netclass >>> * match_type >>> * match_layer >>> * match_all >>> * match_area (not yet implemented with the exception of “$board”, >>> which matches everything) >>> * >>> * (selector (match_area "$board") (rule "OSHParkClass3") (priority >>> 100)) >>> * >>> * (selector (match_netclass "HV") (rule "HV_internal")) >>> * (selector (match_netclass "HV") (match_layer "F_Cu") (rule >>> "HV_external")) >>> * (selector (match_netclass "HV") (match_layer "B_Cu") (rule >>> "HV_external")) >>> * >>> * (selector (match_netclass "HV") (match_netclass "HV") (rule "HV2HV")) >>> * (selector (match_netclass "HV") (match_netclass "HV") (match_layer >>> "F_Cu") (rule "HV2HV_external")) >>> * (selector (match_netclass "HV") (match_netclass "HV") (match_layer >>> "B_Cu") (rule "HV2HV_external")) >>> * >>> * TODO: pads for connector pins or wire pads have even larger required >>> creepage clearances. How to encode? >>> * User attributes on parent footprint? >>> * >>> * (selector (match_netclass "HV") (match_type "pad") (match_netclass >>> "HV") (match_type "pad") (rule "pad2PadHV")) >>> * >>> * (selector (match_netclass "signal") (match_area "BGA") (rule >>> "neckdown")) >>> * >>> * Type tokens: >>> * track >>> * via >>> * micro_via >>> * blind_via >>> * pad >>> * zone >>> * text >>> * graphic >>> * board_edge >>> * hole >>> * npth >>> * pth >>> * >>> * Rule tokens: >>> * allow (not yet implemented) >>> * clearance >>> * annulus_width >>> * track_width >>> * hole >>> * >>> * Rule modifiers: >>> * relaxed >>> * >>> * (rule "HV" (clearance 200) (priority 200)) >>> * (rule "HV_external" (clearance 400) (priority 200)) >>> * (rule "HV2HV" (clearance 200) (priority 200)) >>> * (rule "HV2HV_external" (clearance 500) (priority 200)) >>> * (rule "pad2padHV" (clearance 500) (priority 200)) >>> * >>> * (rule "signal" (clearance 20)) // implied >>> priority of 1 >>> * (rule "neckdown" (clearance relaxed 15) (priority 2)) >>> * >>> * (rule "allowMicrovias" (allow microvia)) >>> */ >>> >>> >>> _______________________________________________ >>> 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
