Pads changed to Vias on Gerber to PCB export

I have the Gerbers for a rather small legacy PCB design that I am trying to import into Kicad. Opening in Grebview then exporting to a Pcbnew .kicad_pcb file works, however all the pads are changed to Vias. I couldn’t find this as a know issue right off, is there a setting or process I am missing?

I have tried in 5.0.0 RC2 on macos and windows 10.

These were SMD pads?

Sorry, yes, these were all SMD pads. They are shown as rectangles in Gerbview.

Gerber file format does not have knowledge of footprints as far as I know.
So all your pads are probably single pad components.

Some time ago (2016?) I did some experiments with custom pads / components in PCBnew. From what I can remember it was pretty easy to replace pads (components) with different pads (components) in PCBnew.

Another option is to direcly edit (search / replace) the pad sizes with an text editor.
The file format of your “project.kicad_pcb” file is described in:
https://kicad.org/help/file-formats/

The Gerber files consist of descriptions of the copper as described to an optical plotter and drilling files. A SMD pad should not have a drill hole, so if there is a via, you have a bug.
What is the exact KiCad version, there is no such thing really as “RC2”?

Normally I believe there are also no holes in Through Hole pads in the gerber file, and the holes are only in the drill (target) file. (At least in the “old” gerber file format).

Could it be that it just puts a hole in all pads? (Which surely looks like a bug indeed.).

Here is my version info, it is a nightly from a month or so ago:

Application: pcbnew
Version: (5.0.0-rc2-dev-299-gbfe9eff), release build
Libraries:
wxWidgets 3.0.4
libcurl/7.54.0 LibreSSL/2.0.20 zlib/1.2.11 nghttp2/1.24.0
Platform: Mac OS X (Darwin 17.6.0 x86_64), 64 bit, Little endian, wxMac
Build Info:
wxWidgets: 3.0.4 (UTF-8,STL containers,compatible with 2.8)
Boost: 1.61.0
Curl: 7.43.0
Compiler: Clang 7.3.0 with C++ ABI 1002

Build settings:
USE_WX_GRAPHICS_CONTEXT=ON
USE_WX_OVERLAY=ON
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_SPICE=ON

Also, I found this may be a bug that has been around for a while:

This comes up frequently.

It’s a limitation of KiCad, JP explains here https://bugs.launchpad.net/kicad/+bug/1748529. Because pcbnew has no support for a standalone pad, pads must belong to a footprint. So then KiCad must try to automagically reverse match pads to footprints, or maybe create one big footprint holding all the pads. Either way probably not good results.

1 Like

When I tried the last time, not long ago with a nightly build, it didn’t export pads at all. Either way of exporting would have worked for me. I was disappointed.

Ah, read the bug feedback and that makes sense. Thanks @bobc

Yes, there are limitations with Gerber import, however it could be improved.

I noticed a file imported from PCAD the other day had what appeared to be ‘free PADS’, and this is the minimal import format

  (module "G_I" (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 that saves as this

  (module G_I (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.667) (layers *.Cu *.Mask))
  )

Using that would allow GerbView to export correct shape and hole size.
Of course, you still lack NETS, but can make minor edits and fab a board.
Groups of free pads can be replaced by footprints, if you wanted.

Sometimes the Gerber in, is overlaid to confirm you have cloned the design ok, then discarded.

The G_I and jjx are dummy checks, can be empty.
I’d suggest GerberView export tag such pads as G_I, but avoid a PinName, so they can be found in an editor later.

Gerber can represent an smd pad or through hole pad in one of 3 ways

  1. as a raster of lines going left to right, which eagle likes to do, and it bloats the gerbers terribly, as well as making them hard to import features from.
  2. as a polygonal copper feature
  3. the proper way, as a “flashed aperture”, meaning it references a shape from a list of apertures embedded in the file or from an external file if a very old gerber format, when specifying the shape of a given pad feature.

I suspect flashed apertures are being imported from gerbers as via type objects, as there is little or no other metadata to go by, and the educated guess gets it wrong.

Regards,

Erich.

1 Like

Yes, currently GerbView only has one decision, which is to export (round) via (of averaged XY) in all Flash items.
That’s a good guess for genuine vias, but quite wrong on SMD, and usually the wrong shape on most non-via pads too.

There are requests for better export of Flash to footprint, meantime I’ve added a bug report requesting some plot time decisions.

I’ve been testing the GerbView to pcbnew flows, and the smart-auto-reconnect of trace polylines inside pcbnew.
For this test, I take a completed design, and split into 2 files,
a) a parts+net file (no traces) and
b) a Gerbers->GerbView->pcbnew->(manual fixup by remove of bad vias) -> traces only design file.
I’ve coded a lazy persons script, to delete vias not in a really-is-a-via-size list, keeps best guess of genuine vias.

Then file.append either to merge.
Append of traces file to parts+net, autoconnects on release.
Append of parts+net to traces, needs save/reload to apply autoconnect.

The pcbnew somewhat hidden smart-auto-reconnect, will try to tag (net 0) trace polylines (from Gerbview export) with (net PinNetName) & does so if it finds no violations (ie that results in conflicting net seeds)

Here is a screen shot, notice all ex-gerber imported traces, have correctly attached net-names :slight_smile:

Fill areas are plot-able, but are GerbView generated edge+area fills, so typically would be recreated & repoured in pcbnew, if expensive editing was planned.

If you add parts manually, you can now use the new WireIt plugin to create new netnames on selected N pads.

