Hello, Daniel, Jon, Thomasz, maybe a bit OT, but is that an idea regarding the performance critical DRC:
Would it be possible or an approach to implement a DRC "descriptive language" to define something like: (condition “A.Type == ‘pad’ && A.parent.GetField(‘example’) == ‘value’”) and compile that into optimized machine language to be run by the DRC? The rules are set only a few times within the design time of a pcb, whereas the DRC is needed permanently during the layout process for a full online check. IMO LTSpice, now QSPICE, is following that approach to get the max performance out of it's ciruit simulation, too. Just my five cents. Regards, Clemens On 04/11/2023 17.50, Jon Evans wrote:
Hi Daniel, > is this something worth putting more time into and work towards making this a part of KiCad itself rather than a plugin? It would be better in my opinion to use this only as a prototyping tool to identify new DRC checks that should be added to KiCad in C++. DRC checkers are performance-critical, especially on larger boards, and involving Python in the critical path is not likely to give the kind of performance we expect. The C++ design rule system is fairly easy to extend and also has a lot of performance optimizations that would be difficult to leverage across the boundaries necessary between the KiCad code and any plugin. Best, -Jon On Sat, Nov 4, 2023 at 12:29 PM Daniel Treffenstädt <[email protected] <mailto:[email protected]>> wrote: Hi there, So I have been thinking a lot about how to properly integrate more complex DRC rules into KiCad, I have some use cases that the current custom rules cannot express properly. Some examples can be seen here: https://forum.kicad.info/t/custom-drc-rules-more-granular-control-for-ecss-specifications/41686 <https://forum.kicad.info/t/custom-drc-rules-more-granular-control-for-ecss-specifications/41686> -- For context -- As an example, these three requirements need more complex code than is possible with the custom DRC rules: 1. Fan out from (PTH/SMD) pad to vi: This is essentially the length of open track between a pad and the nearest via. The required length is dependent on pad type and track width. 2. Maximum difference in connecting track width for two-pad components. 3. Asymmetric track attachment points for two-pad components. Basically this means that tracks connected to two-pad components should point in the same direction, ideally only attach to the head of the component. Requirements two and three have to do with the reflow process. If components are improperly attached, they can get misaligned during soldering, in the worst case they can tombstone. Requirement one is mostly important for classic space hardware which usually comes without solder mask. If a via is too close to a pad, it can act as a sink for solder paste and reduce the amount available for the actual pad. -- For context -- Recently I have had some time to look at the issue a bit more in depth and decided to write up a plugin that offers an interface to write complex custom DRC rules like the ones stated above. The code can be found here: https://gitlab.com/d.treffenstaedt/extra_drc_plugin <https://gitlab.com/d.treffenstaedt/extra_drc_plugin> Keep in mind that this is little more than a first draft and the code is mostly exploratory. *Now to the actual point I am trying to make here:* I think a system like this could improve the user experience of KiCad and make the DRC system a whole lot more flexible than it already is. From your perspective - is this something worth putting more time into and work towards making this a part of KiCad itself rather than a plugin? Have similar ideas been proposed before? Thank you for your time, I hope there is some interest in this. Best Regards, Daniel Some visuals: no_parameter_rule.png three_parameter_rule.png one_parameter_rule.png -- You received this message because you are subscribed to the Google Groups "KiCad Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected] <mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/a/kicad.org/d/msgid/devlist/0f3e5777-40ce-4681-8227-439e78103b4en%40kicad.org <https://groups.google.com/a/kicad.org/d/msgid/devlist/0f3e5777-40ce-4681-8227-439e78103b4en%40kicad.org?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "KiCad Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected] <mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/a/kicad.org/d/msgid/devlist/CA%2BqGbCCnp470E%2Bs%3DGvua4A32gP79p-1cLzHL0uAYSxXAC8XkkA%40mail.gmail.com <https://groups.google.com/a/kicad.org/d/msgid/devlist/CA%2BqGbCCnp470E%2Bs%3DGvua4A32gP79p-1cLzHL0uAYSxXAC8XkkA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
-- You received this message because you are subscribed to the Google Groups "KiCad Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/kicad.org/d/msgid/devlist/41894f6d-17f8-4e27-a951-231359f9d6b8%40gmx.net.
