Re: [Kicad-developers] Stable release 4.0.7 status.

[Wayne Stambaugh]

Thank you Rene!

What else needs to be done so we can get the packages built?

On 8/23/2017 6:51 PM, Rene Pöschl wrote:
> On 22/08/17 14:53, Wayne Stambaugh wrote:
>> Sorry about the delay but I was dealing with a family emergency all last
>> week.  Now that I'm getting caught up I really need to get stable
>> version 4.0.7 released.  Are there any outstanding issue remaining
>> before I make the release announcement?  I'm shooting for Friday or
>> Saturday.
>>
>> On 8/17/2017 8:45 AM, Rene Pöschl wrote:
>>> On 16/08/17 01:35, Wayne Stambaugh wrote:
 AFAIK we intend to use the 4.0.6 tag for libraries, docs, and i18n. 
 The
 libraries in particular have changed significantly and I think it's a
 bad idea to break users schematics on a point release.
>>> Does the default setup of kicad use the github plugin to get up do date
>>> footprints?
>> Github.
>>
>>> If so this will create inconsistencies within the lib. (If the symbol
>>> and 3d model libs are not updated as well)
>> I hadn't thought about that but you are correct.  Maybe it makes sense
>> to tag the library repo where it stands right now.  That being said, as
>> the footprints and library repo change, they may (will) eventually get
>> out of sync so this isn't an ideal solution.
> 
> I created the 4.0.7 tag on all our libs. (Well 4 footprint libs do not
> have tags yet because i do not have write access to these 4 libs. The
> good news is that these are very new libs with only a handful of
> footprints in them.)
> 
>>
>>> In particular there might be a problem if either a footprint has been
>>> renamed.
>>> (Footprint field or footprint filters of a symbol is now wrong.)
>>>
>>> Or if the scaling, offset or rotation of 3d models changed within a
>>> footprints 3d model settings.
>>> (We got a lot of new correctly scaled models since the 4.0.6 release)
>>>
>>> In my opinion it would be best if users can control when they receive
>>> new libraries.
>>> Each update should make sure that all 3 types of libraries are updated
>>> at the same time. (to the same version)
>> Unfortunately, we are not set up to handle this at the moment and I
>> would not ask our package devs to fix this for the 4.0.7 release.  It is
>> certainly something worth considering for the 5 stable release.
> I am aware of the fact that over time the libs will again get out of
> sync. (I think everyone involved with the library is aware of this fact.)
> The impact of our scaling changes will be reduced if users get an update
> of the 3d lib.
> 
> 
> 
> ___
> 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] Stable release 4.0.7 status.

[Rene Pöschl]

On 22/08/17 14:53, Wayne Stambaugh wrote:

Sorry about the delay but I was dealing with a family emergency all last
week.  Now that I'm getting caught up I really need to get stable
version 4.0.7 released.  Are there any outstanding issue remaining
before I make the release announcement?  I'm shooting for Friday or
Saturday.

On 8/17/2017 8:45 AM, Rene Pöschl wrote:

On 16/08/17 01:35, Wayne Stambaugh wrote:

AFAIK we intend to use the 4.0.6 tag for libraries, docs, and i18n.  The
libraries in particular have changed significantly and I think it's a
bad idea to break users schematics on a point release.

Does the default setup of kicad use the github plugin to get up do date
footprints?

Github.


If so this will create inconsistencies within the lib. (If the symbol
and 3d model libs are not updated as well)

I hadn't thought about that but you are correct.  Maybe it makes sense
to tag the library repo where it stands right now.  That being said, as
the footprints and library repo change, they may (will) eventually get
out of sync so this isn't an ideal solution.


I created the 4.0.7 tag on all our libs. (Well 4 footprint libs do not 
have tags yet because i do not have write access to these 4 libs. The 
good news is that these are very new libs with only a handful of 
footprints in them.)





In particular there might be a problem if either a footprint has been
renamed.
(Footprint field or footprint filters of a symbol is now wrong.)

