Custom rule for DRC error "items shorting two nets" (allow stacked no-connect pins)

[pferdob]

Hi all!

Anybody solved the problem of stacked ‘no-connect’ SMD/TH pads creating DRC errors?

This does have some sense inherent sense because of the no-connect ‘x’ in the schematic their nets default to two differing ‘unconnected-(REF-PAD)’ net names. Problem is, that I do not find any way to make the DRC understand the collision is ok:

I created a rule to allow for collisions these.

(rule "Clearance: Allow shorting of stacked 'no connect' pads"
   (constraint clearance (min -1mm))
   (condition "A.Type == 'Pad' && B.Type == 'Pad' && A.Net != B.Net && A.NetName == 'unconnected-*' && B.NetName == 'unconnected-*'"))

The clearance resolution seems to work, but the DRC errors are created nevertheless…

I’d appreciate help on this

Version is yesterdays 7.99 nightly.

[JeffYoung]

You shouldn’t need the rules at all for this.

Bug fix in: d428b0e20ec9fefb47272698811abcac717d118b

[pferdob]

Thanks, Jeff. I also just found Do not mark multiple no-connect pads of the same name as requiring connection (#15692) · Issues · KiCad / KiCad Source Code / kicad · GitLab

[JeffYoung]

He he, yeah that was the fix that broke it.

[pferdob]

Hey Jeff,

maybe you could - once again - look into this thing. I afraid of opening too much issues and I think this might be connected to the previous bug.

DRC complains about insufficient clearance (<0.8mm)

like this

even though the rule

(rule "Clearance: Net class Default vs. everything (outer layers)"
   (layer outer)
   (constraint clearance (min 0.8mm))
   (condition "A.NetClass == 'Default' && (B.NetClass == 'DIO' || B.NetClass == 'Ctrl' || B.NetClass == 'Bat+' || B.NetClass == 'Bat-') && B.NetName != 'unconnected*'"))

does not apply here… as the clearance resolution clearly shows:

Clearance resolution for:
Layer F.Cu
Track [/Controller/DI_{Iso0}] on F.Cu, length 4.0100 mm [netclass Ctrl]
Pad 26 [unconnected-(U14-GPIO20-Pad26)] of U14 on F.Cu [netclass Default]

[...]

Checking rule Clearance: Net class Default vs. everything (outer layers) clearance: 0.8000 mm.
Checking rule condition "A.NetClass == 'Default' && (B.NetClass == 'DIO' || B.NetClass == 'Ctrl' || B.NetClass == 'Bat+' || B.NetClass == 'Bat-') && B.NetName != 'unconnected*".
Condition not satisfied; rule ignored.

[...]

Board minimum clearance: 0.2000 mm.

Resolved clearance: 0.2 mm.

This only happens with unconnected pads, so I some feel as if this belongs here somehow… I do have about 30 errors like this, all related to NC pins…

Thanks in advance!

[JeffYoung]

Can you do a Save As of the project, whack down the board to just a minimal case the reproduces it, and post a zip of project here (or on GitLab)?

[eelik]

Why does your screenshot of the error show “Clearance: Net classe” while the rule name has “Clearance: Net class”?

[pferdob]

You’re on to something here :-D. Did edit the rule itself and the posting after realizing this myself. Just a typo.

[pferdob]

I hope, this does the job: cvtcs-c kicadjeff.zip (1.8 MB)

I left some parts from other net classes in the PCB there on purpose. Sorry that the thing is still so large on filesize

[JeffYoung]

@pferdob what version are you on?

My clearance report agrees with DRC (note that it also lists the track and pad in a different order at the top – that shouldn’t matter, but is interesting).

[JeffYoung]

And the condition looks like it’s correctly firing to me.

We are on an “outer” layer (F.Cu), one netclass is “Default” and the other is “Ctrl”.

(Note that ‘A’ and ‘B’ are not order-specific; it will run the rule in both directions. They just mean “one” and “the other”.)

[pferdob]

Hey Jeff,

thank you for looking into this.

Heres the output of with the exact same pad and track you used:

Version: 7.99.0-1.20230927git3c40cb3.fc38, release build

Version: 7.99.0-1.20230929gitfa11e91.fc38, release build

Could it bet, that the B.NetName != ‘unconnected*’ is ignored in your case?

I used this to test for the NC pins. In this case, this could be circumvented by putting net-class labels on all the NC pins in the schematic for the µC module. But there are cases, like for example EEPROM footprints with NC (by the manufacturer) which are not accessible in the schematic but also fits NetName != 'unconnected*' in the PCB…

If the rule is evaluated the other way round… in my opinion, it should not be applied either as B.NetClass has no test for ‘Default’?

Regards

[pferdob]

Aha… just realized the differing window caption in your screenshot. If you start the clearance resolution from the menu and not directly from the DRC I also get your results:

Now the bullet points state a “reversed” order for the pad 26 and the track which are tested. And now the rule is applied However…

• I do not understand how this rule can be applied.
• How’s the clearance resolution different when started from the DRC if pad and track are tested in both A-B and B-A order?

[JeffYoung]

Oh, now that is interesting. That does reproduce for me.

[JeffYoung]

That turned out to just be a typo when we call the reporter via the DRC dialog (it was passing ‘A’ into both ‘A’ and ‘B’).

So now the various clearance reports agree with each other (and with DRC), but the question remains why the “unconnected*” test isn’t working…

(Sadly my debugger is crashing when I try to put a breakpoint there, so I’m going to have to figure this one out somewhat blind.)

[JeffYoung]

Ahh… it’s an error in the rule. While we run the rule in both directions (A:B and B:A), each one is constant for a particular evaluation.

In this case the unconnected net is the one with the “Default” netclass. The rule compares ‘A.NetClass’ with “Default”, but ‘B.NetName’ with “unconnected*”.

So you need to add && A.NetName != 'unconnected*' at the end.

[pferdob]

Oh man, thank you. You are absolutely right.

For me, it’s always hard to differentiate between “I screwed up the rules” and “some logic does evaluate properly here”…