W045 on KiCad lib footprints

[oliv3r]

For whatever reason, present triggers a W045, where gerber or render3d individually does not. Out of all my kibot jobs, its only present that triggers this.

DEBUG:- Loaded ?? (LMH7322SQ ) [id 130870545042640]  UUID e26e4a6e-04b6-4c3b-8d22-d8dfbe709077 original UUID e26e4a6e-04b6-4c3b-8d22-d8dfbe709077 (kibot - v6_sch.py:2281)
DEBUG:Collected sheet instances (kibot - v6_sch.py:2138)
DEBUG:- / -> 1 (kibot - v6_sch.py:2140)
DEBUG:Collected symbol instances (kibot - v6_sch.py:2141)
DEBUG:- /e26e4a6e-04b6-4c3b-8d22-d8dfbe709077 -> U1 (kibot - v6_sch.py:2143)
DEBUG:Collected sheet paths (kibot - v6_sch.py:2144)
DEBUG:- / (kibot - v6_sch.py:2146)
DEBUG:  - /e26e4a6e-04b6-4c3b-8d22-d8dfbe709077 -> ?? (LMH7322SQ ) (kibot - v6_sch.py:2148)
DEBUG:Assigning components to instances (kibot - v6_sch.py:2316)
DEBUG:- /e26e4a6e-04b6-4c3b-8d22-d8dfbe709077 -> U1 -> 130870545042640 e26e4a6e-04b6-4c3b-8d22-d8dfbe709077 (kibot - v6_sch.py:2358)
DEBUG:Schematic dependencies: ['/workspace/test/test.kicad_sch'] (kibot - kiplot.py:253)
DEBUG:- Removing U1 (kibot - out_base.py:1091)
DEBUG:Removing paste, mask and/or glue (kibot - out_base.py:399)
WARNING:(W045) Pad with solder paste, but no copper or solder mask aperture in U1 (kibot - out_base.py:434)

The footprint is from the standard kicad library, and looking at the footprint we see nothing odd or strange.

Attached a mini project with a minimal kibot file that triggers this issue.

$ docker run --pull always --user "$(id -u):$(id -g)" --env HOME=/tmp --rm -it -v $(pwd):/workspace -w /workspace ghcr.io/inti-cmnb/kicad7_auto_full:1.6.4 /bin/bash
$ kicad-cli --version
$ kibot -vvv -w 9,10 -c present.kibot.yaml present

w045.tar.gz

[oliv3r]

Note, that this is for v1.6.4 so we may need a fix on 1.6.4 as well, or a new release (though I noticed some problems when running dev already).

[set-soft]

Why do you think this is a bug? This footprint has 4 "pads" that are just solder paste, not real pads.

[oliv3r]

Well it doesn't trigger in any of the other jobs. Only in present. Why not in the drc or update XML jobs? Kicad itself certainly doesn't complain.

And how to avoid the warning? The Design is not that uncommon, 4 smaller dabs of paste on a big pad. AFAIK its even best practice. So why is present complaining here?

On March 4, 2024 6:26:43 p.m. GMT+01:00, "Salvador E. Tropea" @.***> wrote:

Why do you think this is a bug? This footprint has 4 "pads" that are just solder paste, not real pads.

-- Reply to this email directly or view it on GitHub: https://github.com/INTI-CMNB/KiBot/issues/584#issuecomment-1977101904 You are receiving this because you authored the thread.

Message ID: @.***>

[set-soft]

Well it doesn't trigger in any of the other jobs. Only in present.

I already explained this. Not all tasks done for everything

Why not in the drc or update XML jobs? Kicad itself certainly doesn't complain.

You answered the question.

And how to avoid the warning?

Warning filters.

The Design is not that uncommon, 4 smaller dabs of paste on a big pad. AFAIK its even best practice.

Did you try converting the pads into just a rectangle? They are fake pads, not real pads. It looks like an abuse of the pad.

So why is present complaining here?

Is the variants code, not the present code.

And the problem is that these "pads", doesn't have a solder mask aperture. They are relying on the aperture made by real pads, which is really bad idea. Paste over the solder mask is plainly wrong, a warning here is good.

I'm modifying the warning to avoid it when the pad doesn't have a name. Assuming this is some bizarre addition.

