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" <[email protected]> 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 <[email protected]> > wrote: > >> On Tue, Aug 22, 2017 at 9:36 PM, Wayne Stambaugh <[email protected]> >> 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 : [email protected] >> 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] > > [email protected] > Live Long and Prosper, > Andrey > > _______________________________________________ > 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
