kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #30394
Re: Additional Patch for via properties dialog (2)
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" <kandrey89@xxxxxxxxx
> <mailto:kandrey89@xxxxxxxxx>> 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
> <thomas.langaas@xxxxxxxxx <mailto:thomas.langaas@xxxxxxxxx>> wrote:
>
> On Tue, Aug 22, 2017 at 9:36 PM, Wayne Stambaugh
> <stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>> 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
> <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> Unsubscribe : https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>
> More help : https://help.launchpad.net/ListHelp
> <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]
>
> kandrey89@xxxxxxxxx <mailto:kandrey89@xxxxxxxxx>
> Live Long and Prosper,
> Andrey
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> Unsubscribe : https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>
> More help : https://help.launchpad.net/ListHelp
> <https://help.launchpad.net/ListHelp>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>
Follow ups
References
-
Additional Patch for via properties dialog (2)
From: Bastian Neumannn, 2017-08-18
-
Re: Additional Patch for via properties dialog (2)
From: jp charras, 2017-08-19
-
Re: Additional Patch for via properties dialog (2)
From: jp charras, 2017-08-20
-
Re: Additional Patch for via properties dialog (2)
From: hauptmech, 2017-08-22
-
Re: Additional Patch for via properties dialog (2)
From: jp charras, 2017-08-22
-
Re: Additional Patch for via properties dialog (2)
From: hauptmech, 2017-08-22
-
Re: Additional Patch for via properties dialog (2)
From: Simon Küppers, 2017-08-22
-
Re: Additional Patch for via properties dialog (2)
From: jp charras, 2017-08-22
-
Re: Additional Patch for via properties dialog (2)
From: Bastian Neumannn, 2017-08-22
-
Re: Additional Patch for via properties dialog (2)
From: Wayne Stambaugh, 2017-08-22
-
Re: Additional Patch for via properties dialog (2)
From: Thomas Langås, 2017-08-22
-
Re: Additional Patch for via properties dialog (2)
From: Andrey Kuznetsov, 2017-08-23
-
Re: Additional Patch for via properties dialog (2)
From: Oliver Walters, 2017-08-23