← Back to team overview

kicad-developers team mailing list archive

Re: Castellated edge support in v5.99

 

Le 23/07/2020 à 14:19, Jon Evans a écrit :
> Local rules will be done with zones: you can give a name to a copper or
> keepout zone and use it to define a rule. If you want a zone that is
> only used to define a rule and has no other effect, use a keepout that
> has no restrictions set.
> 
> Regarding castellations, I think we should study an example case and see
> if it can be allowed easily with the current set of rules planned, and
> if not, add whatever is needed to make it so. I agree it's common enough
> that it should be not too hard to make castellations that pass DRC. 
> 
> -Jon
> 

There is (since 6 months) some pad fabrication properties (see pad
properties dialog), only enabled by the advanced config.

I just enabled this option (removed from the advanced config option.)

Castellated pad is one of these abrication properties.

These properties are stored in Gerber files, so they need to be a pad
property.

Currently, DRC does not use these properties (in fact only Castellated
pad can be used in DRC).

> 
> On Thu, Jul 23, 2020, 03:24 Eeli Kaikkonen <eeli.kaikkonen@xxxxxxxxx
> <mailto:eeli.kaikkonen@xxxxxxxxx>> wrote:
> 
>     KiCad doesn't have any specific support for castellations, and doesn't
>     need anything special because it's basically PTH pad on the edge. It
>     works so-and-so in 5.1: it doesn't complain about pad copper which is
>     too close to the edge, and it's even possible to add SMD pads to the
>     footprint so that it's possible to route without DRC problems. (See
>     https://forum.kicad.info/t/how-to-design-castellated-pins/23945 .)
> 
>     However, this doesn't work so well in 5.99. DRC check handles pads
>     like other copper and the only way to turn off errors is to ignore
>     "Board edge clearance violations" altogether.
> 
>     We could of course have some specific support for castellation, like
>     marking footprints as castellation and then allowing copper and
>     routing there. But I doubt this is what the team wants because it's a
>     special case which can be solved otherwise (like local neckdown for
>     tight IC's).
> 
>     It' not clear to me how the local rules is going to be implemented.
>     Will there be some kind of graphical polygon where I can define the
>     rules with the DRC Rules editor? That would work for me if it's made
>     easy enough.
> 
>     I thought about being able to add certain kind of predefined rules
>     without a need to write them. For example
>     * Add a box around the area
>     * Open the context menu on the box
>     * It reveals menu item "Add Rules"
>     * -> "Castellation"
> 
>     Then it would allow the pads on the edge, and also routing and zone
>     filling fully without caring about the edge line inside the pad
>     boundaries (the rule system must of course support this!).
> 
>     On the other hand, castellation is pretty much a de facto standard and
>     it wouldn't hurt to support it as a special case. Even allowing THT
>     pads on an edge where the hole is on the edge, too, would be enough to
>     allow the same workflow than in 5.1.
> 
>     Splitting board edge violations into two, pad and other, would also
>     work. I never want to violate with traces, but sometimes in a tight
>     design I have placed pads very near to the edge and trusted that the
>     manufacturer removes copper if they want and there's still enough room
>     for the component. This would also allow non-castellated edge plating
>     with a footprint (which must otherwise be handled with local rules,
>     like castellation).
> 
>     Finally, being able to select a bunch of violation markers - for
>     example for one footprint - and excluding them permanently could also
>     work.
> 
>     Eeli Kaikkonen
> 
>     _______________________________________________
>     Mailing list: https://launchpad.net/~kicad-developers
>     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     Unsubscribe : https://launchpad.net/~kicad-developers
>     More help   : https://help.launchpad.net/ListHelp
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


-- 
Jean-Pierre CHARRAS


Follow ups

References