How do I use the new creepage custom rules? (v9.0.0)

I’ve been attempting to set up the creepage custom design rule. The only current information I can find on it is in the v9 announcement, and then just a couple of lines in the documentation which are less helpful than the code snippet from the announcement. Here’s what I’ve got so far, which is basically just the example duplicated and using what I think should be the correct values swapped in:

(version 1)
(rule HV_HV
   (constraint creepage (min 2.50mm))
   (condition "A.hasNetclass('HVHPT') && B.hasNetclass('HVLPT')")
)
(rule HV_HV
   (constraint creepage (min 2.50mm))
   (condition "A.hasNetclass('HVH1') && B.hasNetclass('HVLPT')")
)
(rule HV_HV
   (constraint creepage (min 220.50mm))
   (condition "A.hasNetclass('HVH1') && B.hasNetclass('HVHPT')")
)
(rule HV_HV
   (constraint creepage (min 2.50mm))
   (condition "A.hasNetclass('HVH2') && B.hasNetclass('HVLPT')")
)
(rule HV_HV
   (constraint creepage (min 2.50mm))
   (condition "A.hasNetclass('HVH2') && B.hasNetclass('HVHPT')")
)

I’ll explain what I’m doing, and I hope someone can tell me where I’m going wrong.

(rule HV_HV // no change needed here I guess
   (constraint creepage (min 2.50mm)) // minimum creepage distance desired
   (condition "A.hasNetclass('HVH2') && B.hasNetclass('HVHPT')") // "A" is the first net I want to compare against, "B" is the second. 
)

I am assuming that I can only compare 2 nets, since there are only two nets included in the example, and though I would also imagine that you could have the HV net compared against every other net, I don’t see any evidence for that. What I do see is that even if I crank the creepage distance up to 220mm, I get no hits on my DRC. The clearance distance on my pins throws errors, but I didn’t get anything on the creepage rules. I read the feature requests which date back 5 years or more, and followed the discussion to the current feature update, but other than finding out that I probably had to move my slots to the edge.cuts layer, I’m still not sure what’s going wrong. I suspect my slots might not be up to snuff. I’m using thick line segments to indicate the slots. I set the thickness to 2mm to accommodate a 2mm endmill, and in the past PCBWay has used those to make the slots I need. I didn’t put them on edge.cuts in the past because it interferes with the 3D view of the board shape.

If I need different edge.cut shapes, which shapes do I need to use? I don’t mind a little work remaking things in a way that I can DRC creepage, but I just don’t really know how to get this to work yet. If someone can help me figure it out faster than I can do it alone, I’d appreciate it. Either way I’m willing to update the documentation with an excruciatingly detailed explanation.

Thanks to any help in advance.

I think I’ve gotten a little bit closer. I’ve figured out how to get slots on the edge.cuts layer instead of having to put them on a user layer and specify this layer as being for slots when I send the gerbers to my PCB manufacturer. Until now, I’ve been using solid line segments with a thickness that makes them slot like, and I have been using multiple overlapping segments to get shapes that I want. I find this to be a very easy way to ensure that the slots have a certain minimum thickness or wall to wall gap, because a 2mm thick line segment cannot be thinner than 2mm even if there is a corner or some other jutting piece in my shape. Furthermore, I can make an arching slot with just one arc line segment instead of the 4 arcs it takes to do it the “proper” way.

The “proper” way to do this is to use thin line segments to make an outline of the slot. I must admit I do not prefer this method as it takes a lot more work to achieve similar results. Instead of a single arc with a thickness of 2mm to get a 2mm arcing slot, I have to use 4 arcs. 2 for the rounded ends of the slot, and 2 for the major and minor radii of the slot. The problem with this technique is that I have to make sure that they stay 2mm apart from each other by making the radii of the end caps 1mm and place them square so that my other arcs will line up in the right locations. Then I can group them and hit shift+m to rotate the entire group of arcs to the angle I need. With a segment, I can just start the arc where I want and finish it where I want. I don’t have to worry about squaring up end caps. Finally, as I mentioned before, having parts that jut in or out of the main shape can result in walls that are too close together for a manufacturer to produce. So you have to be even more careful about not making mistakes by having walls too close together and leaving plenty of space; especially if you’re working with bezier curves. I’ve made some curves that look nice until you measure the slot width and realize an endmill would never be able to fit between those lines.

I find the proper method to be rather complex and requires quite a bit more effort than accepting the standalone segments as slots, but perhaps it is easier to program that way. If not, perhaps allowing for both methods would be advantageous.