[oliv3r]

Well it doesn't trigger in any of the other jobs. Only in present.

I already explained this. Not all tasks done for everything

I understand, but I try to run 'all tasks' as part of my linting, e.g. erc, drc, update_xml. So somehow, present triggers a task, that is not available anywhere else. I don't think it is required that I add present as a linting task surely :p

Why not in the drc or update XML jobs? Kicad itself certainly doesn't complain.

You answered the question.

Then I fail to see how I did :)

And how to avoid the warning?

Warning filters.

Well that depends on the bellow part, because I want to avoid using filters, as that basically 'disables' the feature, which I do want to keep.

The Design is not that uncommon, 4 smaller dabs of paste on a big pad. AFAIK its even best practice.

Did you try converting the pads into just a rectangle? They are fake pads, not real pads. It looks like an abuse of the pad.

This is from the official kicad library. So you are suggesting that there's a bug in the footprint? I can believe that, I'll look at this more carefully, but this is also where my kicad footprint design knowledge is stretching its limits :)

So why is present complaining here?

Is the variants code, not the present code.

Interesting, I haven't enabled anything variants related yet. But as I stated above, I'd like to be able to have this in my linting jobs, not having to rely on present, so how can I trigger this in drc or update_xml or is that not possible at all?

And the problem is that these "pads", doesn't have a solder mask aperture. They are relying on the aperture made by real pads, which is really bad idea. Paste over the solder mask is plainly wrong, a warning here is good.

I'm modifying the warning to avoid it when the pad doesn't have a name. Assuming this is some bizarre addition.

Well, lets first see if we can fix the bug in the footprint first, if possible. If its not possible, this would then indeed be a quirk needed.

Thank you so far! I'll get back to you, or if you manage to fix the footprint, that'll be great too, and then work on getting it merged upstream.

[set-soft]

Well it doesn't trigger in any of the other jobs. Only in present.

I already explained this. Not all tasks done for everything

I understand, but I try to run 'all tasks' as part of my linting, e.g. erc, drc, update_xml. So somehow, present triggers a task, that is not available anywhere else. I don't think it is required that I add present as a linting task surely :p

You can trigger it using any part of the variants mechanism.

Why not in the drc or update XML jobs? Kicad itself certainly doesn't complain.

You answered the question.

Then I fail to see how I did :)

"Because KiCad doesn't complain about it."

And how to avoid the warning?

Warning filters.

Well that depends on the bellow part, because I want to avoid using filters, as that basically 'disables' the feature, which I do want to keep.

You'll have to choose.

The Design is not that uncommon, 4 smaller dabs of paste on a big pad. AFAIK its even best practice.

Did you try converting the pads into just a rectangle? They are fake pads, not real pads. It looks like an abuse of the pad.

This is from the official kicad library. So you are suggesting that there's a bug in the footprint? I can believe that, I'll look at this more carefully, but this is also where my kicad footprint design knowledge is stretching its limits :)

I can't say this is a "bug", but surely an abuse of the pad entity. And surely a dangerous idea. This "pad" should also include a solder mask aperture to avoid putting solder paste over the solder mask. It doesn't happen now, but if the ghost pads are moved could happen.

So why is present complaining here?

Is the variants code, not the present code.

Interesting, I haven't enabled anything variants related yet. But as I stated above, I'd like to be able to have this in my linting jobs, not having to rely on present, so how can I trigger this in drc or update_xml or is that not possible at all?

You can't. You must generate some output.

And the problem is that these "pads", doesn't have a solder mask aperture. They are relying on the aperture made by real pads, which is really bad idea. Paste over the solder mask is plainly wrong, a warning here is good. I'm modifying the warning to avoid it when the pad doesn't have a name. Assuming this is some bizarre addition.

Well, lets first see if we can fix the bug in the footprint first, if possible. If its not possible, this would then indeed be a quirk needed.

Thank you so far! I'll get back to you, or if you manage to fix the footprint, that'll be great too, and then work on getting it merged upstream.

I'll see, I have no motivation to go and fix footprints.

[set-soft]

The above patch will avoid the W045 for pads without a name. Assuming they are not pads, just a hack (instead of using a geometry).

[oliv3r]

Well it doesn't trigger in any of the other jobs. Only in present.

