Need some guinea pigs for a rule-based DRC <<PROTOTYPE>>

unfortunatelly now in eescheme i cannot see the wires i draw. Maybe you have look at it (todays version)

EDIT: I had to downgrade to kicad-r16539.0fecb5f27-x86_64 so that eescheme works.

One question: How do i specify netclasses in eescheme?

@JeffYoung: How do i specify the clearance to a board edge? Can you please add an example?

Is there any possibility to work to implement smaller clearances when there is a cutout?

try:

(rule "board-edge-clearance"
   (constraint clearance (min 0.5mm))
   (condition "B.onLayer(Edge_Cuts)")
)

For cutouts you’ll need to draw a zone around the cutout and give it a name. Then try:

(rule "cutout-edge-clearance"
   (constraint clearance (min 0.2mm))
   (condition "B.onLayer(Edge_Cuts) && B.insideArea('zone_name')")
)

ooo this looks interesting.
I am presently laying out two higher voltage cards so I want to see how this works.
The way such things are done in Mentor Xpedition are painful to say the least as they just expanded their high-speed clearance table to everything…

Is there any plan to consider 3D? ill give you the two examples that i am usual guaranteed to find a problem in a layout.

  1. creepage due to cuts
    Whether it is board edge or some NPTH, this can be a creepage path for an internal (or external ) conductor. If you require a creepage path of 3.5mm (to realise a working voltage of 900V) that is ~1.75 from any cut as it is the creep to the edge, around the edge of the card (cut or drill) and back in.
    Yes this could be crudely done with the board-edge clearance but this applies larger distances universally rather than selectively.

  2. considerations of prepreg.
    FR4 is ok, Poly is better, but there could be quality issues with the weave and therefore we would use a minimum of two prepreg’s to ensure guaranteed separation. We also have intralayer separation (for FR4) to ensure there is suitable z-clearance through the prepreg (1.1mm for 900V). This one is a bugger as constantly check with x2+y2 (or we simply go… make sure you have 2mm)

the other consideration is collections of circuits which locally have the same reference and potentials (so typical 8thou:8thou rules) but need higher clearances from other circuitries

Good examples are gatedrives where the secondaries traverse the full DClink swing while the primary would be references to some processor. Equally isolated CAN or some isolated discrete.

a typical card of mine could have at least 10 higher voltage clearance type sub-circuits and another 10-20 “transient” or lower voltage clearance. These zones could also have high-speed signal concerns so controlled impedances exist.

Each one of these cases adds another rule and thus causes the conditions to grow exponentially to ensure Ch1_default is clear from Ch1_50R_SOA (8thou) which in turn are clear from CH2_default (3.5mm) and again Ch2_50R_SOA an so on.

Mentor’s approach is a big table and i would typically end up with over 200 row-column’s to ensure all conditions of rules to rules are covered… huge. Yet the grouping clearances are only about 12 but this is more in an excel for visual checks as I then apply to the constraint manager

I’m trying to write rules (or expressions) for Different clearance inter-Copper zone and rest of copper. KiCad crashes when I press the debug button after this text:

(version 1)
(rule "twozones_clearance"
	(constraint clearance(min 0.5mm))
	(condition "")
)

I still have to try with up to date codebase, it’s compiling. But I wonder if the quotes in the condition have something to do with it. If I take them off, the check works, i.e. shows an error message about missing expression. With the quotes it crashes.

The new rules would work very well with your reference & potential examples. The recommended way would be to give your gatedrive/CAN bus/whatever a netclass and then specify rules between that netclass and either other types of item or other netclasses (or a combination of the two).

Because it’s not done in a table you only have to specify a general rule and then the conditions you need a more specific rule for.

We don’t yet do creepage. We’ve just added a board stackup manager which allows you to specify dielectric properties, but we don’t yet use these in DRC.

@eelik, your empty quote example reproduces for me. I’ll get a fix in.

great.
ill get hold of a nightly to try (in isolation) but from what has been describe it does seem manageable.

now I really want v6! keepouts work but are hacky and too much human error creeps in

Keep in mind that while the syntax is getting closer to what we’ll ship, it’s still not final so you may have to rework some things…

understandable. I would never dream of using a nightly for this as these cards need to go for fabrication.
I just wanted to poke to break it

BTW: https://gitlab.com/kicad/code/kicad/-/issues/5159

New guinea pig here.

What’s wrong with this:

(version 1)
(rule “touch_lines”
(constraint clearance(min 2mm))
(condition “A.NetClass == ‘touch’ && A.insideArea(‘GND’)”)
)

Bug check says: no error. Pcbnew hangs for a little while, then crashes and immediately restarts.

Note: I’m no python/sexpr guy (although I get the concepts), so I appreciate you bearing with me ;-).

5.99 nightly 12.8. Windows 10

Looks good to me. (But even if it didn’t, it shouldn’t crash.)

Let me see if I can reproduce it or if I need your board…

…and the project. Lol
It crashes after closing the board setup.

Probably there’s some problem in KiCad there, I added the rule after my rule and now when I click the bug button KiCad gets stuck in some loop eating up 100% of one processor core.

Does not crash when the board is opened/loaded initially. Btw, I take it that the new rule machine is applied when filling zones (B) as well.

Here is the complete story: crashes when closing the board setup dialogue, crashes when running a DRC, but DOES NOT crash when doing a zone fill. In this case it removes the entire fill (but not the zone itself or any tracks).

Addendum: the zone fill removed when doing a zone fill is the zone in question (GND). Zones with other names remain filled all right.

Awesome, I really should start using gitlab

The crash is a layer handling issue. (It’s actually only a debug assert, but it’s flagging a real issue.)