Copper zone distance to Edge.Cuts

Bug #1797787 reported by Olivier on 2018-10-14
34
This bug affects 8 people
Affects Status Importance Assigned to Milestone
KiCad
Medium
Jeff Young

Bug Description

Hello,

In most PCB fabrication houses, the interpretation of the lines on the mechanical layer Edge.cuts is that the _middle_ of the lines indicates the exact position of the mechanical cut. In other words, the width of the line has _no significance_.

However, when filling a copper zone, KiCAD uses the clearance value with respect to the edge of the line instead of the middle of the line. I think this is bad practice because the width of the line should have no significance.

Moreover, the designer may need to specify more margin with respect to the mechanical edge than with respect to the copper patterns, because they are technologically two different things. Therefore, it is reasonable to distinguish the margin with the PCB edge and the clearance with the copper patterns.

Request: In the property dialog of the copper zone filling, I suggest to add a supplementary property named "Margin to Edge.Cuts". This margin would be interpreted with respect to the middle of the line (not the edge of the line).

Olivier

---
Note: In bug 1516244, Nicholas said he changes the line-width of Edge.Cuts in order to force zones from edges to the distance he wants. It may work fine, but it looks more like a software trick than really taking into account the technological difference between copper patterns and board edges. Also, some fabrication houses sometimes advise for a preferred line width for the Edge.Cuts layer, and

Reference example:
https://www.eurocircuits.com/pcb-design-guidelines/#mechanicallayer
"Outlines are best shown using a small line – e.g. 0.50mm (20mil) wide – where the center of the line represents the exact board outline."

---
Application: kicad
Version: 5.0.0+dfsg1-2, release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.60.0 OpenSSL/1.1.0e zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) libssh2/1.7.0 nghttp2/1.27.0 librtmp/2.3
Platform: Linux 4.14.0-3-amd64 x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.62.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.61.0
    Compiler: GCC 8.2.0 with C++ ABI 1013

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=OFF
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=OFF

Seppe Stas (seppestas) wrote :

A lot of board vendors have a different required margin from the board edge for internal and external layers (see e.g item 6 in the [copper layer design rules of Eurocircuit](https://www.eurocircuits.com/pcb-design-guidelines/#copperlayers))

I think it would be very handy to have design rules to specify this and have DRC check whether tracks and zones keep enough distance. Zones could use this information to have a different size per layer.

And yes, the margin for copper zones should apply to the center of edge cuts, not the side.

Note also that currently tracks currently act in a similar way. When using the interactive router, tracks keep their clearance + the edge cut thickness distance from the center of the edge cut. However, when increasing the thickness of the edge cut, DRC does not show any form of error.

Since this type design rule error is only spotted by the pre-production analysis on Eurocircuits, not the automated PCB checker, it can cost a lot of time.

Jeff Young (jeyjey) on 2018-10-16
Changed in kicad:
status: New → Triaged
importance: Undecided → Medium
milestone: none → 5.1.0
Jeff Young (jeyjey) on 2018-11-14
Changed in kicad:
assignee: nobody → Jeff Young (jeyjey)
status: Triaged → In Progress
KiCad Janitor (kicad-janitor) wrote :

Fixed in revision bcc8c642562ee9013e5b76a696e6c3faa6b907ef
https://git.launchpad.net/kicad/patch/?id=bcc8c642562ee9013e5b76a696e6c3faa6b907ef

Changed in kicad:
status: In Progress → Fix Committed
Seth Hillbrand (sethh) wrote :

@Jeff- This disabled the only way to set the clearance to the board edge.

Can we revert this until 6 when we add a setting for specific board edge clearance?

Jeff Young (jeyjey) wrote :

Well, it comes down to bug vs. missing-feature work-around. I'm sure you'd find people to come down on either side of the argument.

But I'm not one of them. The board house I use doesn't care about the bug, and I don't miss the missing feature. So I'm happy either way. ;)

Seth Hillbrand (sethh) wrote :

The problem is that people have made boards in v5 using this work-around. Removing it changes the board output and may invalidate existing designs as copper now extends closer to the edge.

I agree with Seth: this change can create issues with existing boards.
The best way is to revert it.

The root issue is the fact the margin layer is not yet used in V5.
I am expecting it will be activated in V6, because its purpose is to define clearance margins, visible and easy to edit and combine with items defined inside a footprint.

Basically using Egde_Cuts both as board outlines (with the constraint to define only closed shapes) and to define a clearance margin is a broken feature.

The best way is to use margin layer to define clearance margins (and not necessary closed shapes, because castellated pads are incompatible with a closed shape) and Egde_Cuts only for board outlines .

We have an non-written policy about not breaking (aka changing without
the users knowledge) existing boards so I'm going to side with JP on
this one. We should wait and implement this in v6 as a new feature.

Cheers,

Wayne

On 12/8/18 5:33 AM, jean-pierre charras wrote:
> I agree with Seth: this change can create issues with existing boards.
> The best way is to revert it.
>
> The root issue is the fact the margin layer is not yet used in V5.
> I am expecting it will be activated in V6, because its purpose is to define clearance margins, visible and easy to edit and combine with items defined inside a footprint.
>
> Basically using Egde_Cuts both as board outlines (with the constraint to
> define only closed shapes) and to define a clearance margin is a broken
> feature.
>
> The best way is to use margin layer to define clearance margins (and not
> necessary closed shapes, because castellated pads are incompatible with
> a closed shape) and Egde_Cuts only for board outlines .
>

Jeff Young (jeyjey) wrote :

I don’t think it’s quite correct to say we’re breaking existing boards. The user has to do something to trigger a zone re-fill to get the change.

That being said, I don’t have a problem with deferring this bug fix.

Wayne Stambaugh (stambaughw) wrote :

@Feff, this case is subtle. I use this trick as well to ensure the board edge clearance is greater than the zone fill clearance. I have a few boards where I need a low zone fill clearance (<= 10 mils) to ensure I end up with a continuous fill. Doing this puts the zone fill dangerous close to the board edge so the board edge line thickness trick ensures that I don't end up with exposed copper. I know this is not ideal and that the bug submitter is correct that the clearance should be determined from the center of the board outline layer line. Unfortunately we have users who have used this trick so changing it would change the board edge clearance should they ever need to revise their board layout that requires a zone refill. We need to create a new board edge clearance feature to implement this in a way that wont bite someone who isn't expecting their board edge clearance to change. This should be part of our new constraint management system.

Jeff Young (jeyjey) on 2018-12-08
Changed in kicad:
status: Fix Committed → Triaged
assignee: Jeff Young (jeyjey) → nobody
milestone: 5.1.0 → 6.0.0-rc1
Jeff Young (jeyjey) on 2019-04-05
Changed in kicad:
assignee: nobody → Jeff Young (jeyjey)
KiCad Janitor (kicad-janitor) wrote :

Fixed in revision 1ae47b6069e54da89fa43896ab25a18f68e985b3
https://git.launchpad.net/kicad/patch/?id=1ae47b6069e54da89fa43896ab25a18f68e985b3

Changed in kicad:
status: Triaged → Fix Committed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers