How to define keep out zone in KiCAD 6

One correction. You still would get the “clearance to mounting holes” error seen in your latest screenshot. That’s not a bug but logical: the pad is near the board edge and the rule checks if one or the other item is an edge, nothing else. It should work with for example this:


(version 1)
(rule "Clearance to mounting holes1"
  (condition "A.memberOf('mountingholes')")
    (constraint clearance (min 3.5mm)))
(rule "Clearance to mounting holes2"
  (condition "A.memberOf('mountingholes')")
  (constraint hole_clearance (min 10mm))
  (constraint edge_clearance (min 10mm)))
(rule "Clearance to mounting holes3"
  (condition "A.memberOf('mountingholes') && A.Type == 'Pad'")
  (constraint edge_clearance (min 1mm)))

The last rule takes precedence, so the the pad/edge clearance for the mounting hole footprint is 1mm.

Apologies for being a pain in the arse, but I still cannot get it to work. The following tests were carried out using 6.99.0-1665-g4ee6cfe5b6 which, if I understand correctly, should work:

The edge clearance violation is still there:

And also tracks can be routed in the keepout (mounting hole) area:

If I’m doing something wrong, please let me know. And thank you for your replies so far, much appreciated.

Right-click on the DRC error you’re getting (in the DRC dialog) and select “Run clearance resolution tool…”

Thanks Jeff for that trick!

Apparently “A.memberOf(‘mountingholes’)” isn’t satisfied, probably there’s a bug which doesn’t take a pad of a footprint as a member of the group to which the footprint belongs.

EDIT: wait a second, I’ll have to check again…
EDIT2: I was wrong. The problem is in the “unrealistic” example board file. The track and the pad have no net, so they are handled as being in the same net, right? It’s unclear how nonplated holes should be handled logically in this case. But when the track is given a net, the problem disappears.

Correct. You can get around this in 6.99 by using mechanical_hole_clearance.

There’s still one source of confusion. DRC seems to take a NPTH hole as board edge. Is this on purpose, and if so, why?

I can understand that a hole edge is a board edge, kind of, because a hole could be drawn in edge.cuts and routed as well. But considering a drill hole for edge clearance isn’t helpful IMO.

This is intentional. Drilling into full copper has the risk of inter-plane shorts, especially with 0.2mm prepregs. Or think of conductive screws shearing the edge and shorting planes. Long story short: NPTHs are no different to board edges when it comes to the risks.

[EDIT] Ok, it need not necessarily be the edge clearance parameter, the NPTH hole clearance would be ok as well.

I still fail to get it to work. I tried using mechanical_hole_clearance but to no avail. Here are my rules:

(version 1)
(rule "Clearance to mounting holes1"
  (condition "A.memberOf('mountingholes')")
    (constraint clearance (min 3.5mm)))
(rule "Clearance to mounting holes2"
  (condition "A.memberOf('mountingholes')")
  (constraint hole_clearance (min 10mm))
  (constraint mechanical_hole_clearance (min 10mm))
  (constraint edge_clearance (min 10mm)))
(rule "Clearance to mounting holes3"
  (condition "A.memberOf('mountingholes') && A.Type == 'Pad'")
  (constraint mechanical_hole_clearance (min 1mm)))

This is how it looks like in 6.99.0-1690-g55a8fb39c4:

Same problems as before: The track can still be routed in the area it shouldn’t. And I’m still getting DRC errors/warnings for the mounting hole.

The hole on the edge layer however works perfectly, it throws no DRC error and it prevents the track from being routed. I’d like this same behaviour for the MountingHole as well.

Am I using mechanical_hole_clearance wrong?

The track routes in to the area you don’t want because of the last rule: since the type of object is a pad, it sets the mechanical_hole_clearance to 1mm.

The board edge violation is because you have overridden the mechanical_hole_clearance of the pad, but not the edge_clearance.

If you change that last rule from mechanical_hole_clearance to edge_clearance it might fix both.

Partial success! Thanks for the suggestion. I’m now using the rules:

(version 1)
(rule "Clearance to mounting holes1"
  (condition "A.memberOf('mountingholes')")
    (constraint clearance (min 3.5mm)))
(rule "Clearance to mounting holes2"
  (condition "A.memberOf('mountingholes')")
  (constraint hole_clearance (min 10mm))
  (constraint mechanical_hole_clearance (min 10mm))
  (constraint edge_clearance (min 10mm)))
(rule "Clearance to mounting holes3"
  (condition "A.memberOf('mountingholes') && A.Type == 'Pad'")
  (constraint mechanical_hole_clearance (min 1mm))
  (constraint edge_clearance (min 1mm)))

This got rid of the DRC errors of the mounting hole. Lovely! But the issue with the track still remains.

As I said earlier, you don’t have a “real world” example here. Usually the track would belong to some net, and that should remove the problem.

Remove the mechanical_hole_clearance constraint from the last rule and try that.

Thanks, that’s it. I keeping the example as simple as possible. But adding a net works:

This is the rule which seems to solve both issues:

(version 1)
(rule "Clearance to mounting holes1"
  (condition "A.memberOf('mountingholes')")
    (constraint clearance (min 3.5mm)))
(rule "Clearance to mounting holes2"
  (condition "A.memberOf('mountingholes')")
  (constraint hole_clearance (min 10mm))
  (constraint edge_clearance (min 10mm)))
(rule "Clearance to mounting holes3"
  (condition "A.memberOf('mountingholes') && A.Type == 'Pad'")
  (constraint mechanical_hole_clearance (min 1mm))
  (constraint edge_clearance (min 1mm)))

It now works as desired. Thanks to all of you for the replies!

Final question: Will this be included in the 6.0.5 release? KiCad 6.0.4 throws: “Unrecognized item ‘mechanical_hole_clearance’”

I think you can conflate the rules 1 and 2 into one because the condition is identical and there are three different constraints for that same condition; just put all three constraints under one rule.

All v6 files must be compatible with all v6.x.y versions (also backwards), so this will not be added to v6.

Well observed. That works, indeed.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.