Or if the scaling, offset or rotation of 3d models changed within a
footprints 3d model settings.
(We got a lot of new correctly scaled models since the 4.0.6 release)

In my opinion it would be best if users can control when they receive
new libraries.
Each update should make sure that all 3 types of libraries are updated
at the same time. (to the same version)

Unfortunately, we are not set up to handle this at the moment and I
would not ask our package devs to fix this for the 4.0.7 release.  It is
certainly something worth considering for the 5 stable release.
I am aware of the fact that over time the libs will again get out of 
sync. (I think everyone involved with the library is aware of this fact.)
The impact of our scaling changes will be reduced if users get an update 
of the 3d lib.




___
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] Additional Patch for via properties dialog (2)

[Oliver Walters]

To clarify, I agree fully that critical functionality should be core. Extra
functionality could be available via an exposed scripting interface, which
I suppose is already available via the existing python framework.

On 23 Aug 2017 14:55, "Wayne Stambaugh"  wrote:

> On 8/23/2017 8:49 AM, Tomasz Wlostowski wrote:
> > On 23.08.2017 14:05, Wayne Stambaugh wrote:
> >> This is the missing piece of the puzzle.  We would need to create a
> >> constraints manager to handle a list of constraints which could either
> >> be an internally defined constraint or a custom python constraint.
> >> Without a well defined interface, this would be a mess.
> >
> > If I may add my 5 cents: no python please for any *critical*
> > functionality of Kicad, like the DRC. I can only imagine expensive
> > boards coming back from production because somebody didn't have python
> > DRC plugins installed/configured.
>
> Agreed, that is why I suggested python for custom stuff.  All standard
> constraints and checks would be written in C++.
>
> >
> > Concerning new DRC plans - a rewrite of DRC is in the V6 roadmap:
> >
> > 
> >
> > Design Rule Check (DRC) Improvements.
> >
> > Goal:
> >
> > Create additional DRC tests for improved error checking.
> >
> > Task:
> >
> > Replace geometry code with unified geometry library.
> > Remove floating point code from clearance calculations to prevent
> > rounding errors.
> > Add checks for component, silk screen, and mask clearances.
> > Add checks for keep out zones.
> > Remove DRC related limitations such as no arc or text on copper
> layers.
> > Add option for saving and loading DRC options.
> >
> > 
> >
> > We need specifications for both the constraint manager & the DRC checks
> > to be implemented. Would anybody here volunteer to write the specs or
> > design the UI?
> >
> > Cheers,
> > Tom
> >
>
> ___
> 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] [PATCH] Change track width setting to dropbox

[Mathias Grimmberger]

Hi Wayne,

Wayne Stambaugh  writes:

> Rather than add a wxComboBox to the WX_UNIT_BINDER object, wouldn't be
> be cleaner to change wxTextCtrl* to wxTextEntry* which wxComboBox and
> wxTextCtrl (along with several others) are derived from?

Yes, of course, I will change that.

I just noticed that my documentation for wxWidgets was badly out of
date and so didn't show the useful base class...


MGri

___
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] cmakeified wxFormBuilder fork

[Mark Roszko]

I didn't write that patch. It was Blair Bonnett.

I just took a look at the wxformbuilder github...its still using their
luamake abomination, ugh.

On Mon, Aug 21, 2017 at 3:12 PM, jp charras  wrote:
> Le 15/09/2015 à 21:07, Mark Roszko a écrit :
>> https://github.com/marekr/wxFormBuilder
>>
>> Is there any interest in a cmakeified version/fork of wxFormBuilder?
>> Because I know accessability of the wxfb is a problem given the
>> abomination its "original" build system is.
>>
>> Its actually super super easy to build now.
>>
>> The master is at the 3.05.02 (RC2) but I threw in a commit from Blair
>> Bonnet that got ignored in the main sourceforge repo.
>> https://github.com/marekr/wxFormBuilder/commit/a4aade70723fe0dd7eeb47737955bf11d1c7bd15
>>
>> Just for giggles.
>
> Hi Mark,
>
> Your patch was recently added to wxFormBuilder!
> (see commit 47eac3915d32b5f11d025dd6446aae616fc782c7)
>
> Just an issue: on the toolbar, the icon is incorrect: this is the dummy icon.
>
>
> --
> Jean-Pierre CHARRAS



