Inner layer 1 doesn't load on gerber viewer (kicad 6) but does on Gerbview (kicad 5)

The project was completed in Kicad 6 but I have trouble loading one of the inner layers.

When I open Kicad 5 Gerb view everything loads normally.

What could be the issue?

What do you mean by “loading”, and what kind of trouble?

Hi eelik,

By loading I mean, opening and viewing the layer.

Every other layer can be viewed normally but Kicad is unable to load the specific inner layer and if I go to close the Gerber viewer window, Kicad freezes and I terminate the applicaiton.

I also realised that the issue is caused when the copper zone of this layer in question is filled as “hatched”, as opposed to to “solid”. In the latter case I can view it normally.

Make a backup of that layer. It may be important for finding and squashing bugs.

To me it looks like you’ve found two bugs.
The first bug seems to be that KiCad apparently generates a faulty Gerber layer.
The second bug is that it hangs Gerbview.

Have you tried to load that layer into another gerber viewer?
Some people use Gebv from the Geda project, as it’s unlikely to have the same bugs (if any) then KiCad’s gerber viewer.

The Gerber format is maintained by Ucamco (Which is a manufacturer of gerber plotters) and they also have an online reference viewer for Gerber files:

1 Like

Thank you for this link, I didn’t know there are online viewers like that.

Both Gerbview from Kicad 5 and the Ucamco viewer you linked to can open the file normally.

Kicad 6 gerber viewer cannot.

I tried removing half the layout from middle up of the board and what is left can be normally viewed so I will try to make copies of my original design and pinpoint what exactly on the layout is causing the issue.

It’s quite common to have a Gerber previewer on websites from PCB manufacturers, so you can verify if they can work with your files before you commit to a final order. This is quite useful because there are quite a few different versions and dialects of the Gerber format (It has roots some 40+ years back).

Is it a big and/or secretive project?
Can you post the zipped project or at least that gerber layer here?

Errors like this are also treated very seriously and with priority on Gitlab, but KiCad developers are a precious resource and they’ve already got a quite substantial workload (with some 1400 open issues on gitlab) Result is that anything we can do to get more information about the bug before making a report on gitlab is a plus.

What hatching parameters are you using for the zone?
Is the bug still present if you change those hatching parameters?

Thanks for all the feedback.

I tried different orientation and claearance amounts but the issue is not solved. Not until I turn it to full solid.

As I said earlier also, cutting away the pour from the middle and upwards seems to solve the issue so something could be wrong on the top part of the layout. In any case I attach the zipped gerber file of the full layout of this layer. gerbers (286.9 KB)

The parameters are:

Another strange issue I encounter is that sometimes when I make a copy of the project folder in My Documents and I try to rename the folder to a different name, the window freezes as soon as I hit enter. Again, after terminating My Documents and reopening, I can normally rename the folder. Deleting the folder takes hell of a lot of time, as opposed to deleting any other copy of other projects I have. Not sure if this is related but I get a sense that it does. Running Kicad 6.0.4 on Windows 10.

It’s also possible that it’s only a problem with the calculation-time. On gitlab there was a thread about zone-filling (or 3D-rendering?) needing massive time with sloped hatch-orientation.
It’s a difference if you:

  • change orientation == 0° / 90° ?
  • double (or more) hatch width / hatch gap (to get less geometry-items and therefore less gerber-items to calculate)

The gerber-file itself seems correct, also my cross-check-gerber-viewer (gerberlogix) shows the file mgflexv-trial-In1_Cu.g2

I can confirm the calculation-time issue mf_ibfeew mentiones.

I just let KiCad’s gerbview run in the background and after about 5 minutes the layer showed up in Gerbview:

During those minutes my PC load was at a steady 8%, which means it’s chugging along at a single thread. During that time I’ve also both loaded it in Ucamco’s reference viewer and Geda’s gerbv, and both show the same picture.

My PC has an AMD 5600G, which is not a top processor, but no slouch either.
After the inital slow load I can pan and zoom normally without lag in Gerbview.

In the meantime I’ve also had a look at existing issues at gitlab, but I see no current issue about slow loading. There is this old (and closed) issue:

And this still open issue about a gerber file with a lot of vectors:


I just let KiCad’s gerbview run in the background and after about 5 minutes the layer showed up in Gerbview.

Ha, my laptop has also just finished the calculation. With 25minutes I’m way slower than @paulvdh .

Maybe it should be nonetheless reported to gitlab, as other viewers don’t show such big slowdown? (maybe there are some easy optimizations possible?).

1 Like

Oh so it was the calculation time after all…

Well, for what it’s worth, I tried removing copper starting from the top and after 50 mils of copper removal I got the layer to appear immediately on Gerber Viewer of Kicad 6.
In contrast, removing only 25 mils of copper pour from the top still allows the slow calculation issue to persist on Gerber Viewer. (I say slow but never had the patience to allow mine to complete and calculate the time). Any further removal after 50 mils produces a “fast” gerber file.

See images of how the pour removal was done and attached the gerbers for “slow” vs “fast” layers. Please verify if the “fast” gerber file also appears quickly on your side:

slow-mgflexv-trial-In1_Cu.g2 (1.5 MB)
fast-mgflexv-trial-In1_Cu.g2 (1.5 MB)

So as a temporary solution I will simply remove 50 mils from the top and move on with my life.
Let me know if you have any other ideas on how to pinpoint the issue.

Settings for keepout:

Settings for copper zone:

Indeed, your “fast” file also loads normally on my side.

In the mean time I’ve created a scratch project and was able to reproduce the issue, and I’ve also reported it on gitlab:

I’ve also attached the test project I made to that issue on gitlab. Here is a direct link:


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