(rule prim_sek
(constraint clearance (min 4.5mm))
(condition “A.NetClass == ‘Sek*’ && B.NetClass == ‘Default’ || B.NetClass == ‘P-400V’”))
This rule can’t handle unconnected pads assigned to no net.
These pads are invisible in EEschema so I can’t assign a ‘dummy’ net class to them.
I’ve got hundrets of DRC errors and routing is impossible.
Any suggestions
I’m no Custom Design Rules specialist, but here’s my 2 cents.
Basically, A.Pin_Type==‘Unconnected’ should work as a term, but it does not, no matter whether you leave the pin open or give it a “No connect” flag.
@JeffYoung Did I miss something? Bug? Pin types like ‘Output’, ‘Input’ work.
Checking for A.Pin_Type == '*no_connect' will find either a pin of type “unconnected” or one with a “No Connect” flag on it.
The first will be “no_connect” while the second will be something like “passive+no_connect”.
FWIW, we do not generate “no_connect+no_connect” for both conditions being true; it drops the suffix in that case.
Ok, thx. But then, what does the Pin_Type ‘Unconnected’ (as listed in the online help) mean?
It would appear to mean the help is buggy. 
Which help is that? (I don’t see it in the Custom Rules Syntax Help…)
Thanks a lot!
This does the trick.
(rule prim_sek
(constraint clearance (min 4.5mm))
(condition “A.NetClass == ‘Sek*’ && B.Pin_Type != ‘*no_connect’ && B.NetClass == ‘Default’ || B.NetClass == ‘P-400V’”))
Just for my understanding:
‘No net’ pads are not part of the rule, so why does the 4.5mm contraint trigger at ‘no net’ pads?
Should I write a bug report for this?
Part of the problem is that all pads of a footprint who doesn’t have a dedicaded pin in the correspondending schematic symbol are automatically assigned to ‘Default’ net class.
Because net assignement in PCB is not supported this is only changeable if I edit the symbol and add the additional pins with the ‘not connected’ flag.
Bug report?
Furthermore I use a footprint converted from a Eagle lib.
All of the unconnected Pads in this footprint a assigned to ‘Default’ but without any netname.
Netname is blank an so ‘*no_connect’` can’t prevent rule violation.
Once again this is only changeable if I add correspondending pins in the schematic symbol with ‘not connected’ flag.
Bug report?
Not sure on the first one. You might try some parentheses around your boolean expressions; I’m not sure what the precedence rules in our parser are.
On the second one, that’s by design (possibly more for historical reasons than anything else). FWIW, you can assign nets in PCBEdit (in the Pad Properties dialog). If you want to assign a new net that doesn’t exist in the schematic you’ll need to create it first in Inspect > Net Inspector.
But generally speaking it’s best to specify what pins/pads are for in the schematic. Pins that aren’t used should be either “No connect” or “Free”.
I’ve overlooked that.
In the pads properties dialog the Pads mit blank net names are ‘no net’
But I can’t find a rule for ‘no net’ or blank net names and so my rules are contantly trigger at all ‘no net’ pads. Strange behavior…
Seems that I have no other chance than to add invisible pins with not connected flag in the schematic symbols.
Thanks for your help!
So I noticed that when connecting footprints, a mesh is created, but when moving it with keyboard “G” it becomes multiple parts.
When the net is laid down, not just one section is created at the corners, but several, which are not all connected to form a net again. If you now click on a part to move it, you sometimes have the choice of two to an infinite number of parts.
All the parts covered by other parts should be deleted so that such an error does not occur again.
Try A.NetCode == 0. (Or maybe -1 if that doesn’t work…)
Kills the hole Rule.
But for now I have a much bigger problem.
This custom rule is working perfectly but ONLY on Bottom Layer.
(rule prim_sek
(constraint clearance (min 4.5mm))
(condition “A.NetClass == ‘Sek*’ && B.Pin_Type != ‘*no_connect’ && B.Pin_Type != ‘free’ && B.NetClass == ‘Default’ || B.NetClass == ‘P-400V’”))
Seems to me that the custom rule system has seriosly problems.
You probably have your rules in the wrong order. Click on the top-layer zone and one of the pads that should be generating a larger clearance and do a Inspect > Clearance Resolution…
I could be that I’m totaly overstrained with this powerfull monster called custom rules.
But I can’t find out what I’m doing wrong.
Its getting stranger every minute.
In one part of the layout the rule is functional, but anyway it triggers not to stiching vias of the ‘hostile’ net class.
A few cm beside with the same signals and net class the rule is completely ignored or triggers to pads but not to tracks or not not to stiching vias.
Same net, same net class just a few cm away.
I’ve created a (confidential) bug report and Seth Hillbrand asked for the project file.
https://gitlab.com/kicad/code/kicad/-/issues/10509#note_815601565
I will investigate this further and post my findings in the bug report.
Thanks for now and perhaps you want to take part in the bug report diskussion.
Clearance Resolution reports will definitely be your friend when trying to debug Custom Rules.
I did see the bug report. I’ll probably end up on my TODO list unless Seth gets curious about it.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