-- 
Mark

___
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] Calling PCB_DRAW_PANEL_GAL::SyncLayersVisibility from python?

[Greg Smith]

Better formatting:
How do you get PCB_EDIT_FRAME functions exposed to python?
I've been looking around the source code tosee how to expose them. 
Specifically, PCB_EDIT_FRAME::syncLayerVisibilities, and other PCB_EDIT_FRAME 
functions.
It looks like to me the definitions are in
pcbnew/pcbframe.cpp
and the declarations are in
include/wxPcbStruct.h

And the relevant swig files are in
pcbnew/swig/pcbnew.i

Is it correct that modification of pcbnew.i to either
1) (excerpt)
%include 
%include 
%include 

or 2)
%include wxPcbStruct.i
(and have some method for generating wxPcbStruct.i)?

The functions I'm wanting are declared in C++ as "protected:". Does thishave 
any implications for running them from python through SWIG?
Finally, how do you make sure that all argument types are accessible from 
python as well? 

On Tuesday, August 22, 2017 1:02 PM, jp charras  
wrote:
 

 Le 22/08/2017 à 19:33, Greg Smith a écrit :
> Continuing to review, it appears I am wrong. PCB_EDIT_FRAME:sLV does in fact 
> synchronize the
> checkboxes, but also calls PCB_DRAW_PANEL_GAL::SLV to do the background 
> synchronization of the layers.
> 
> Thank you jp, and I apologize for not researching sufficiently your answer 
> before posting.
> 
> So at this point, how do we get PCB_EDIT_FRAME:sLV exposed in python?
> 
> void PCB_EDIT_FRAME::syncLayerVisibilities    (        )    
> 
>     protected
> 

Certainly the Python interface needs a few specific and "easy to call" methods 
to update the GUI and
the canvases, when a board is modified by a python script.

The "legacy" canvas is easy to update, but the GAL canvas has a lot of cached 
data, so it needs a
rebuild method.

I'll try to add this kind of methods. But remember: I have a (very) poor 
knowledge of Python.

Also, I'll not be able to work on Kicad next 3 days.

-- 
Jean-Pierre CHARRAS

___
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] Calling PCB_DRAW_PANEL_GAL::SyncLayersVisibility from python?

[Greg Smith]

How do you get PCB_EDIT_FRAME functions exposed to python?
I've been looking around the source code tosee how to expose them. 
Specifically, PCB_EDIT_FRAME::syncLayerVisibilities, and other PCB_EDIT_FRAME 
functions.
It looks like to me the definitions are inpcbnew/pcbframe.cppand the 
declarations are ininclude/wxPcbStruct.h
And the relevant swig files are inpcbnew/swig/pcbnew.i
Is it correct that modification of pcbnew.i to either1) (excerpt)%include 
%include %include 
or 2)%include wxPcbStruct.i(and have some method for generating wxPcbStruct.i)?
The functions I'm wanting are declared in C++ as "protected:". Does thishave 
any implications for running them from python through SWIG?
Finally, how do you make sure that all argument types are accessible from 
python as well?
 

On Tuesday, August 22, 2017 1:02 PM, jp charras  
wrote:
 

 Le 22/08/2017 à 19:33, Greg Smith a écrit :
> Continuing to review, it appears I am wrong. PCB_EDIT_FRAME:sLV does in fact 
> synchronize the
> checkboxes, but also calls PCB_DRAW_PANEL_GAL::SLV to do the background 
> synchronization of the layers.
> 
> Thank you jp, and I apologize for not researching sufficiently your answer 
> before posting.
> 
> So at this point, how do we get PCB_EDIT_FRAME:sLV exposed in python?
> 
> void PCB_EDIT_FRAME::syncLayerVisibilities    (        )    
> 
>     protected
> 