As complete/valid net-sets of pins are tagged, the traces will nicely autoconnect(net-tag), provided there are no violations.

Hopefully these rules/explanations will help the OP, & others importing via GerbView.

2 Likes

It would be nice if these flashed objects were rendered in a different colour as being highly suspect.

It does make me wonder what happens if you submit the Gerber to a random PCB fab

I’m not quite following your comment ? What is suspect about which flashed object ?

This is the starting section of a KiCad Gerber file - this has comments and you can see flashed circular and rectangular pads.

G04 #@! TF.GenerationSoftware,KiCad,Pcbnew,(5.0.0-rc2-160-g7b7355772)*
G04 #@! TF.CreationDate,2018-06-23T08:09:59+12:00*
G04 #@! TF.ProjectId,hack_jg,6861636B5F6A672E6B696361645F7063,rev?*
G04 #@! TF.SameCoordinates,Original*
G04 #@! TF.FileFunction,Copper,L1,Top,Signal*
G04 #@! TF.FilePolarity,Positive*
%FSLAX46Y46*%
G04 Gerber Fmt 4.6, Leading zero omitted, Abs format (unit mm)*
G04 Created by KiCad (PCBNEW (5.0.0-rc2-160-g7b7355772)) date 06/23/18 08:09:59*
%MOMM*%
%LPD*%
G01*
G04 APERTURE LIST*
%ADD10C,0.100000*%
%ADD11C,0.150000*%
%ADD12C,0.300000*%
%ADD13C,0.400000*%
G04 #@! TA.AperFunction,NonConductor*
%ADD14C,0.031750*%
G04 #@! TD*
G04 #@! TA.AperFunction,SMDPad,CuDef*
%ADD15R,1.050000X0.650000*%
G04 #@! TD*
G04 #@! TA.AperFunction,SMDPad,CuDef*
%ADD16R,1.350000X0.400000*%
G04 #@! TD*
G04 #@! TA.AperFunction,ComponentPad*
%ADD17C,1.600000*%
G04 #@! TD*
G04 #@! TA.AperFunction,SMDPad,CuDef*
%ADD18R,1.400000X1.600000*%
G04 #@! TD*
G04 #@! TA.AperFunction,SMDPad,CuDef*
%ADD19R,1.900000X1.900000*%
G04 #@! TD*
G04 #@! TA.AperFunction,Conductor*
%ADD20R,1.900000X1.100000*%
G04 #@! TD*
G04 #@! TA.AperFunction,SMDPad,CuDef*
%ADD21R,1.900000X1.100000*%
G04 #@! TD*
G04 #@! TA.AperFunction,SMDPad,CuDef*
%ADD22R,1.250000X0.600000*%
G04 #@! TD*
G04 #@! TA.AperFunction,SMDPad,CuDef*
%ADD23R,2.199640X1.600200*%
G04 #@! TD*
G04 #@! TA.AperFunction,SMDPad,CuDef*
%ADD24R,1.600200X2.199640*%
G04 #@! TD*
G04 #@! TA.AperFunction,ComponentPad*
%ADD25R,2.032000X1.727200*%
G04 #@! TD*
G04 #@! TA.AperFunction,BGAPad,CuDef*
%ADD26C,0.500000*%
G04 #@! TD*
G04 #@! TA.AperFunction,SMDPad,CuDef*
%ADD27R,0.700000X0.250000*%
G04 #@! TD*
G04 #@! TA.AperFunction,SMDPad,CuDef*
%ADD28R,0.250000X0.700000*%
G04 #@! TD*
G04 #@! TA.AperFunction,SMDPad,CuDef*
%ADD29R,1.725000X1.725000*%
G04 #@! TD*
G04 #@! TA.AperFunction,SMDPad,CuDef*
%ADD30R,0.350000X0.180000*%
G04 #@! TD*
G04 #@! TA.AperFunction,SMDPad,CuDef*
%ADD31R,0.300000X1.500000*%
G04 #@! TD*
G04 #@! TA.AperFunction,ComponentPad*
%ADD32R,1.727200X2.032000*%
G04 #@! TD*
G04 #@! TA.AperFunction,SMDPad,CuDef*
%ADD33R,0.700000X0.600000*%
G04 #@! TD*
G04 #@! TA.AperFunction,SMDPad,CuDef*
%ADD34R,0.600000X0.700000*%
G04 #@! TD*
G04 #@! TA.AperFunction,SMDPad,CuDef*
%ADD35C,1.400000*%
G04 #@! TD*
G04 #@! TA.AperFunction,Conductor*
%ADD36C,0.100000*%
G04 #@! TD*
G04 #@! TA.AperFunction,ViaPad*
%ADD37C,0.508000*%
G04 #@! TD*
G04 #@! TA.AperFunction,ViaPad*
%ADD38C,0.584200*%
G04 #@! TD*
G04 #@! TA.AperFunction,Conductor*
%ADD39C,0.304800*%
G04 #@! TD*
G04 #@! TA.AperFunction,Conductor*
%ADD40C,0.152400*%
G04 #@! TD*
G04 #@! TA.AperFunction,Conductor*
%ADD41C,0.203200*%
G04 #@! TD*
G04 APERTURE END LIST*
D10*
D11*
X177002200Y-166007200D02*
X177002200Y-198007200D01*
X285002200Y-198007200D01*
X285002200Y-166007200D01*
X177002200Y-166007200D01*
D10*

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.