date:20200516

Re: [Kicad-developers] DRC rules

2020-05-16 Thread Jeff Young

I got tired of my text editor not highlighting matching parens so there’s now a 
basic rule editor in Board Setup > Design Rules > Rules.

> On 16 May 2020, at 17:02, Jon Evans  wrote:
> 
> Thanks Jeff, this is awesome.  I look forward to trying it out.
> 
> On Sat, May 16, 2020 at 12:00 PM Jeff Young  > wrote:
> Here’s a really dumb test file just so you can get an idea of what it looks 
> like:
> 
> (version 1)
> (selector (match_netclass "Default") (rule "Big Gap"))
> (selector (match_type track) (rule "Big Gap"))
> (rule "Big Gap" (clearance 1.5))
> (selector (match_type blind_via) (rule "Big Hole"))
> (rule "Big Hole" (hole 2))
> (rule "Small Edge" (clearance 2))
> (rule "Big Edge" (clearance 3))
> (selector (match_type board_edge) (rule "Small Edge"))
> (selector (match_layer "In1.Cu") (match_type board_edge) (rule "Big Edge") 
> (priority 2))
> 
> 
>> On 16 May 2020, at 16:43, Jeff Young > > 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:

Re: [Kicad-developers] DRC rules

2020-05-16 Thread Jon Evans

Thanks Jeff, this is awesome.  I look forward to trying it out.

On Sat, May 16, 2020 at 12:00 PM Jeff Young  wrote:

> Here’s a really dumb test file just so you can get an idea of what it
> looks like:
>
> (version 1)
> (selector (match_netclass "Default") (rule "Big Gap"))
> (selector (match_type track) (rule "Big Gap"))
> (rule "Big Gap" (clearance 1.5))
> (selector (match_type blind_via) (rule "Big Hole"))
> (rule "Big Hole" (hole 2))
> (rule "Small Edge" (clearance 2))
> (rule "Big Edge" (clearance 3))
> (selector (match_type board_edge) (rule "Small Edge"))
> (selector (match_layer "In1.Cu") (match_type board_edge) (rule "Big Edge")
> (priority 2))
>
>
> On 16 May 2020, at 16:43, Jeff Young  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
>
___
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

Re: [Kicad-developers] DRC rules

2020-05-16 Thread Jeff Young

Here’s a really dumb test file just so you can get an idea of what it looks 
like:

(version 1)
(selector (match_netclass "Default") (rule "Big Gap"))
(selector (match_type track) (rule "Big Gap"))
(rule "Big Gap" (clearance 1.5))
(selector (match_type blind_via) (rule "Big Hole"))
(rule "Big Hole" (hole 2))
(rule "Small Edge" (clearance 2))
(rule "Big Edge" (clearance 3))
(selector (match_type board_edge) (rule "Small Edge"))
(selector (match_layer "In1.Cu") (match_type board_edge) (rule "Big Edge") 
(priority 2))


> On 16 May 2020, at 16:43, Jeff Young  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

[Kicad-developers] DRC rules

2020-05-16 Thread Jeff Young

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

Re: [Kicad-developers] Requesting maintainership for KiCad manifest on flathub.org

2020-05-16 Thread Johannes Maibaum

Hi Nick,
Am Samstag, den 16.05.2020, 15:50 +0200 schrieb Nick Østergaard:
> I am not aware of who the maintainer of the flatpak is, nor do I think
> he may follow this list closely.

>From what I can say, so far the flatpak has been maintained by whoever
sent in a PR, and it was updated whenever one of the main flathub
maintainers found time to review the PR.
Johannes
> But it would certanly be good to get the package updated to be on part
> with other packages.
> 
> Nick
> 
> lør. 16. maj 2020 12.27 skrev Johannes Maibaum :
> > Hello KiCad team,
> > 
> > 
> > 
> > during the past months, I have been updating the KiCad flatpak on
> > 
> > flathub.org from time to time, via PRs to 
> > 
> > https://github.com/flathub/org.kicad_pcb.KiCad (I am preparing the
> > 
> > update to KiCad 5.1.6 right now as well).
> > 
> > 
> > 
> > There are a few pending issues with the current flatpak build
> > manifest
> > 
> > for KiCad which I'd like to address: Activating Python scripting
> > 
> > support, adding the docs, and generally updating various
> > dependencies
> > 
> > would be my next steps.
> > 
> > 
> > 
> > I was recently being asked by another user if I would like to
> > request
> > 
> > the maintainership of the KiCad manifest on flathub, and I am now
> > 
> > contemplating to do so. But, since I did only contribute a few tiny-
> > tiny 
> > 
> > things to KiCad in the past, I wanted to ask the core
> > 
> > packagers/developers first, if anyone else would take over the
> > 
> > maintainership instead?
> > 
> > 
> > 
> > 
> > 
> > Cheers,
> > 
> > Johannes
> > 
> > ___
> > 
> > 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

Re: [Kicad-developers] Requesting maintainership for KiCad manifest on flathub.org

2020-05-16 Thread Nick Østergaard

I am not aware of who the maintainer of the flatpak is, nor do I think he
may follow this list closely.

But it would certanly be good to get the package updated to be on part with
other packages.

Nick

lør. 16. maj 2020 12.27 skrev Johannes Maibaum :

> Hello KiCad team,
>
> during the past months, I have been updating the KiCad flatpak on
> flathub.org from time to time, via PRs to
> https://github.com/flathub/org.kicad_pcb.KiCad (I am preparing the
> update to KiCad 5.1.6 right now as well).
>
> There are a few pending issues with the current flatpak build manifest
> for KiCad which I'd like to address: Activating Python scripting
> support, adding the docs, and generally updating various dependencies
> would be my next steps.
>
> I was recently being asked by another user if I would like to request
> the maintainership of the KiCad manifest on flathub, and I am now
> contemplating to do so. But, since I did only contribute a few tiny-tiny
> things to KiCad in the past, I wanted to ask the core
> packagers/developers first, if anyone else would take over the
> maintainership instead?
>
>
> Cheers,
> Johannes
> ___
> 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

[Kicad-developers] Requesting maintainership for KiCad manifest on flathub.org

2020-05-16 Thread Johannes Maibaum

Hello KiCad team,

during the past months, I have been updating the KiCad flatpak on
flathub.org from time to time, via PRs to 
https://github.com/flathub/org.kicad_pcb.KiCad (I am preparing the
update to KiCad 5.1.6 right now as well).

There are a few pending issues with the current flatpak build manifest
for KiCad which I'd like to address: Activating Python scripting
support, adding the docs, and generally updating various dependencies
would be my next steps.

I was recently being asked by another user if I would like to request
the maintainership of the KiCad manifest on flathub, and I am now
contemplating to do so. But, since I did only contribute a few tiny-tiny 
things to KiCad in the past, I wanted to ask the core
packagers/developers first, if anyone else would take over the
maintainership instead?


Cheers,
Johannes


signature.asc
Description: This is a digitally signed message part
___
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

Re: [Kicad-developers] DRC rules

Re: [Kicad-developers] DRC rules

Re: [Kicad-developers] DRC rules

[Kicad-developers] DRC rules

Re: [Kicad-developers] Requesting maintainership for KiCad manifest on flathub.org

Re: [Kicad-developers] Requesting maintainership for KiCad manifest on flathub.org

[Kicad-developers] Requesting maintainership for KiCad manifest on flathub.org

7 matches

Site Navigation

Mail list logo

Footer information