Certainly the Python interface needs a few specific and "easy to call" methods 
to update the GUI and
the canvases, when a board is modified by a python script.

The "legacy" canvas is easy to update, but the GAL canvas has a lot of cached 
data, so it needs a
rebuild method.

I'll try to add this kind of methods. But remember: I have a (very) poor 
knowledge of Python.

Also, I'll not be able to work on Kicad next 3 days.

-- 
Jean-Pierre CHARRAS

___
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] Additional Patch for via properties dialog (2)

[Greg Smith]

To assist compilation of a set of rules, we might be able to use this link to 
my effortson loading/saving an Eagle DRU file. I've listed all the settings 
saved by the Eagledesign rule check dialog, and annotated the output file. I 
list the equivalent DRU keywordwith its associated dialog entry box (including 
the help text within the dialog 
box):https://forum.kicad.info/t/design-rules-file-load-save/7044/21

Some of the DRCs do not transfer because of the difference in the specific 
checks available.There really should be a distinction between the two major 
types of design rules:1) settings that are assigned to tools and go into the 
layout as it is placed2) settings that are checked after layoutAlthough, 
perhaps obviously, some are both.
An easy (?) example is the Global Design Rules (Type 2) vs. Local Clearance 
Settings (Type 1 and a little Type 2).
 

On Wednesday, August 23, 2017 7:55 AM, Wayne Stambaugh 
 wrote:
 

 On 8/23/2017 8:49 AM, Tomasz Wlostowski wrote:
> On 23.08.2017 14:05, Wayne Stambaugh wrote:
>> This is the missing piece of the puzzle.  We would need to create a
>> constraints manager to handle a list of constraints which could either
>> be an internally defined constraint or a custom python constraint.
>> Without a well defined interface, this would be a mess.
> 
> If I may add my 5 cents: no python please for any *critical*
> functionality of Kicad, like the DRC. I can only imagine expensive
> boards coming back from production because somebody didn't have python
> DRC plugins installed/configured.

Agreed, that is why I suggested python for custom stuff.  All standard
constraints and checks would be written in C++.

> 
> Concerning new DRC plans - a rewrite of DRC is in the V6 roadmap:
> 
> 
> 
> Design Rule Check (DRC) Improvements.
> 
> Goal:
> 
> Create additional DRC tests for improved error checking.
> 
> Task:
> 
>    Replace geometry code with unified geometry library.
>    Remove floating point code from clearance calculations to prevent
> rounding errors.
>    Add checks for component, silk screen, and mask clearances.
>    Add checks for keep out zones.
>    Remove DRC related limitations such as no arc or text on copper layers.
>    Add option for saving and loading DRC options.
> 
> 
> 
> We need specifications for both the constraint manager & the DRC checks
> to be implemented. Would anybody here volunteer to write the specs or
> design the UI?
> 
> Cheers,
> Tom
> 

___
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] Additional Patch for via properties dialog (2)

[Wayne Stambaugh]

On 8/23/2017 8:49 AM, Tomasz Wlostowski wrote:
> On 23.08.2017 14:05, Wayne Stambaugh wrote:
>> This is the missing piece of the puzzle.  We would need to create a
>> constraints manager to handle a list of constraints which could either
>> be an internally defined constraint or a custom python constraint.
>> Without a well defined interface, this would be a mess.
> 
> If I may add my 5 cents: no python please for any *critical*
> functionality of Kicad, like the DRC. I can only imagine expensive
> boards coming back from production because somebody didn't have python
> DRC plugins installed/configured.

Agreed, that is why I suggested python for custom stuff.  All standard
constraints and checks would be written in C++.

