Oh is that true? That would explain why it didn’t work haha.
I just assumed it would work because I’ve seen Eagle tutorials where Jeremy Blum adds a bunch of vias throughout the board to connect the top and bottom GND copper fills to ensure they are connected throughout the board. You can see it at 19:52 in https://youtu.be/CCTs0mNXY24?t=19m52s
I guess KiCad doesn’t behave this way. Thanks for clarifying that.
Yeah, there was talk/work to be able to have more simple stitching vias in future… but I’m pretty sure that is not possible yet.
Stitching is one of KiCads greatest weaknesses at the moment. Messy and hard to move around
KiCad is what I’d call 'Lone Via Averse’
Rule: if there is a Trace-Corner anywhere under the via, it will attach it to that net.
That means a Moved-too-far-Via, or one simply copied onto a trace segment clear of any corner, will not connect.
Also, you do need to re-run DRC, not just ‘B’/Reflood to check this, as DRC is really DRRC, and it will rebuild the net-trees, and thus isolate any vias that now violate the rule. A simple re-flood does not do this.
If you are in Route-Mode and add a via, then it will add a corner to the segment when placing Via.
( ie you can add a via to an already routed trace, just take care to do it in Route Mode, or pick an existing corner)
It is a pity Copy-Via does not have the same auto-corner-add, as it knows it has a (eg) GND Via on the Cursor.
In route mode, you can use D to Drag a via, and keep the important Trace-corner inside the via.
Interesting usage.
There could be good potential for kiCad in this type of ‘sub-set seat at zero cost’, to keep the bigger players honest 
Of course, as kiCad improves, the other tools are required less and less…
What package is used on redesigned more carefully for manufacture. ?
and how do you transfer the design information ?
I use Kicad now and then just out of interest. I am 99% a Linux user so if I do a final design myself then I use the Geda pcb tools, simply because I have used them for many years, and while they have their own problems, the library handling is vastly better than the Kicad system. And I do not see much hope of an improvement in the Kicad library system in the future. Linux default library paths
There is no real collaboration needed on designs in my work (short term entertaiment, shows, exhibitions, films etc.) so If a test piece is passed on to a colleague it is never more than a few pages of A4 and always needs modifying and redrawing so it is no big deal for them to redraw it in whatever software they use. I have seen copies of Altium and Eagle at one end of the spectrum and RS Designspark at the other. The same with Cad software, $olidworks, Rhino cad and me with Freecad
Interesting to find a gEDA user. I have glanced at gEDA a couple of times, but the project seems almost dormant, last news 2014???
It does not seem to be anywhere near as active as Kicad but development is going on in the background, it just seems that there is no forum for public discussion about the software. The last update to the development branch I got was about 5 weeks ago from an ubuntu PPA https://launchpad.net/~mehanik/+archive/ubuntu/geda-unstable.
It is easy to build from source as well and a lot easier code to hack than Kicad, so modifying it to suit my needs is fairly easy.
I don’t use gEDA per se, but I like the gEDA Gerber Viewer (" gerbv " - http://gerbv.geda-project.org/ ) more than KiCAD’s “GerbView”.
Dale
I do the same and so do many more. A second opinion on Gerber output is often helpful
Shudder… m4 was popular in some arcane mail processing applications 
I have both installed, and I wondered if it would make sense to KiCad to include a GerbV launch button, similar to the GerbView one ?
That would make GerbV an installation dependency. Then you run into the lack of gEDA for OSX.
Due to a bug in KiCad PCBNew ([Bug 1609401] Re: PCBnew fails to properly import netlist after changing annotation with pours see https://bugs.launchpad.net/kicad/+bug/1609401)
The fix is simple. Type ‘B’ and the pours will regenerate except where there are errors where they appear hatched. Note the rats nest netlist name in the hatched error zone. Edit the zone (hit ‘E’ near a zone edge) and change the pour net to the rats net netlist name. (the rats nest name is usually near the top of the selection window). Type ‘B’ again, and the pour will fill. Run DRC and the errors are gone.
I have filed a bug report with the KiCad developers regarding this issue.
Be careful what you just ignore, it looks like your pours aren’t connected judging from your screenshot.
The zones are connected in the real pcb: copper over copper.
But jwpartain1 is right, it is potentially dangerous. They are not logically connected. To do so, edit the zone and select GND net.
Then refill the zone.
The ratsnest will only go away if the pour actually connects ALL GND pads OR these pads are connected to GND via tracks…
The red copper pour is not connecting them all together.
Your clearance settings are too wide, to make that possible.
The ratsnest tells you that you still got islands and your layout isn’t connected as your schematic implies/defines.
If you ignore this, your circuit will NOT work.
Just because you can place a GND symbol in your schematic anywhere you need GND, doesn’t mean your physical board has the same ‘option’ of creating GND ‘out of thin air’ at any place on your board.
You actually have to make sure (and that’s what the ratsnest is telling you there) that the GND plane/tracks/net actually connects all pads that are supposed to be connected to GND are really connected to it.
The OPs problem was that the visual check showed him OVERLAPPING copper pour with a pad (just not to it’s center) while also showing a rats-nest link, which implies no connection (PCBnew tests to the center, not peripheral overlapping).
From a physical/technical point of view the layout would have worked.
You on the other hand have DISCONNECTED GND zones/pads/tracks/islands and your pcb will NOT work if you ignore this.
PS: If you’re lucky your pcb fabricator will stop your boards before producing them, as the gerbers have NET information in them for testing continuity of the copper tracks (E-Test).
The CAM tool they use will flag these as non connected, or at least should do so.
PPS: personally I have a GND pour on the back of 2 sided pcbs and have ONE via for EACH GND pad with a track to that pad right next to it, no matter if the front pour would have done this already (unless space is of premium):
I think this might be bug 1609401 https://bugs.launchpad.net/kicad/+bug/1609401.
There is a fix (usually) Type ‘B’ and the pours will regenerate except where there are errors where they appear hatched. Note the ratsnest netlist name in the hatched error zone. Edit the zone (hit ‘E’ near a zone edge) and change the pour net to the ratsnet netlist name. (the ratsnest name is usually near the top of the selection window). Type ‘B’ again, and the pour will fill. Run DRC and the errors are gone. Usually.
You know that this is a very old thread?
Locking it now
