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.
Hi Daniel,
Thank you for your interest in contributing to KiCad, but here I second
Jon. DRC engine performance is critical in particular for the P&S
routing and component placement. The rule language has been designed
with performance in mind and that's why it has certain limitations.
Trust me, we had considered using Python expressions for DRC in the
past. Running a worst-case O(n^2) clearance queries during shove routing
is already a huge bottleneck.
Also, DRC is a core feature of KiCad. Just like the router or footprint
editor. It must be IMHO an integral part of KiCad, not relying on a
plugin. Imagine the case where someone sends a design where design rules
are provided by plugins to a fab which doesn't have the same set (and
same versions of plugins).
If you'd like to contribute to the DRC engine, we are open for
discussions & patches in C++, as Jon mentioned already it's pretty
straightforward to extend/add new checks, and the examples you provided
don't look particularly difficult to implement.
Regards,
Tom
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/74932581-5164-4c49-b4e1-8807eba3667d%40cern.ch.