> 
> Concerning new DRC plans - a rewrite of DRC is in the V6 roadmap:
> 
> 
> 
> Design Rule Check (DRC) Improvements.
> 
> Goal:
> 
> Create additional DRC tests for improved error checking.
> 
> Task:
> 
> Replace geometry code with unified geometry library.
> Remove floating point code from clearance calculations to prevent
> rounding errors.
> Add checks for component, silk screen, and mask clearances.
> Add checks for keep out zones.
> Remove DRC related limitations such as no arc or text on copper layers.
> Add option for saving and loading DRC options.
> 
> 
> 
> We need specifications for both the constraint manager & the DRC checks
> to be implemented. Would anybody here volunteer to write the specs or
> design the UI?
> 
> Cheers,
> Tom
> 

___
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] Additional Patch for via properties dialog (2)

[Tomasz Wlostowski]

On 23.08.2017 14:05, Wayne Stambaugh wrote:
> This is the missing piece of the puzzle.  We would need to create a
> constraints manager to handle a list of constraints which could either
> be an internally defined constraint or a custom python constraint.
> Without a well defined interface, this would be a mess.

If I may add my 5 cents: no python please for any *critical*
functionality of Kicad, like the DRC. I can only imagine expensive
boards coming back from production because somebody didn't have python
DRC plugins installed/configured.

Concerning new DRC plans - a rewrite of DRC is in the V6 roadmap:



Design Rule Check (DRC) Improvements.

Goal:

Create additional DRC tests for improved error checking.

Task:

Replace geometry code with unified geometry library.
Remove floating point code from clearance calculations to prevent
rounding errors.
Add checks for component, silk screen, and mask clearances.
Add checks for keep out zones.
Remove DRC related limitations such as no arc or text on copper layers.
Add option for saving and loading DRC options.



We need specifications for both the constraint manager & the DRC checks
to be implemented. Would anybody here volunteer to write the specs or
design the UI?

Cheers,
Tom

___
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] Additional Patch for via properties dialog (2)

[Wayne Stambaugh]

On 8/23/2017 7:32 AM, Oliver Walters wrote:
> Something I have been considering for a while - instead of hard coding
> complex DRC rules into base code, what if we developed a DRC API and
> write the rules in Python?

I can see using python for complex or custom constraints but not for
general purpose constraints such as trace clearances, via stack ups, etc.

> 
> Each rule could be a separate python file (similar to how footprint
> wizards are done). Users could enable/disable each DRC and once the
> framework is in place, rather than *arguing* over DRC rules in the
> developer list, the community can create and perfect as many different
> checks as they wish. 
> 
> Each DRC should provide a pass/fail metric and also a way of providing
> formatted feedback. 
> 
> Currently there are minimal DRC checks so even if more are implemented
> in C++ I see no reason why such a framework could not be implemented
> concurrently anyway. 

This is the missing piece of the puzzle.  We would need to create a
constraints manager to handle a list of constraints which could either
be an internally defined constraint or a custom python constraint.
Without a well defined interface, this would be a mess.

