Custom DRC for Overlapping Footprints Silkscreen Elements

Layout Footprints
1

I have two components on my PCB that have the same footprint and occupy the same space as if they were one component, only one component will be populated at a time. I have a custom design rule setup to bypass the courtyard overlap error however I am not having success getting rid of the silkscreen overlap errors. Below the additional context is more information.

Additional context (not necessary but useful);
I am using KiVar (GitHub - markh-de/KiVar: PCB Assembly Variants for KiCad) to control 2 variants of a product requiring 2 different crystal frequencies, depending on the variant one of two crystals is populated and although both crystals share the same footprint the specific information about them is controlled in my component libraries. The issue is introduced because I am wanting to place the footprints for these two components on top of each other to save PCB space. The smoother workflow would be to change the MFG and MPN information fields depending on the variant and re-using the same footprint, however this this takes control of that specific information from the revision controlled component library and places the information in the schematic which is not ideal for my workflow.

Working courtyard overlap rule

(rule "Allow overlapping courtyards for DNP parts"
    (condition "A.Type == 'Footprint' && B.Type == 'Footprint' && B.Do_not_populate")
    (constraint courtyard_clearance (min -1mm))
)

Attempted but not working silkscreen overlap rule, errors still persist.
(rule “Silkscreen overlap with DNP footprint”
(condition “A.Layer == ‘Silkscreen’ && B.Layer == ‘Silkscreen’ && B.Type == ‘Footprint’ && B.Do_not_populate”)
(constraint clearance (min 0mm))
)

I also attempted to use this for the silkscreen lines with no success.
(rule “Silkscreen overlap with DNP footprint”
(condition “A.Layer == ‘Silkscreen’ && B.Layer == ‘Silkscreen’ && B.Type == ‘fp_line’ && B.Do_not_populate”)
(constraint clearance (min 0mm))
)

DRC errors
DRC errors1435×674 60.3 KB

4

DRC errors 3
DRC errors 31229×898 49.6 KB

5

Technical note: please use “Preformatted text” for all text which needs to be displayed verbatim character by character, for example code, OS prompts and here the textual rules. Otherwise the forum software messes them up. I edited one rule as an example.

6

Is there some advantage to this, relative to making a combi footprint and placing that with one symbol?

For example, this is my SOT23-SOT223 combi. I did not bother creating a silkscreen outline but that would not be difficult:

image
image587×826 3.78 KB

7

The courtyard rule works because it is run on the footprints (A and B), they have the DNP attribute.

However, in the silkscreen case, A and B are the graphic items, and it’s their parent that has the DNP attribute. Sadly, we don’t currently have any way to say A.parent.Do_not_populate.

(Another option would be to put a DNP property on the graphic items and have them internally query their parent footprints. But that’s a slippery slope as there are a lot of other parent properties you might want to query.)

8

Bobz,

I appreciate the suggestion however both crystals have the same footprint so no combo footprint is required. I also do not want to add special case footprints to my managed component library as the crystal may be used on its own in a design where this case of overlapping the components is not used.

Working off of your suggestion I could assign a footprint to one of the components within the schematic with no elements in the footprint which would lead to no conflicts. I have a hesitancy to do that though because now the component in the schematic deviates from the managed component library.

-Daniel

9

Jeff,

Thank you for the insight into the inner workings of the design rules.

I was definitely confused by the lack of the Do_not_populate property on the fp_line because it is contained withing the footprint.

Untitled
Untitled700×1350 194 KB

If I happened to be a person who liked slippery slopes, how would I go about investigating your suggestion of adding the DNP property to the graphic items? Is there a resource you can point me to?

-Daniel

10

At the very bottom of pcb_shape.cpp you can see where it defines the properties. You’d need to add new properties (probably for all 4 attributes, Exclude_from_SIM, Exclude_from_board, etc.). You’d then need to add a getter (and no setter), and you’d need to set the flag that says not to show them in the properties inspector.