Copper crash when open EasyEDA v5.9 Gerber file

Issue #268 resolved
luodesong created an issue

EasyEDA.com has release a new version v5.9, and this version use a new copper pour method, the copper will be combined piece by piece to be a whole copper, then the Gerber looks well at Gerbv, and can be manufacture too, but it can't read correctly by FlatCAM. The latest FlatCAM doesn't work too. such as: Snipaste_2019-01-24_10-09-19.png

Snipaste_2019-01-24_10-09-02.png

some piece of copper area will disappear.

any chance to resolve this issue?

example: example

thank you

Comments (3)

  1. Marius Stanciu

    Hi @luodesong ,

    I have analyzed the issue and the problem is that EasyEDA generates the Gerber regions in a way that can create (in certain situations) problems for FlatCAM Gerber parser.

    Short answer: there is no way I can see to fix this in FlatCAM, EasyEDA generates non-compatible code.

    Long answer: Basically, EasyEDA accomplished it's target in splitting the copper pour by implementing multiple Gerber regions for the copper pour. Each region starts with a G36 command and ends with a G37 command. FlatCAM will interpret all the points in the region by creating a Shapely Polygon which is then plotted on the canvas.

    Now, in the case of the areas that are missing in the picture of the Gerber you posted, what is happening is that the FlatCAM Gerber parser can't create polygons out of those Gerber regions.

    Why? Because the Gerber region coordinates violates a rule that Shapely package (used in FlatCAM) ask to be obeyed when creating a Polygon:

    Rings of a valid Polygon may not cross each other, but may touch at a single point only.
    

    As an example let's look at the Gerber code that creates the region that is missing and it is marked in picture 1.jpg.

    1.JPG

    The code is this (I removed from the original file all other code leaving only the header, apertures, footer and the region in question).

    %FSLAX33Y33*%
    %MOMM*%
    G90*
    G71D02*
    
    %ADD10C,0.254000*%
    %ADD11C,0.355600*%
    %ADD12C,0.699999*%
    %ADD13R,1.469898X1.160018*%
    %ADD14C,1.651000*%
    %ADD15R,1.574800X1.574800*%
    %ADD16C,1.574800*%
    
    G36*
    G01X18847Y9195D02*
    G01X18339Y9703D01*
    G01X18339Y9703D01*
    G01X18334Y9708D01*
    G01X18328Y9714D01*
    G01X18323Y9719D01*
    G01X18317Y9724D01*
    G01X18311Y9729D01*
    G01X18306Y9733D01*
    G01X18300Y9738D01*
    G01X18294Y9743D01*
    G01X18288Y9747D01*
    G01X18281Y9752D01*
    G01X18275Y9756D01*
    G01X18269Y9760D01*
    G01X18263Y9764D01*
    G01X18256Y9768D01*
    G01X18250Y9772D01*
    G01X18243Y9776D01*
    G01X18236Y9779D01*
    G01X18230Y9783D01*
    G01X18223Y9786D01*
    G01X18216Y9789D01*
    G01X18209Y9792D01*
    G01X18202Y9795D01*
    G01X18195Y9798D01*
    G01X18188Y9801D01*
    G01X18181Y9804D01*
    G01X18174Y9806D01*
    G01X18167Y9809D01*
    G01X18160Y9811D01*
    G01X18153Y9813D01*
    G01X18145Y9815D01*
    G01X18138Y9817D01*
    G01X18131Y9819D01*
    G01X18123Y9820D01*
    G01X18116Y9822D01*
    G01X18109Y9823D01*
    G01X18101Y9824D01*
    G01X18094Y9826D01*
    G01X18086Y9827D01*
    G01X18079Y9827D01*
    G01X18071Y9828D01*
    G01X18064Y9829D01*
    G01X18056Y9829D01*
    G01X18049Y9830D01*
    G01X18041Y9830D01*
    G01X18034Y9830D01*
    G01X19151Y9830D01*
    G01X19151Y9195D01*
    G01X18847Y9195D01*
    G37*
    
    M00*
    M02*
    

    The problem stay in this section (last part):

    G01X18049Y9830D01*
    G01X18041Y9830D01*
    G01X18034Y9830D01*
    G01X19151Y9830D01*
    G01X19151Y9195D01*
    G01X18847Y9195D01*
    G37*
    

    First there is a succession of linear moves to the left at the same height (3 moves to the left). Then, and here is the violation, there is a sharp reversal of direction, a linear move at the same height but this time to the right:

    G01X19151Y9830D01*
    

    which violates the rule because there is now an overlap in multiple points which Shapely does not allow. FlatCAM does try to solve the issue by trying to make a buffer(0) but this one fails also creating an empty polygon.

    If I change the above line very little, a decimal in the height - Y (therefore there is no longer overlap) like this (see the Y parameter):

    G01X19151Y9831D01*
    

    then the region is parsed correctly like in the picture: 2.JPG

    The only solution is for the EasyEDA engineers to make sure that the generated regions have no overlapped sections.

  2. luodesong reporter

    Hi @Marius Stanciu Thanks for reply. I will tell EasyEDA to fix this issue. Thank you very much :)

  3. Log in to comment