> 
> Thoughts?
> 
> Oliver
> 
> On 23 Aug 2017 10:02, "Andrey Kuznetsov"  > wrote:
> 
> If you're looking for good DFM manuals, check out protoexpress,
> otherwise known as Sierra Circuits.
> They're a professional board house in the USA with simple to complex
> board design support including high speed interfaces, uvias, etc.
> 
> 
> On Tue, Aug 22, 2017 at 2:33 PM, Thomas Langås
> mailto:thomas.lang...@gmail.com>> wrote:
> 
> On Tue, Aug 22, 2017 at 9:36 PM, Wayne Stambaugh
> mailto:stambau...@gmail.com>> wrote:
> > I'm not opposed to this change.  However, there are two schools of
> > thought when it comes to board layout: strict layout constraints 
> and no
> > layout constraints.  I tend to lean towards the latter but I've been
> > doing this for 30 years so I am painfully aware of the pitfalls of 
> no
> > layout constraints and have a pretty good idea of what not to do.
> > Should we choose to loosen the layout constraints for blind/buried 
> vias,
> > then we should be prepared for a serious tongue lashing the first 
> time
> > someone violates their board vendor's manufacturing limitations and 
> ends
> > up with a bunch of useless and likely expensive boards.  Maybe at 
> some
> > point in the future we will have a complete constraint system that 
> can
> > cover all possibilities but until then we have to walk that fine 
> line
> > between power users and beginners.
> 
> 
> Is there a good reason why not to build this by rulesets, and allow
> people to define
> their own rulesets within KiCAD.  You can have a sensible
> default rule
> that covers
> the 80-90%, and allow the people who know more about this and
> what they need
> just remove the default rule and add their own advanced rules?
> 
> Of course, this would imply that without any rules at all, it's just
> willy nilly and
> everything allowed.  But isn't that the way design rules should
> be?  If you want
> to try ice skating down a mountain, it might not be smart, but
> it's your own
> choice  ;-)
> 
> 
> --
> Thomas
> 
> ___
> 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
> 
> 
> 
> 
> 
> -- 
> Remember The Past, Live The Present, Change The Future
> Those who look only to the past or the present are certain to miss
> the future [JFK]
> 
> kandre...@gmail.com 
> Live Long and Prosper,
> Andrey
> 
> ___
> 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://l

Re: [Kicad-developers] Additional Patch for via properties dialog (2)

[Greg Smith]

I have experience in python DRCs and have a background in ASIC layout software 
and Design Rule Checks as well as a healthy experience in GIS and layer 
manipulation..

I have started KiPadCheck exactly to fill in some missing (IMHO) DRC checks. It 
might be a good as a base for further development. I can help craft an API. A 
huge decision to make is whether it's worth implementing basic "full layer" 
checks. That is, generate all polygons on a layer, then use basic geometry 
calculations (union, then chop into non-overlapping convex polygons, then check 
separation, adjacency/touching, overlap, etc.

I've written a few of python routines for getting all drill holes (via and 
pad), extracting mask and paste, extracting all objects on a specified layer, 
checking items between two specific layers. And the beginnings of working with 
geometries in the functions within kipadcheck.wxPointUtil. There are quite a 
few speed ups to be made when checking large numbers of objects 
(pre-calculating normals, using squares for distance check (avoiding square 
roots).

One thing that might help using python for DRC is including numpy or one of a 
few other geometry-specific python libraries.

Another awesome addition would be to create objects on layers with annotation. 
That way, DRC errors can be indicated with shapes (the way Cadence Virtuoso 
does it) and the annotation is the error message.

Greg S.

> On Aug 23, 2017, at 6:32 AM, Oliver Walters  
> wrote:
> 
> Something I have been considering for a while - instead of hard coding 
> complex DRC rules into base code, what if we developed a DRC API and write 
> the rules in Python?
> 
> Each rule could be a separate python file (similar to how footprint wizards 
> are done). Users could enable/disable each DRC and once the framework is in 
> place, rather than *arguing* over DRC rules in the developer list, the 
> community can create and perfect as many different checks as they wish. 
> 
> Each DRC should provide a pass/fail metric and also a way of providing 
> formatted feedback. 
> 
> Currently there are minimal DRC checks so even if more are implemented in C++ 
> I see no reason why such a framework could not be implemented concurrently 
> anyway. 
> 
> Thoughts?
> 
> Oliver
> 
>> On 23 Aug 2017 10:02, "Andrey Kuznetsov"  wrote:
>> If you're looking for good DFM manuals, check out protoexpress, otherwise 
>> known as Sierra Circuits.
>> They're a professional board house in the USA with simple to complex board 
>> design support including high speed interfaces, uvias, etc.
>> 
>> 
>>> On Tue, Aug 22, 2017 at 2:33 PM, Thomas Langås  
>>> wrote:
>>> On Tue, Aug 22, 2017 at 9:36 PM, Wayne Stambaugh  
>>> wrote:
>>> > I'm not opposed to this change.  However, there are two schools of
>>> > thought when it comes to board layout: strict layout constraints and no
>>> > layout constraints.  I tend to lean towards the latter but I've been
>>> > doing this for 30 years so I am painfully aware of the pitfalls of no
>>> > layout constraints and have a pretty good idea of what not to do.
>>> > Should we choose to loosen the layout constraints for blind/buried vias,
>>> > then we should be prepared for a serious tongue lashing the first time
>>> > someone violates their board vendor's manufacturing limitations and ends
>>> > up with a bunch of useless and likely expensive boards.  Maybe at some
>>> > point in the future we will have a complete constraint system that can
>>> > cover all possibilities but until then we have to walk that fine line
>>> > between power users and beginners.
>>> 
>>> 
>>> Is there a good reason why not to build this by rulesets, and allow
>>> people to define
>>> their own rulesets within KiCAD.  You can have a sensible default rule
>>> that covers
>>> the 80-90%, and allow the people who know more about this and what they need
>>> just remove the default rule and add their own advanced rules?
>>> 
>>> Of course, this would imply that without any rules at all, it's just
>>> willy nilly and
>>> everything allowed.  But isn't that the way design rules should be?  If you 
>>> want
>>> to try ice skating down a mountain, it might not be smart, but it's your own
>>> choice  ;-)
>>> 
>>> 
>>> --
>>> Thomas
>>> 
>>> ___
>>> 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
>> 
>> 
>> 
>> -- 
>> Remember The Past, Live The Present, Change The Future
>> Those who look only to the past or the present are certain to miss the 
>> future [JFK]
>> 
>> kandre...@gmail.com
>> Live Long and Prosper,
>> Andrey
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https:/

