Gerber file not properly generated for Edge.Cuts layer

[Fernando Molina]

Application: kicad
Version: (5.0.2)-1, release build
Libraries:
    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:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON

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.

[jean-pierre charras (jp-charras)]

Hi Fernando,
The Gerber files are correctly created.
But:
- 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.

[Seth Hillbrand (sethh)]

@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)]

@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)]

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)]

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)]

@sethh could it be you mean this report? https://bugs.launchpad.net/kicad/+bug/1661705

[Bob Cousins (bobcousins42)]

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)]

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)]

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.

[jean-pierre charras (jp-charras)]

@Seth
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)

Thanks.

[KiCad Janitor (kicad-janitor)]

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

[Seth Hillbrand (sethh)]

@JP-

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.

[jean-pierre charras (jp-charras)]

@Seth,

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)]

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)]

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)]

@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)]

@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.