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

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.

Ok, I’ve gotten the updated test version and it is working much better! Very good work.

However, as I’ve now got some rather reliable creepage tests, I’ve been improving my board, and I have come across another issue that I think is not the intended result.

It appears that at least on an inner layer (oh I went ahead and increased my board to 4 layers to help with routing which was getting tight in too many places), slots can get ignored. I have double checked this slot on the 3D view, and it does show it to be cut out of the PCB, so I suspect that this creepage error should be a different location:

I also think I’m going to improve on that slot and make it look a bit more like a tab so that the creepage is forced to take a different route on the In2.Cu layer as well. It is currently hitting in that spot on the left with the red marker. I’ll strip out the fancy stuff on this version of the board and upload it if you like. … I did so, and this time the error did not occur in the same place. That error is now just missing. Perhaps the error in the DRC is older than that slot. I’m sorry I can’t be certain of that error at the moment. If it happens again at this point, I’ll know for sure.

I went ahead and added the tab, like a u shape around the pin, and now all creepage errors for that pin are gone, but the minimum creepage test condition is 20.5mm, and using the measure tool, I estimate that moving from the PTH to the In2.Cu layer’s HVH1 trace is about 7.5ish or so mm. There should probably be some sort of error there, but there’s nothing. Maybe it’s because the PTH doesn’t connect on that layer? I doubt there’s an air gap around the PTH just because there’s no copper connecting to it. Then again… if that were the case, it wouldn’t have given the error before either.

I’ll go ahead and upload this version of the test board and you can play around with it if you like. These results are enough to make me feel a bit more confident about my design, so I’ll probably send this off and build the prototype. I only need around 1.5mm of creepage distance on an inner layer, and I’m now around 5mm on most errors. That’s probably good enough as long as the relays hold up.

creepage-test-4layer.zip (36.2 KB)

Just as an update since I suddenly abandoned this thread. Holidays and life have gotten in the way a bit as usual. I have found a few more bugs and have preliminarily reported them in existing bug reports that seemed similar, but I have been asked to make new bug reports for each issue. I’m not exactly sure which bugs are related or not, but I intend to make those bug reports as soon as I can.