Re: [Kicad-developers] Additional Patch for via properties dialog (2)

[Wayne Stambaugh]

On 8/22/2017 5:33 PM, Thomas Langås wrote:
> On Tue, Aug 22, 2017 at 9:36 PM, Wayne Stambaugh  wrote:
>> I'm not opposed to this change.  However, there are two schools of
>> thought when it comes to board layout: strict layout constraints and no
>> layout constraints.  I tend to lean towards the latter but I've been
>> doing this for 30 years so I am painfully aware of the pitfalls of no
>> layout constraints and have a pretty good idea of what not to do.
>> Should we choose to loosen the layout constraints for blind/buried vias,
>> then we should be prepared for a serious tongue lashing the first time
>> someone violates their board vendor's manufacturing limitations and ends
>> up with a bunch of useless and likely expensive boards.  Maybe at some
>> point in the future we will have a complete constraint system that can
>> cover all possibilities but until then we have to walk that fine line
>> between power users and beginners.
> 
> 
> Is there a good reason why not to build this by rulesets, and allow
> people to define
> their own rulesets within KiCAD.  You can have a sensible default rule
> that covers
> the 80-90%, and allow the people who know more about this and what they need
> just remove the default rule and add their own advanced rules?

I believe this would require some major refactoring of the Pcbnew
internals to handle constraints.  The current design is rather ad-hoc
and would be difficult to extend.

> 
> Of course, this would imply that without any rules at all, it's just
> willy nilly and
> everything allowed.  But isn't that the way design rules should be?  If you 
> want
> to try ice skating down a mountain, it might not be smart, but it's your own
> choice  ;-)
> 
> 

___
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] Additional Patch for via properties dialog (2)

[Oliver Walters]

Something I have been considering for a while - instead of hard coding
complex DRC rules into base code, what if we developed a DRC API and write
the rules in Python?

Each rule could be a separate python file (similar to how footprint wizards
are done). Users could enable/disable each DRC and once the framework is in
place, rather than *arguing* over DRC rules in the developer list, the
community can create and perfect as many different checks as they wish.

Each DRC should provide a pass/fail metric and also a way of providing
formatted feedback.

Currently there are minimal DRC checks so even if more are implemented in
C++ I see no reason why such a framework could not be implemented
concurrently anyway.

