Feature request - multifile custom DRC

[ravn]

Hey,

Custom DRC are awesome. We are using it extensively in our designs. However, we would like to create some standardized design rule libraries that corresponds to a particular vendor and stack-up and place them under revision control. Then one would like to be able to make board-specific design rules as well and it makes sense to have these in a board project specific file (like the .drc-file now used). So, for this reason, it would be great with an (import "my_library.drc") feature in the DRC language. That way, I can have my board specific design rules like now, but then also generic library DRCs in an included DRC file.

Thanks for your great work!

Robert

[paulvdh]

This is already supported. KiCad has: Import Settings from Another Board, and then you can select what you want to import. It’s quite easy to make a few empty project which have some specific rules set up and nothing else.

[mf_ibfeew]

If I understand you correctly you are talking about the “custom design rules” defined in Board setup–>Design rules–>Custom rules? And you want to include different existing *.kicad_dru files?
Like including multiple header files into the main.c file during programming?

That idea sounds interesting for bigger/commercial use cases. You should open a gitlab issue (feature request) and explain this idea. (note: the custom_rules file has filetype*.kicad_dru, not *.drc)

[Tojan]

This is already implemented with the board templates and we use it regularly: Just create a board template with all the parameters, custom rules etc. of a particular board manufacturer and us this as a base every time you start with a new design.

[mf_ibfeew]

I don’t think this meets the original question/proposal. Working with the templates (or importing the settings as paul mentioned) still results in one drc rules file.

As I understand the original proposal is some modular system, where the user is able to #include / #import subfiles into the main custom drc rules file.
example with 3 custom-drc subfiles for:

• manufacturer generic constraints
• isolation clearances
• diff pair

And the main custom drc file would look something like:
#include "manufacturer_constraints.kicad_dru
#include "isolation_clearances.kicad_dru
#include "diff_pair_constraints.kicad_dru

With this modularity it’s easier to share parts of the custom rules between projects.

Maybe @ravn has to chime in and explain if my interpretation of the opening post is even correct.

[ravn]

@mf_ibfeew , your are absolutely right. This was my thinking, and I think it has clear benefits compared to the import and template approach proposed by others, in the same way as is it used in programming languages as you write. I will open a feature request, but it might be worth thinking about how to make this generic, if there are features that makes sense to include in such a request.

[paulvdh]

A big issue, which has been opened since 2019 is a request for a CAM Manager:

CAM Manager / output automation / plot and export presets (#2346) · Issues ·...

Intention of the CAM Manager is to create a user interface to have a bunch of settings grouped together to generate different sets out outputs. Your Idea is the counter part of this, by formalizing how settings can be import.

On my opinion some thought should be given to create a similar GUI that works for both these cases. I don’t know whether code-reuse is a thing between these (probably not), but a similar look and feel for the users is certainly a bonus.

[BlackCoffee]

I was curious so I spent some time reviewing various Kicad files, settings and pragmatism of implementation and usage. I tweaked Preferences, Designs and Rules and compared the files and my observations are as follows:

Considering:
• The various Design-Attributes and DRC (not, ERC), some from the PCB file, some from Kicad_pro file
• The changes in Kicad versions that may affect what works today but may not work in tomorrow’s version of Kicad
• Each Design could have significant differences (such as Teardrop, diff-Pair…etc)

Implementing a GUI Panel with selection options for various DRC Rules would be easy. It’s simply a Search and Replace of the “rules” section in the Kicad_pro file and other relevant items in the PCB file.

The GUI panel could offer Override’s to some DRC settings and could include Input Fields for Text such as Manufacturer/etc.

That can also apply to the Kicad_pro file that contains the Diff-pair info and many/any other attributes.
But, which one’s?
Who decides?
How many Attributes and DRC Rules and where to draw the line?

Should it be:
• a Standard feature?
• a Stand-Alone App?
• a Plugin?
• code for executing in Kicad’s Scripting Console?
• what about schematic’s ERC?

If I dialed it down to, say the Two-Dozen DRC rules/etc that seem to happen as a ‘default’ in the above mentioned files, I (and most any average coder) could write fully tested code in less than a few-hours.

Below shows about one-hour’s effort using wxFormBuilder, including coffee breaks…

I may spend some time to implement the Action-Code - maybe, maybe-not. I suppose that depends on several things, including response(s) to this post… At least, it’s food for thought and perhaps this GUI will spawn User ideas…

I can imagine Reading and Parsing the PCB and Kicad_pro file, extracting needed content and writing a File of DRC settings that can be read back as, for example, “DRC Set #2” or a User can edit a boiler-plate file… many options…

[paulvdh]

How far would this be useful to put in a database or git repository?
For example, I want to check quickly whether my current design is compatible with a certain PCB manufacturer. Then just load the file with settings from that PCB manufacturer and run DRC.

Setting up such a system would be a small thing once loading of custom sets of rules is implemented. It would be nice if naming conventions for such files would be a part of the KLC Some combination of PCB manufacturer, their process name, and a “relaxation factor”, so the rules are not set to the minimum a PCB specifies. Maybe adding 30% tolerance, and then “rounding upwards” “ceil()” would be a sensible value.

In these modern times It’s a bit weird when you think of it that you have to go to a website of a PCB manufacturer, interpret a long web page with settings and then figure out how to translate that to something that fits in KiCad.

[BlackCoffee]

I agree with paulvdh comments and respond as follows:

Settings/DRC
• Let the code drive what things are called (the syntax) using knowledge from reviewing various PCB-makers (and, perhaps some dialog with them). I suspect there will be suffieicent consistency that minimizes the work/problems. There should be compatibility with Kicad’s syntax as well as ‘programming syntax’ (things like those pesky Forward and Back slashes, underscore…etc)

• Most likely PCB-maker’s DRC won’t change often so, even hard-coding could work. Otherwise, loading from downloadable files or Online-Database…etc - Not hard ‘if’ the Database/Files are published. Otherwise, it’s programming Work and, though not difficult, there’s little incentive to do it. Code could have options per user’s selection.

Syntax/Naming of what stuff is called
• Comparing one, or more, DB/Hard-Coded/other files would be easy once the PCB-maker’s file structure/syntax is known - the harder part is deciding what to do with differences (could simply Flag or Ignore them and let User decide…?)

Deciding what to do about DRC could include paulvd’s 30% tolerance, Rounding…etc and could easily be user-selectable

Access to PCB-Makers related files/database & Implementation
• Perhaps not too difficult to get data/files from them and, at least, talk with them

---

I’ll think about this and perhaps implement/prototype some common-sense, useful ideas and suggestions that users post. I like programming and, though this ‘idea’ (this ‘Post’) was not mine and I’m not in a hurry, I suspect it to be a ‘Fun’ alternative to yard-work but/and, ‘things’ happen, including good motorcycle riding weather

[BlackCoffee]

Status: 7/15/24

Looking good so far (video below) and now need a variety of realistic DRC-Rule snippets from interested Users. Not wild stuff but, preferably from PCB’s that were made. And, hopefully, contain the PCB-Maker’s DRC stuff. Please indicate who the PCB-Maker was.

The DRC can be either typed or, simplier to open the desired kicad_pro file in Text-Editor and copy the “Rules” section and paste it into a new Text File (screenshot example below - may/may-not reflect your actual DRC)

I need this DRC info before wasting time on Parsing bad, non-useful data…
Thanks

Snippet

Video