Gerber file not properly generated for Edge.Cuts layer

Bug #1815642 reported by Fernando Molina on 2019-02-12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Seth Hillbrand

Bug Description

Application: kicad
Version: (5.0.2)-1, release build
    wxWidgets 3.0.4
    libcurl/7.61.1 OpenSSL/1.1.1 (WinSSL) zlib/1.2.11 brotli/1.0.6 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) nghttp2/1.34.0
Platform: Windows 7 (build 7601, Service Pack 1), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8)
    Boost: 1.68.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.61.1
    Compiler: GCC 8.2.0 with C++ ABI 1013

Build settings:

A project is attached as a zip files. Steps:
1. generate Gerber files.
2. Inspect PlacaPoteCentral2-Edge.Cuts.gbr (also, the "traza" folder holds the one I generated). It shows a different shape form what can be seen in pcbnew. Also, it si reported as empty by manufacturer.

Fernando Molina (fvmolina) wrote :
Seth Hillbrand (sethh) on 2019-02-12
Changed in kicad:
importance: Undecided → High
milestone: none → 5.1.0
status: New → Triaged

Hi Fernando,
The Gerber files are correctly created.
- The board has an issue in edge cuts layer.
Please, delete the Edge.cut layer using Edit/Global Deletions/Board outlines
and redraw the outlines.
- The Gerber edge cut is not empty. Your manufacturer is wrong.

Changed in kicad:
importance: High → Undecided
Seth Hillbrand (sethh) wrote :

@JP- The issue I saw here was the we don't show the line that overflows and there is no good way for a user to know that they should remove it. The method you mention is the only way but that requires knowing that there is a bad line to begin with.

Maybe we limit points on load to the board limits?

Fernando Molina (fvmolina) wrote :

@JP. Thank you, I can do that. But as Seth says, there should be an indication that something is wrong. I saw a strange long line in Gerber View but in pcbnew it looked OK.

Wayne Stambaugh (stambaughw) wrote :

Tread very carefully here. Chances are you cannot define "that something is wrong" accurately enough to make any automatic changes without breaking someone else's "I meant to do that". There are a lot of users who use pcbnew to panelize multiple boards so checking for extreme edge cuts in any meaningful way may prove to be difficult. Given that this is a user error, I would be hesitant to make any changes for 5.1. I would accept a warning but automatically "fixing" a users design is a slippery slope.

Seth Hillbrand (sethh) wrote :

This was a case of "can't be represented by int32". In this case, the item was present but could not be seen or selected and created invalid output. I could have sworn this was discussed previously but can't find the bug report. I thought we had decided to treat invalid data like this in the same way as invalid layers, i.e. drop + warn.

Rene Poeschl (poeschlr) wrote :

@sethh could it be you mean this report?

Bob Cousins (bobcousins42) wrote :

We have seen this several times on the forum where users end up with invalid values in PCB items. It is not the user putting in invalid values. Somehow KiCad puts in the invalid values, and the user is left with a confusing bug to tidy up.

Wayne Stambaugh (stambaughw) wrote :

We should fix the bug that allows objects to drawn outside the 32 bit integer limit. If we allowed these objects to drawn and saved to the file than we will have to provide some way to clean up our mess.

Seth Hillbrand (sethh) wrote :

Here is a proposed patch for this issue. Values that cannot be represented as an integer are clamped to a visible limit of ±INT_MAX/SQRT(2) (~1.5 meters). At a bare minimum, this allows the user to interact with the item and our DRC will point to it.

In this patch, only values INT_MAX and INT_MIN are clamped.
But an item at INT_MAX-1 is not clamped to 1.5m and is invisible because it is outside the draw area.

I am thinking any coordinate > 1.5m or < -1.5m should be clamped.
(A limit = INT_MAX/2 -1 could be better)


KiCad Janitor (kicad-janitor) wrote :

Fixed in revision 2c61b7d7d6501094cf15e77b21cc461f343ef251

Changed in kicad:
status: Triaged → Fix Committed
assignee: nobody → Seth Hillbrand (sethh)
Seth Hillbrand (sethh) wrote :


See the associated commit and let me know if you have any concerns. This clamps to the same value used for comparison. I think INT_MAX/2 -1 might be too extreme as that would put us at 1.07m.


I proposed INT_MAX/2 - 1 because this limit ensure any item will be drawn.
I agree it is a rather small value.

However I proposed this value because we are using a BOX2I to handle bounding boxes.
It imply the origin and end coordinates are clamped to INT_MAX/2 - 1/2 - 1.
Otherwise the bounding box height and width (that need integer values, not unsigned values) can overflow in some cases.

This is easy to test:
- the measure tool is not displayed if its bounding box is too big (try to used is with a lenght > INT_MAX.
- In fact any item having a too big bounding box is not displayed (for instance a line from X < -INT_MAX/2 to X > INT_MAX/2)

Fixing this draw issue is not so obvious.
Note also the clamp should be applied to panning and during creating a item.

Seth Hillbrand (sethh) wrote :

Ah, right. Thanks. I had only been looking at the rtree.

Can you have a look at commit 7b60c856e9? This fixes the two examples you gave. It allows all items to be displayed regardless of size.

Fixing the limits issue will be more difficult (I think), but at least now users can fix their mistakes if they accidentally set a line to start at -3000mm.

Wayne Stambaugh (stambaughw) wrote :

Rather than clamping the drawing limits by some arbitrary limit, why not just use the bounding box to determine if an object can be drawn? Vertical and horizontal lines could be drawn all the way out to the numerical limits of a 32 bit integer and still produce a valid output.

Seth Hillbrand (sethh) wrote :

@Wayne- The immediate concern I would have is that this isn't the same limitation we use for plotting. Everything there is an absolute offset, so I think it might be safer to use that for our limitation until we remove the limitation in our fabrication outputs.

Wayne Stambaugh (stambaughw) wrote :

@Seth, that's fine but the limitation still feels somewhat arbitrary unless I'm missing something here. We should probably take a closer look at this during v6.

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

Other bug subscribers