> implementing all (or most) rules from the ECSS-Q-ST-70-12C specification would result in quite a specialised rule set not really that applicable for non-space related projects.
I'm not sure how practical this line of thought would be, but my first thought is: can we implement enough rule primitives in the design rule language to implement all of these space-related rules without implementing the specific checks themselves as individual primitives? In other words, can the ECSS rules be composed out of smaller or less-specific building-blocks that might be more generally useful? > Maybe this would be a different discussion altogether, but what is your opinion of the UI I have drafted? > When more rules are added, especially more complex ones with more than one parameter, the current DRC page could get overloaded. The "constraints" page is only aimed at the most basic rules. More complex rules are currently only specified through the custom rules language, and have no GUI. We could decide to add more GUI for advanced rules, however it would not go on the basic constraints page. My recommendation would be to focus on implementing the checks you need in the custom rules language first, and make the GUI question a separate question. > Maybe an approach like this could benefit the current custom DRC rule section, also to integrate it more into the existing rules? I am not sure what you mean by integrate here; the custom rules and basic constraints are both already integrated together into the DRC system. We have discussed before the concept of auto-generating UI for editing custom rules, but it hasn't been prioritized at the moment. Such a system should probably be a layer on top of the custom rules language, essentially parsing it and serving as a "visual editor" for it. > It is relatively easy to accidentally bend the rules so they don't actually do what was intended. A generated UI with parameters could make it easier for them to work with it. I'm not sure I think that a GUI like you propose is an answer to rules not doing what was intended. I think there are other non-GUI features that would help here more, such as an interactive preview of condition predicates. -Jon On Sat, Nov 4, 2023 at 1:49 PM Daniel Treffenstädt < [email protected]> wrote: > Hi Jon, > > Thank you for your feedback. > > > 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++. > > That sounds like something I could get behind. I have started implementing > some of the rules in Python, re-implementing them in C++ would be pretty > straightforward once the implementation has matured. > However implementing all (or most) rules from the ECSS-Q-ST-70-12C > specification would result in quite a specialised rule set not really that > applicable for non-space related projects. > Maybe some of the rules would need to be hidden behind something akin to a > checkbox >enable ECSS compliant rules< (other industries probably have > similar problems I assume). > > > Maybe this would be a different discussion altogether, but what is your > opinion of the UI I have drafted? > > When more rules are added, especially more complex ones with more than one > parameter, the current DRC page could get overloaded. > > The way I currently do it in this small project is each rule defines its > own icon + description + parameter set, the UI is generated from that. > > Maybe an approach like this could benefit the current custom DRC rule > section, also to integrate it more into the existing rules? > I often find myself writing a custom rule set then reusing it between > boards with slight modifications and handing them over to colleagues > working with KiCad. > It is relatively easy to accidentally bend the rules so they don't > actually do what was intended. A generated UI with parameters could make it > easier for them to work with it. > > Best Regards, > Daniel > [email protected] schrieb am Samstag, 4. November 2023 um 17:51:14 UTC+1: > >> 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]> >> 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 >>> >>> -- 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 >>> >>> 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: >>> >>> [image: no_parameter_rule.png] >>> >>> [image: three_parameter_rule.png] >>> >>> [image: 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]. >>> 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]. To view this discussion on the web visit https://groups.google.com/a/kicad.org/d/msgid/devlist/CA%2BqGbCA2k5sCVqjMNyOof1BMxuEAEme2rEDPhFu7Gkjqui2scQ%40mail.gmail.com.
