Issues with converting gerber to kicad board file

Bug #1748529 reported by Nick Østergaard
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
KiCad
Won't Fix
Undecided
Unassigned

Bug Description

I just tried to open a project originally from Altium. I tried to open the gerbers in gerbview. Looks ok. But when I try to export the GBL layer to F.Cu it looks like it is converted in a strange way. Big circular pads appear and it looks like roundrect pads from the gerbers are misinterpreted here.

There are various other issues. Like the board does not show a board body in the 3D viewer. This bug focuses on the pads that arebig round ones and missing at the QFN package.

Steps to reproduce:
1. Open gerbview
2. Load bluebox-micro-1B.GTL
3. Export to F.Cu to pcbnew
4. Open in pcbnew and you should see something similar to the screenshot that I have attached

I attached the bluebox-micro-1B.GTL for convenience. Gerbers originally from:
https://github.com/satlab/bluebox/blob/master/hardware/bluebox_micro_1b/bbmicro-1b-usb-stick-160404.zip

Application: pcbnew
Version: (2018-02-09 revision dba198e57)-master, release build
Libraries:
    wxWidgets 3.0.3
    libcurl/7.57.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) libssh2/1.8.0 nghttp2/1.29.0
Platform: Linux 4.14.13-1-ARCH x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.66.0
    Curl: 7.57.0
    Compiler: GCC 7.2.1 with C++ ABI 1011

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

Revision history for this message
Nick Østergaard (nickoe) wrote :
Revision history for this message
Nick Østergaard (nickoe) wrote :
Revision history for this message
jean-pierre charras (jp-charras) wrote :

I am thinking you are expecting too much from Gerber to Pcbnew converter:

* It can only convert drawings to tracks and vias on copper layers, because Gerber files (expect recent X2 files) do not contain any info about footprints.
* Anyway, Gerber files do not contain footprint descriptions.

Therefore, regardless to actual shapes (that do not exist in Pcbnew) any flashed item on copper layers is a round via.

You can expect only have tracks, not even zones.

Changed in kicad:
status: New → Won't Fix
Revision history for this message
Wayne Stambaugh (stambaughw) wrote :

@JP, I understand that there is no way to create footprint objects and net connections from a gerber import but would it be possible to at least get the geometry correct? I think this is what Nick was looking for.

Revision history for this message
jean-pierre charras (jp-charras) wrote :

Unfortunately, there is no easy way to create a correct geometry of flashed items on copper layers.

To do that, new items specific to Gerber export should be created.
Any flashed shape that is not a circle can be displayed only as a rectangle or a polygon.

Pcbnew does not support pads not belonging a footprint.

So to create a correct geometry, we need new objects ( vias with specific shape or "orphan" pads. )

This is not a basic change.

Especially if we take in account many of these shapes must be easily removed (cleaned) after footprints are added to the board converted from gerber files to recreate a usual board with footprints.

Revision history for this message
Nick Østergaard (nickoe) wrote :

Ok, so the issue is that we can not add pads with no footprint container in pcbnew. But it should be possible to add them as individual footprints or as a single footprint go get a more correct import when inspecting copper. Is this correct, and are tjhere any objections to try to inplement that?

My specific use case was just to get the board outline, although I would have liked to get accurate pads for the connectors it was not critical for me. It just means that I sort of need to eyeball the connectors to be able to make a mechanical design around it.

Revision history for this message
Wayne Stambaugh (stambaughw) wrote : Re: [Bug 1748529] Re: Issues with converting gerber to kicad board file

This seems reasonable albeit a bit unwieldy. I would at least allow
pads to be shown correctly even if they don't represent actual footprints.

On 2/12/2018 7:39 AM, Nick Østergaard wrote:
> Ok, so the issue is that we can not add pads with no footprint container
> in pcbnew. But it should be possible to add them as individual
> footprints or as a single footprint go get a more correct import when
> inspecting copper. Is this correct, and are tjhere any objections to try
> to inplement that?
>
> My specific use case was just to get the board outline, although I would
> have liked to get accurate pads for the connectors it was not critical
> for me. It just means that I sort of need to eyeball the connectors to
> be able to make a mechanical design around it.
>

Revision history for this message
PCB Wiz (1-pcb-wiz) wrote :

See also https://forum.kicad.info/t/pads-changed-to-vias-on-gerber-to-pcb-export/11187/11
From above :
WS>This seems reasonable albeit a bit unwieldy. I would at least allow
WS>pads to be shown correctly even if they don't represent actual footprints.

I agree with this, and here is a link to an earlier report I filed around Gerb import.
https://bugs.launchpad.net/kicad/+bug/1646221

I think Gerb Export should try to do
* correct SMD pads (no drill, shape right. Shape can be line, or pad)
* correct drill size (see below) Of course, presumes we have a loaded/aligned drill file in GerbView
If shapes & drills are ok, someone can do minor edits, and actually fab the board

JP>Pcbnew does not support pads not belonging a footprint.

I noticed a file imported from PCAD the other day had what appeared to be ‘free PADS’, and testing I find this is the minimal 'free pad' import format : (names G_I and jjx are testing, can be empty)

  (module "G_V" (layer F.Cu)
    (at 243.375 32.395)
    (pad jjx thru_hole rect (at 0 0) (size 0.8636 1.27) (drill 0.666) (layers *.Cu *.Mask))
  )
and after loading, that saves as this

  (module G_V (layer F.Cu) (tedit 5B28113F) (tstamp 0)
    (at 243.375 32.395)
    (fp_text reference "" (at 0 0) (layer F.SilkS)
      (effects (font (size 1.27 1.27) (thickness 0.15)))
    )
    (fp_text value "" (at 0 0) (layer F.SilkS)
      (effects (font (size 1.27 1.27) (thickness 0.15)))
    )
    (pad jjx thru_hole rect (at 0 0) (size 0.8636 1.27) (drill 0.666) (layers *.Cu *.Mask))
  )

I’d suggest GerberView export tag such pads as G_V, but avoid a PinName, so they can be found in an editor later.

Revision history for this message
PCB Wiz (1-pcb-wiz) wrote :

 Thinking a little more on this, it may be easier to not try to merge pads and drill, as I suspect offset ovals etc might fail.

 Simpler could be a pass per layer, so SMDs (actually all pads) on top export as

  (module "G_VF" (layer F.Cu)
    (at 243.375 32.395)
    (pad smd rect (at 0 0) (size 0.8636 1.27) (drill 0) (layers F.Cu F.Mask))
  )

 SMDs on bottom export as

  (module "G_VB" (layer B.Cu)
    (at 243.375 32.395)
    (pad smd rect (at 0 0) (size 0.8636 1.27) (drill 0) (layers B.Cu B.Mask))
  )

and a drilled hole is a separate item

  (module "G_VD" (layer F.Cu)
    (at 243.375 32.395)
    (pad thru_hole circle (at 0 0) (size 0.666 0.666) (drill 0.666) (layers F.Cu B.Cu))
  )

That would overlap 3 entities in a thru hole item, but would support differing sizes/shapes Top/Bottom
From the above gerber example, it looks like flashed item to mask is an ok rule ?
A more verbose export could be to also export mask layers separately, for a final stack of 5.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.