I’m still not getting any creepage calculations that I can tell, though I do see the DRC reporting that it is calculating creepage, but in truth, my settings do not throw up errors as I was expecting they would. So my assumptions are wrong, my methods are wrong, or both are wrong.

I’ll keep at it for now and report back any progress.

Small addition: I found that if I use my line segment technique, and leave them on a nice bright user layer, I can then trace around them with the bezier tool, and as long as I don’t draw over the thick line segments, I can ensure the slots are big enough for the manufacturer. Also, modifying footprint minimum clearance values and setting them to the same value as your board edge clearance values can give you a temporary visual guide to stay away from as well. Now I have creepage slots around pins that obey clearance values, preserve slot endmill clearance, and only take twice as much or more work than just using line segments as slots. X’D

I’m going to make a list of custom design rules that I think might work for whatever reason, but don’t for whatever reason.

(rule HV_HV
   (constraint creepage (min 220mm)) // removed the decimal to see if that was causing a problem since all examples I've found do not use decimals ... seemingly made no difference
   (condition "A.NetClass != B.NetClass && A.hasNetclass('HV*')") // attempt to compare my HV nets against all other nets ... doesn't work
)

I found the Merge Request which has a bit more information, and there is a unit test file, which at first made me excited as I’d be able to copy their custom design rules since these are saved in the board setup.

Unfortunately, those rules are not present in the unit test pcb file. Why? No idea. How was the test run if it doesn’t use custom design rules? … Update: Just figured out that the design rules are actually saved to a text file named with the extension .kicad_dru (I guess dru stands for Design Rules User?) That file was not included with the board file for the unit test. I wonder if that file will eventually be embedded. Really since its all ascii text files anyway, I’m not sure why it’s not just included in the pcb file already. At least one mystery solved.

Supposedly the shortest creepage path gets saved to User.Eco1 and all possible candidates get saved to User.Eco2 (at least in this unit test file), but I still cannot get the test to run. Maybe my past efforts have worked and I didn’t check the Eco layers. I’ll go back and try everything again. Having to reload the board to check the layers (at least as described when the functionality was being tested and debugged) is a little inconvenient, but not a deal breaker.

Nope. Went back to the original example rule from the v9 release announcement using 2 specific net names, and nothing was output to the Eco layers, and nothing was flagged as an error in the DRC. Maybe I have to turn it on somewhere I’m unfamiliar with. In the DRC Violation Severity, creepage is set as an error.

I’ll keep looking.

… This comment from the MR by Fabien confuses me because I do not know enough about how KiCAD is built to know if this is a user setting somewhere, or simply a flag that gets flipped in the code which makes sure the functionality gets compiled and made available for use.

Fabien Corona @Drinausaur · 5 months ago

Author Maintainer

I added the EnableCreepageDRC flag for advanced config, removed commented lines, and debugging with the last set of commit I pushed

If I can find this advanced config flag (assuming its a user setting) I might be in business.

Creepage checks were behind an advanced config flag during development, but should now enabled by default.

Can you post the project you’re seeing issues with?

Ok, sure thing. It’s a design for some propriety industrial testing equipment, so I stripped out everything but the HV section. Nothing secret nor terribly embarrassing about what’s left, and the creepage tests still don’t work, so I guess it’s fine to share. I’ll include the dru file as well. I removed the few relay signal tracks that were giving DRC errors for unconnected traces, so the last time I checked, there were no DRC errors at all with the board.
creepage-test.kicad_dru (129 Bytes)
creepage-test.kicad_pcb (161.7 KB)

I’m heading home for the day. I’ll be back in 15 hours or so.

Well, I tried making a new test design. It’s a tact switch connected to the coil of a relay. I added the creepage rule from the v9 announcement and use the only two nets I have on the board with a 20.5mm minimum creepage, but nothing happens. The traces for the two nets are less than 1mm apart. Either this creepage rule is not turned on, not included in the binary for my platform (Windows), or just doesn’t work as described. Unless someone can offer some help, I’m giving up and filing a bug report. I really don’t know what to do about a function with no documentation and no effect on anything no matter how you try to get it to work. Here’s the new test file. Feel free to try it out and let me know if it works for you.

testcreepagedrc.zip (11.9 KB)

Alternatively, if ANYONE has gotten this creepage rule to work, please let me know. My guess is that no one has tried it yet. I suspect most users avoid the custom rules like the plague. I know I did until I needed to use this feature.

