Default REGEX_EXCLUDE footprint name filter excludes components whose footprint names contain "MountingHoles"

[ghost]

Default REGEX_EXCLUDE footprint name filter excludes some components whose footprint names contain "MountingHoles".

Per the default bom.ini, a component whose footprint field is "PROJ_LIB:DSUB-9_Female_Vertical_P2.77x2.84mm_MountingHoles" would be matched by the default filter (below) and silently excluded from the BOM.

[REGEX_EXCLUDE]
; A series of regular expressions used to exclude parts from the BoM
; If a component matches ANY of these, it will be excluded from the BoM
; Column names are case-insensitive
; Format is: "[ColumName] [Regex]" (separated by a tab
References      ^TP[0-9]*
References      ^FID
Part    mount.*hole
Part    solder.*bridge
Part    test.*point
Footprint       test.*point
Footprint       mount.*hole
Footprint       fiducial

[SchrodingersGat]

@phansel thanks for reporting. Would you be willing to submit a PR to fix this?

[ghost]

I have a couple theories on how we could address this:

• Expand the References list
• Edit the KiCAD standard library so that SMT test points and mounting holes have DNI already populated
• Match only if the footprint and the part match MH/MK/TP/FID
• Prompt the user or pass a warning in the BOM generation terminal

[set-soft]

Looking at the current KiCad 6 library I see that real mounting holes starts its name with MountingHole_ all other components that matches mount.*hole doesn't have it at the beginning.

So I think that for KiCad 6 we just need to add a ^

The same seems to be true for the KiCad 5.1.9 lib.

[hraftery]

This bit me again with a DSUB-9_Female_Horizontal_P2.77x2.84mm_EdgePinOffset7.70mm_Housed_MountingHolesOffset9.12mm footprint for a DE9 connector. I thought of the same mitigation as @set-soft and I think it could have sufficed for me (if it was applied to Footprint as well!).

But I opted for something less subtle, removing the Part mount.*hole and Footprint mount.*hole lines entirely and adding a References ^H line instead. My rational was its better to have to correct a mistaken BOM entry than unknowingly order a BOM with a missing item, but I'm not sure how universal my motivations are.

Also worth keeping in mind issue #178 , which has the same root cause. Any fix should probably be general enough to catch this family of issues, without making the out-of-the-box experience worse for most users.