The “courtyard.clearance” rule still does not work with the nightly versions released to date.
(version 1)
(rule “Distance between test points”
(constraint courtyard_clearance (min 1.54mm))
(condition “A.memberOf (‘TP1mm’) && B.memberOf (‘TP1mm’)”)
)
I inserted the circle on the “Courtyard” layer in the “TP1mm” group
but I do not detect any violations.
Do I have to wait a few more days?
The courtyard test is run on the footprint, so ‘A’ and ‘B’ are going to be the footprints, not the courtyard shape.
So get rid of the groups and try something like:
(condition "A.Reference == 'TP*' && B.Reference == TP*'")
(Or use Value if you have different kinds of test points with different clearance requirements.)
Perfect.
Now works .
Thanks
1 Like
I wanted to create another rule that warns me if the distance between the trace and the via for is less than a certain value.
(rule "Via to Track Clearance"
(constraint hole_clearance (min 0.5mm))
(condition "A.Type =='Via' && B.Type =='Track'")
)
I’ve tried several options but can’t find the violation.
In the pcb there is at least one trace which is 0.4mm between a via hole.
Yikes. Time to log another bug. (Turns out we only do hole clearance checks against pads, not vias.)
Perfect. Now this rule works too.
Now I will set all the rules of my usual pcb supplier.
At this point I should succeed.
I wanted to implement this “PTH to Track” rule
Don’t know the right name that is indicated as “A.Pad_Type == ‘PTH’” ?
But I don’t get errors.
(rule "PTH to Track Clearance"
(constraint hole_clearance (min 1mm))
(condition "A.Pad_Type =='PTH' && B.Type =='Track'")
)
I’m not sure how we’re going to document this stuff, but for now:
ENUM_MAP<PAD_ATTR_T>::Instance() // Pad_Type
.Map( PAD_ATTRIB_PTH, _HKI( "Through-hole" ) )
.Map( PAD_ATTRIB_SMD, _HKI( "SMD" ) )
.Map( PAD_ATTRIB_CONN, _HKI( "Edge connector" ) )
.Map( PAD_ATTRIB_NPTH, _HKI( "NPTH, mechanical" ) );
ENUM_MAP<PAD_SHAPE_T>::Instance() // Shape
.Map( PAD_SHAPE_CIRCLE, _HKI( "Circle" ) )
.Map( PAD_SHAPE_RECT, _HKI( "Rectangle" ) )
.Map( PAD_SHAPE_OVAL, _HKI( "Oval" ) )
.Map( PAD_SHAPE_TRAPEZOID, _HKI( "Trapezoid" ) )
.Map( PAD_SHAPE_ROUNDRECT, _HKI( "Rounded rectangle" ) )
.Map( PAD_SHAPE_CHAMFERED_RECT, _HKI( "Chamfered rectangle" ) )
.Map( PAD_SHAPE_CUSTOM, _HKI( "Custom" ) );
ENUM_MAP<PAD_PROP_T>::Instance() // Fabrication_Property
.Map( PAD_PROP_NONE, _HKI( "None" ) )
.Map( PAD_PROP_BGA, _HKI( "BGA pad" ) )
.Map( PAD_PROP_FIDUCIAL_GLBL, _HKI( "Fiducial, global to board" ) )
.Map( PAD_PROP_FIDUCIAL_LOCAL, _HKI( "Fiducial, local to footprint" ) )
.Map( PAD_PROP_TESTPOINT, _HKI( "Test point pad" ) )
.Map( PAD_PROP_HEATSINK, _HKI( "Heatsink pad" ) )
.Map( PAD_PROP_CASTELLATED, _HKI( "Castellated pad" ) );
1 Like
Hi. A question. I am trying out the rule system in version (5.99.0-7511-ga134567838), release build.
I was attempting to create a rule to keep the copper away from graphic defined areas such as the board outline and any graphic items on a Eco.User1 Layer that I renamed “Boundary”
I created two rules:
(rule “Reinforced PRIMARY to BOUNDARY”
(constraint clearance (min 5.5mm))
(condition “A.NetClass == ‘PRIMARY*’ && B.Layer == ‘Boundary’”))
(rule “Copper to Board Edge”
(constraint clearance (min 20mil))
(condition “A.Layer == ‘*.Cu’ && B.Layer == ‘Edge.Cuts’”))
The clearance to the board edge rule works fine. The router stops 20mils from the board edge. I tried changing the rule to 100mils and it still works OK. However, the rule to keep any Nets belonging to the “PRIMARY” NetClass and the graphic objects on layer “Boundary” does not appear to work. Are the User layers being considered when running the constraints?
EDIT: Unfortunately, the project appears to be crashing a lot now.
The “clearance” constraint only applies on a single copper layer (and Edge.Cuts, which are treated as being on every layer).
DRC examines both the Edge.Cuts and Margin layers for the “edge_clearance” constraint, so that might be a solution for your “Boundary” objects. I’m not sure about the router though.
A little bit confused by the statement " Later rules take precedence over earlier rules; once a matching rule is found no further rules will be checked." in the syntax help. How can later rules take precedence if rule checking stops when a matching rule is found. Can anyone clarify?
Is A.Pad_Type implemented?
It doesn’t seem to work.
Or it is I who write badly.
If I remove this entry A.Pad_Type == ‘Through-hole’ violations are found but if I leave it I don’t detect any problems.
(rule "PTH to Track Clearance"
(constraint hole_clearance (min 0.33mm))
(condition "A.Type == 'Pad' && A.Pad_Type == 'Through-hole' && B.Type == 'Track'")
)
I wanted to distinguish between PTH pad and NPTH pad since the pcb manufacturer makes this distinction.
Because it checks them in reverse order…
Thanks.
If my PCB is crashing KiCad often, should I send it or mail it somewhere for debugging purposes. My current PCB seems to be crashing KiCad every few actions.
Log a bug (and post the board) on GitLab:
There might be better instructions elsewhere. It’s hard for me to see the forest for all the trees… 
It seems that the constraint “clearance” does work with the “Margin” Layer as well. New rules:
(rule “Reinforced PRIMARY to BOUNDARY”
(constraint clearance (min 5.5mm))
(condition “A.NetClass == ‘PRIMARY*’ && B.Layer == ‘Margin’”))
(rule “Reinforced PRIMARY to BOUNDARY”
(constraint clearance (min 5.5mm))
(condition “B.NetClass == ‘PRIMARY*’ && A.Layer == ‘Margin’”))
1 Like
That looks correct. Could you log a bug with an example? I’ll need to look in to it. (The property stuff came from Orson and I’m not that familiar with it.)
I don’t know if this is a stupid question, but is there a way to ignore a clearance completely? Now there are constraint min, max, opt. There’s no obvious way to set it to be ignored so that for example I could create a rule area inside a castellated footprint which would allow having tracks over the edge. This could maybe be used also as a net-tie workaround: set net clearance to “ignore” inside a footprint pad.
@JeffYoung I found some time to experiment and can confirm @BoxFish observations. I have the same requirements @BoxFish.
I might have an older version (2 weeks nightly…) Tell me if this is the problem.
The following term leads the following image:
(version 1)
(rule “THT PAD Clearance”
(condition “A.Type == ‘Pad’”)
(constraint clearance (min 2.3mm))
)
Now, we want only through-hole pads. Thus we add your proposed syntax. It looks now the following:
(version 1)
(rule “THT PAD Clearance”
(condition “A.Type == ‘Pad’ && A.Pad_Type == ‘Through-hole’”)
(constraint clearance (min 2.3mm))
)
However, clearance is NOT maintained.
EDIT:
@JeffYoung I saw that you requested a test board. I just emailed you the test board for tracking down that issue.
EDIT 2
The hole clearance statement seems to have issues as well. So please double-check the following statement:
(version 1)
(rule “THT PAD Clearance”
(condition “A.Type == ‘Pad’”)
(constraint hole_clearance (min 2.3mm))
)
If we fixed that hole statement, it could be a good idea, to add this to the DRC examples as other users might have that question too.
Do you have the updated nightly?
The distance of the holes between the pads has been corrected.
The rule that determines the violation is this:
(rule "Distance between Vias Hole Same Nets"
(constraint hole_to_hole (min 0.254mm))
(condition "A.Type =='Via' && B.Type =='Via' && A.Net == B.Net")
)
(rule "Distance between Vias Hole Different Nets"
(constraint hole_to_hole (min 0.5mm))
(condition "A.Type =='Via' && B.Type =='Via' && A.Net != B.Net")
)
I had set the rules for the vias.
The following are for the Pads:
(rule "Distance between Pads Hole Same Nets"
(constraint hole_to_hole (min 3.0mm))
(condition "A.Type =='Pad' && B.Type =='Pad' && A.Net == B.Net")
)
(rule "Distance between Pads Hole Different Nets"
(constraint hole_to_hole (min 3.0mm))
(condition "A.Type =='Pad' && B.Type =='Pad' && A.Net != B.Net")
)