I already explained this. Not all tasks done for everything

I understand, but I try to run 'all tasks' as part of my linting, e.g. erc, drc, update_xml. So somehow, present triggers a task, that is not available anywhere else. I don't think it is required that I add present as a linting task surely :p

You can trigger it using any part of the variants mechanism.

Curious, as I'm not using any variants yet, but I suppose it'll get triggerd regardless somehow. Strangely none of the other tasks do this, only present, so it's something that's default/hidden to me right now.

Why not in the drc or update XML jobs? Kicad itself certainly doesn't complain.

You answered the question.

Then I fail to see how I did :)

"Because KiCad doesn't complain about it."

And how to avoid the warning?

Warning filters.

Well that depends on the bellow part, because I want to avoid using filters, as that basically 'disables' the feature, which I do want to keep.

You'll have to choose.

The Design is not that uncommon, 4 smaller dabs of paste on a big pad. AFAIK its even best practice.

Did you try converting the pads into just a rectangle? They are fake pads, not real pads. It looks like an abuse of the pad.

This is from the official kicad library. So you are suggesting that there's a bug in the footprint? I can believe that, I'll look at this more carefully, but this is also where my kicad footprint design knowledge is stretching its limits :)

I can't say this is a "bug", but surely an abuse of the pad entity. And surely a dangerous idea. This "pad" should also include a solder mask aperture to avoid putting solder paste over the solder mask. It doesn't happen now, but if the ghost pads are moved could happen.

So is it fixable in a clean way? I'll go play with it right now to see what I can discover ...

So why is present complaining here?

Is the variants code, not the present code.

Interesting, I haven't enabled anything variants related yet. But as I stated above, I'd like to be able to have this in my linting jobs, not having to rely on present, so how can I trigger this in drc or update_xml or is that not possible at all?

You can't. You must generate some output.

So then the question is, what's the best 'dummy/fake' task to do trigger this? Obviously I'd want a linting job that would trigger this. Present is not the most ideal for this, as it requires a render job, a gerber job (though they can be faked of course as well, with external dummy outputs).

And the problem is that these "pads", doesn't have a solder mask aperture. They are relying on the aperture made by real pads, which is really bad idea. Paste over the solder mask is plainly wrong, a warning here is good. I'm modifying the warning to avoid it when the pad doesn't have a name. Assuming this is some bizarre addition.

Well, lets first see if we can fix the bug in the footprint first, if possible. If its not possible, this would then indeed be a quirk needed. Thank you so far! I'll get back to you, or if you manage to fix the footprint, that'll be great too, and then work on getting it merged upstream.

I'll see, I have no motivation to go and fix footprints.

Of course, I understand. I'll do it if I can :)

[oliv3r]

So I figured it out, and now understand the problem. I think you are right, there shouldn't be solder mask under solderpaste. I've done a script to add the mask layer (which removes it) in the upstream symbols, and fixed it in my local footprints.

Your patch sounds still reasonable, as I changed 551 footprints, so who knows how many 'false-positives' this would trigger.

https://gitlab.com/kicad/libraries/kicad-footprints/-/merge_requests/3551

The previous question remains, but coudl be split off into a feature request. How can we trigger W045 without any 'proper' task (if only as part of erc, drc or update_xml).

[oliv3r]

@set-soft I've run into a pickle that I feel like you might be able to point me into the right direction.

I've done the change, which I thought was sensible, removed (or checked) the F.Mask so that it would remove the soldermask under the paste. However, KiCad DRC now compalains about ERROR:(solder_mask_bridge) Front solder mask aperture bridges items with different nets; Severity: error. Which basically means either W045, or mask aperture bridges. Your fix of course avoids this, but that still begs the question, how can we properly fix this then? Did I miss-understand something in your suggested fix?

[set-soft]

Hi @oliv3r ! I don't know a clean mechanism to fix it. I think KiCad is just doing it in a dirty way. This is why I changed W045 to be generated only if the pad has a name, which I think is currently impossible because KiCad itself seems to be removing the name for such a pad. You can play with the pad attributes, I think they have an option to exclude them from the bridge check.

[oliv3r]

I agree, I think there may not be any other way, then your 'quirk' to check if the name is there or not.

I did play with the attributes and stuff. So for now, your fix is all I got :)