I think that easiest assembly disallows having via-in-pad for SMT pads. I found where I had placed one or two vias in pads, and it seems that DRC did not catch them.
Am I missing something in 5.99?
I think that easiest assembly disallows having via-in-pad for SMT pads. I found where I had placed one or two vias in pads, and it seems that DRC did not catch them.
Am I missing something in 5.99?
IIRC you can write a custom rule for that in 5.99.
I don’t think people normally want that, but I would expect it to be possible to add in the “Custom Rules”.
Thanks. But…I am looking at how this is done. Too much like programming; not something I want to attempt right now.
Do you mean that people normally want via in pad? I think that is an added cost type of assembly. I am surprised because I think via in pad is usually undesirable and software help in finding it would be a good thing to have.
Yeah, well. Of course it depends, but I mean; vias in pads are often or sometimes used as thermal vias.
I, too, think that normally people don’t want vias in pads. They mess up assembly in SMD pads unless they are microvias or plugged/plated, put there on purpose. See Shoves vias into pads : KiCad shoves vias to pads accidentally, so preventing it is a good thing.
https://docs.kicad.org/master/en/pcbnew/pcbnew.html#custom_design_rules says:
clearance
Checks the clearance between copper objects of different nets. KiCad’s design rule system does not permit constraining clearance between objects on the same net at this time.
So it’s not possible. I’m disappointed.
You CAN do it, but there is a problem. Much of the solder gets pulled down into the Via hole. The component may shift or tombstone.
I recommend against it.
Yes the issue is that KiCad DRC does not help me to spot any vias-in-pads that I have missed. The last board I supervised (a designer did it with Altium) was dense and purposefully done with via-in-pad, and resistors and capacitors down to 0201 size. I think the vias were filled. I find 0402s difficult to work with and would not attempt 0201s.
I also think there should be a DRC check for “VIA inside pad”, defaulted to severity “Warning”. In order to try this out this, now looking at v5.99 File -> Board setup -> Design rules -> Custom rules -> Syntax help
To be honest, I have no idea if this is possible, cannot grasp the these custom rules, it seems so unnatural. There is no such simple to write like sentence Is "VIA" && IsInside "Pad"
. It is the first time I have opened custom rule section, so what do I know.
Rule should be like this (?):
(version 1)
(rule Via_inside_pad
(constraint disallow )
(condition "A.Type == 'Pad' && B.Type == 'Via'"))
also:
(rule "Pad to VIA"
(constraint clearance (min 0.2mm))
(condition "A.Type =='Pad' && B.Type =='VIA'"))
Both these does not produce any result.
Altium has this:
https://www.altium.com/documentation/altium-designer/pcb-dlg-viasundersmdrule-framevias-under-smd-ad
Like I said, it doesn’t seem to be possible.
This rule is nonsensical.
This is (almost) how it should look like. But this adds the constraint between items of different nets. I quoted the documentation which tells that objects of the same net can’t be checked. So adding “A.Net == B.Net” doesn’t work, unfortunately. Maybe @JeffYoung or someone else can tell why this isn’t possible.
The root of the problem is that if we checked objects of the same net then we’d throw DRC errors for every bend in a track (as it’s actually two different track segments).
If you had a rule that also had other discriminators (such as pad & via) then this could be OK, but the present implementation gets around the issue by not running rules on things of the same net.
Could it be possible to keep the current behavior but if the “same net” rule is explicitely defined, then it would be used, and the user would be responsible for the result? Track/track check wouldn’t work but via/via, pad/via etc. would?
The issue there is that we would have to run the rule resolver for all items to find out whether or not there was an explicit same-net rule, and the rule resolver is compute-intensive (ie: slow).
There are two things that this could mean, and it’s important to understand the difference between them.
The reason you might want this is if you need to break out the signals of a very fine pitch BGA, but don’t have enough space to use a dogbone to get from the BGA pad to a via to an inner layer. This technique allows you to place the escape vias right on top of the BGA pads. You need a capped surface if you want to do this so that the BGA ball doesn’t wick into the via during reflow.
Dogbone: https://i.stack.imgur.com/yy0Sq.jpg
Filled via-in-pad (on the right): https://pcbsfactory.com/app/uploads/2020/08/6370943414577400009215897.png
This is not ever referred to as “via-in-pad” and I’ve never seen anyone use a design rule to catch this.
In reality, it’s a guideline that you sometimes need to break, and doing so is usually fine. For example, you often want uncovered vias in the central exposed pad on a QFP footprint to wick away excess solder and prevent it from shorting to the pins on the periphery. Even on 0402 passives, putting a small via halfway across the pad to save some space is usually okay.
It’s more “something to be aware of” than “something to religiously prevent.”
I’ve also never seen an assembly house automatically flag designs because of this, as this would result in way too many false positives. They’ll usually try to assemble it, and will only contact you if something is so bad that it’s causing yield issues.
Annoyingly, if you actually do want a board to be manufactured with (filled and capped) via-in-pad, there isn’t really a standard way to specify which vias you want filled. I’ve seen designers specify “fill and cap all vias smaller than [diameter]” in a comment field, or provide an additional gerber or drill file with the via locations. I think Gerber X2 may be filling in (ha) some of the gaps here, but I haven’t played with it enough to understand what it can and can’t do yet.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.