Thoughts?

Oliver

On 23 Aug 2017 10:02, "Andrey Kuznetsov"  wrote:

> If you're looking for good DFM manuals, check out protoexpress, otherwise
> known as Sierra Circuits.
> They're a professional board house in the USA with simple to complex board
> design support including high speed interfaces, uvias, etc.
>
>
> On Tue, Aug 22, 2017 at 2:33 PM, Thomas Langås 
> wrote:
>
>> On Tue, Aug 22, 2017 at 9:36 PM, Wayne Stambaugh 
>> wrote:
>> > I'm not opposed to this change.  However, there are two schools of
>> > thought when it comes to board layout: strict layout constraints and no
>> > layout constraints.  I tend to lean towards the latter but I've been
>> > doing this for 30 years so I am painfully aware of the pitfalls of no
>> > layout constraints and have a pretty good idea of what not to do.
>> > Should we choose to loosen the layout constraints for blind/buried vias,
>> > then we should be prepared for a serious tongue lashing the first time
>> > someone violates their board vendor's manufacturing limitations and ends
>> > up with a bunch of useless and likely expensive boards.  Maybe at some
>> > point in the future we will have a complete constraint system that can
>> > cover all possibilities but until then we have to walk that fine line
>> > between power users and beginners.
>>
>>
>> Is there a good reason why not to build this by rulesets, and allow
>> people to define
>> their own rulesets within KiCAD.  You can have a sensible default rule
>> that covers
>> the 80-90%, and allow the people who know more about this and what they
>> need
>> just remove the default rule and add their own advanced rules?
>>
>> Of course, this would imply that without any rules at all, it's just
>> willy nilly and
>> everything allowed.  But isn't that the way design rules should be?  If
>> you want
>> to try ice skating down a mountain, it might not be smart, but it's your
>> own
>> choice  ;-)
>>
>>
>> --
>> Thomas
>>
>> ___
>> 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
>>
>
>
>
> --
> Remember The Past, Live The Present, Change The Future
> Those who look only to the past or the present are certain to miss the
> future [JFK]
>
> kandre...@gmail.com
> Live Long and Prosper,
> Andrey
>
> ___
> 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] Additional Patch for via properties dialog (2)

[Andrey Kuznetsov]

If you're looking for good DFM manuals, check out protoexpress, otherwise
known as Sierra Circuits.
They're a professional board house in the USA with simple to complex board
design support including high speed interfaces, uvias, etc.


On Tue, Aug 22, 2017 at 2:33 PM, Thomas Langås 
wrote:

> On Tue, Aug 22, 2017 at 9:36 PM, Wayne Stambaugh 
> wrote:
> > I'm not opposed to this change.  However, there are two schools of
> > thought when it comes to board layout: strict layout constraints and no
> > layout constraints.  I tend to lean towards the latter but I've been
> > doing this for 30 years so I am painfully aware of the pitfalls of no
> > layout constraints and have a pretty good idea of what not to do.
> > Should we choose to loosen the layout constraints for blind/buried vias,
> > then we should be prepared for a serious tongue lashing the first time
> > someone violates their board vendor's manufacturing limitations and ends
> > up with a bunch of useless and likely expensive boards.  Maybe at some
> > point in the future we will have a complete constraint system that can
> > cover all possibilities but until then we have to walk that fine line
> > between power users and beginners.
>
>
> Is there a good reason why not to build this by rulesets, and allow
> people to define
> their own rulesets within KiCAD.  You can have a sensible default rule
> that covers
> the 80-90%, and allow the people who know more about this and what they
> need
> just remove the default rule and add their own advanced rules?
>
> Of course, this would imply that without any rules at all, it's just
> willy nilly and
> everything allowed.  But isn't that the way design rules should be?  If
> you want
> to try ice skating down a mountain, it might not be smart, but it's your
> own
> choice  ;-)
>
>
> --
> Thomas
>
> ___
> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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