UPDATE: As I was writing my bug report, I found another bug report that sounds similar to my situation, so I thought I should try his file and see what happens. Well, it works as well as he describes. It catches creepage errors on the first try, then if you rerun the test, it returns no creepage errors. If you close the pcb window and open it again, it will report the errors the first time, but not again until you close and reopen the window.

So, I sort of got it to work thanks to this bug report. It looks a little broken, but it’s progress! I’m going to try his rule (more simple than I would have expected could work) and see if my board does anything.

(rule creepage
	(constraint creepage (min 5mm)))

From: Creepage DRC violations disappear on repeated runs (#20048) · Issues · KiCad / KiCad Source Code / kicad · GitLab

Oh, and here’s a rule that one person has claimed works:

(rule BasicInsulationCreepage (constraint creepage (min 20mm)) (condition "A.hasNetclass('BI') && !B.hasNetclass('BI')") )

From: DRC Check gets very slow / stuck with creepage check enabled (#19488) · Issues · KiCad / KiCad Source Code / kicad · GitLab

Well, using the short rule from the bug report:

(rule creepage
	(constraint creepage (min 5mm)))

and my stripped down board above

And the DRC goes unresponsive. Checking task manager shows KiCad PCB Editor 9.0.0 is non-responsive and CPU usage fluctuates between 18 and 44% use, and memory usage fills up completely, resets, then starts again filling completely only to dump back to zero and start again. I think it was using around 6 gigs of memory before it dumps it all out and starts again. When dumping, CPU usage goes to 100%. This laptop only has 8gigs of memory I believe.

Memory leak maybe? Whatever it is, it’s broken. I’m going to work on something else until this is fixed. If you want to use the creepage rule check, please consider giving this bug report a thumbs up in hopes of expediting the fix.

https://gitlab.com/kicad/code/kicad/-/issues/20048

I had another idea to test while working on other things, and got some interesting results:

Using the simple rule:

(rule creepage
	(constraint creepage (min 5mm)))

And my test board with tact switch and relay:

And I get 10 creepage errors. Run the DRC again, and I get 3. Run it again and I get 1. Run it again and I get none.

Definitely broken, but for simple boards, it sorta works as long as you only run it once, but the thing about it showing the various distances on Eco layers just doesn’t happen. I think I must have misunderstood what was being said. When the errors in the DRC show up, you can click on the error and it will show the line between the two nets that are too close. Maybe it’s showing up on some hidden layer.

The problem in your file is that you add creepage constraint on netclass, but you do not define netclasses. So the creepage checks is defined on inexistant netclasses, and therefore nothing runs.

EDIT: in your last post, it detects something because you are adding a 5mm creepage constraint for every single net

This is how I usually do

  1. Define netclass

  2. Add nets to netclass

  3. Update PCB

  4. Run the check with this rule:
    (version 1)
    (rule HV_HV
    (constraint creepage (min 20.50mm))
    (condition “A.hasNetclass(‘L1’) && B.hasNetclass(‘L2’)”)
    )

The error is detected

Ah! Thank you! I was confusing nets with netclasses. This is not the first time I’ve used those terms interchangeably, I’m sure. I’ll give it another go and post my results in a little bit.

I’m certain I would not have realized that mistake without it being pointed out to me, so thank you very much.

Things are indeed much better! It’s working!

I have run into a slightly unexpected result, but this could be due to my ignorance. If you don’t mind, could you tell me if this is the result you would expect?

I actually only need 2.5mm of clearance between HV and LV, and that value was returning no errors, which is great if correct, but I wanted to see the actual values, so I overstated my minimum to 20.5mm, and the results are not bad, but it’s only checking the distance between pins in this instance, and we can see that the HVH2 trace goes right by the pin that is being flagged as an error. The trace is actually 2.5mm away, but the 20mm test flagged only the pins and not the trace to the pin.

My understanding of tracking and creepage is that an external trace would count as an external conductor as well, not only the pins. But then again, I’m sure you know better than I do. This is my first HV project. It’s not a very dangerous project (automating insulation resistance testing), but I’d prefer not to make any mistakes.

The creepage check runs idepently for every single layer, if you have a 4 layer board, you can have 4 violation for each pair of net.

Here, it is not clear but I suppose you are looking at the violation of F.Cu, where there is basically only pins. But if you look at B.Cu, you should have another one, mostly likely between tracks based on your picture.

( There error is not clear because they are through holes, and therefore it does not report on which layer the violation is happening )

Can you confirm that this is what is happening here ?

You are correct that these are through hole pins on a relay, and the trace is on the bottom copper layer. However I do not have any errors for the traces themselves. I have 6 errors in total (all creepage) and none of them are for traces on the B.Cu layer. They are all PTH and F.Cu errors. Here is the report from the DRC

** Drc report for IRtestingJig.kicad_pcb **
** Created on 2025-03-12T17:38:35+0900 **

** Found 7 DRC violations **
[creepage]: Creepage violation (rule 'HV_HV' creepage 20.5000 mm; actual 13.4900 mm)
    Rule: HV_HV; error
    @(84.0000 mm, 53.5400 mm): Track [/HVHPT] on F.Cu, length 20.2250 mm
    @(96.5400 mm, 37.7750 mm): PTH pad 2
[creepage]: Creepage violation (rule 'HV_HV' creepage 20.5000 mm; actual 9.2750 mm)
    Rule: HV_HV; error
    @(81.0000 mm, 68.0000 mm): Track [/HVLPT] on F.Cu, length 16.0000 mm
    @(87.8000 mm, 79.2500 mm): PTH pad 6
[creepage]: Creepage violation (rule 'HV_HV' creepage 20.5000 mm; actual 5.5500 mm)
    Rule: HV_HV; error
    @(87.8000 mm, 86.7500 mm): PTH pad 3
    @(87.8000 mm, 79.2500 mm): PTH pad 6
[creepage]: Creepage violation (rule 'HV_HV' creepage 20.5000 mm; actual 13.2168 mm)
    Rule: HV_HV; error
    @(19.7750 mm, 53.5400 mm): PTH pad 1
    @(19.5400 mm, 37.7750 mm): PTH pad 2
[creepage]: Creepage violation (rule 'HV_HV' creepage 20.5000 mm; actual 9.0250 mm)
    Rule: HV_HV; error
    @(27.0000 mm, 68.0000 mm): Track [/HVLPT] on F.Cu, length 12.0000 mm
    @(36.5000 mm, 79.0000 mm): PTH pad 3
[creepage]: Creepage violation (rule 'HV_HV' creepage 20.5000 mm; actual 5.5500 mm)
    Rule: HV_HV; error
    @(36.5000 mm, 86.5000 mm): PTH pad 6
    @(36.5000 mm, 79.0000 mm): PTH pad 3
[removed a long silkscreen overlapping warning here]

** Found 0 unconnected pads **

** Found 0 Footprint errors **

** End of Report **

Just a thought, do you mean that I have to run the DRC while the bottom layer is the active layer? … well, I just tried that and I got no errors for the bottom layer either.

A bit more info to clarify the situation. I have added all the high voltage nets to the “HV” netclass using pattern matching. I then added the low voltage pins that we see in that picture to a “LV” class via pattern matching on the net names of the connector J3 for example. It reports only that one net, so I know I’m testing HV lines vs these specific LV lines, and these are the results we see in the DRC.

There might be an issue with the code, can you open a gitlab issue and upload your board file ? ( if this is sensitive, you can set the issue as confidential ).

From what I see in the code, it looks it still should be running on every layer ( there have been some changes since I first merged it, so I’m not entirely sure ).

Or upload it here if it is not sensitive so I can check that there is no issue with the setting, and if so, then we use gitlab

No problem. I have the version of this board that I posted above with all the secrety stuff removed. I’ll modify that board to have the same netclasses and upload it now or if I don’t have time, tomorrow, assuming it behaves in the same way. (In 7 minutes it’s time to go home here.) If it does not behave in the same way, I’ll set it as confidential. Thanks very much for your help.

Got it done in time! This is the same board as I uploaded higher up in the thread, but I added the same netclasses as in my actual board, and the same rule. The creepage error results look to be the same: no B.Cu errors. Thanks again, and I’ll be back in 15 hours or so.
creepagetest.zip (34.7 KB)

Looks like there is an issue in the code and only F.Cu is checked…

1 Like

Now the issue should be fixed thanks to Seth. The fix will be released in 9.0.1 ( or you can use the current master branch )

… or use the 9.0 testing builds, which are what 9.0.1 will be built from.

Thank you everyone. I’ll try to download a fixed version and keep at it. If no one has any objections, after I gain a little more confidence in what I’m doing, I’ll write up a how-to for people who want to try it out, but like me had no idea how to begin.