Dumb mistake with plane refill

Hi all,
I just received a PCBA from Eurocircuits and got a short to GND on the 12V rail. It turned out that I had moved a 12 V via, but not regenerated the ground plane fill, causing the via cutout to be in the wrong place and the via connect to GND:
image
(lower +12V via, yellowish layer is GND).

So my mistake. I was wondering - how did this happen and how could I prevent this next time?
I did not generate gerber files where I might have noticed, as Eurocircuits accepts KiCad PCB files directly. The DRC complains about out-of-date fills, but then finds no error. I ran the DRC before to check all was OK, but the via move was a last-minute change to the PCB and I did not run the DRC again.
Again, no fault from KiCad, but I am wondering: Could the tool somehow prevent this from happening?
First - why are zone fills not automatically updated? Probably a performance issue? Seems pretty fast though. Maybe add an option to refill automatically (checked by default, turn off for large boards)?
Or a big “zones out of date” indicator, like all zone fill overlaid with a skull icon?

BTW I rescued the PCB by drilling through the via.

The nightlies have a “Check zone fills before plotting” option that can be checked to prevent this issue. It may be on the 5.1.x series but I cannot confirm.

V5.1.8 has the same checkbox for [ ] Check zone fills before plotting

Always do a DRC check before generating Gerbers?
Turn on that checkbox?

How big is the batch size of those boards?
They are quite easily repairable by drilling out the offending via, and maybe poke a wire through it and solder it to where the via should be. If you want to add the wire, then be careful of sharp edges around the hole.

1 Like

The issue here is the kicad_pcb file was provided and that might not be in a state of zone refill.
Plots, gerbers, drc all prompt or perform a refill but the RAW file doesn’t need to.

If your workflow is utilising boardhouses that take kicad file directly there isn’t a lot of additional prompts that can be given without causing major auto-regen in the background. The best thing is NEVER release without DRC being clicked & save (at the very least this will do a refill)

1 Like

I misread the original question, didn’t catch that you weren’t generating gerbers until the second time I read the post after @Naib’s reply.

The idea of sending a PCB file only makes me a bit queasy.

1 Like

I can see both have its problems, sending Gerber and PCB files. Gerber is an ancient format, there is no naming standard for the layers, however “auto-guessing” typically works well. Why bother with gerber when you can send the PCB file?
In my case also I ordered PCB assembly and they extracted the component positions directly, instead of me having to generate another non-standard component placement “csv” file.
I would guess particularly for beginners this is easier than sending out heaps of dinosaur age data.

But back to the original question: Why do the fills not update automatically? Performance? Is there a hidden switch for that?

Gerberx2 fixes that
Odb++ might be better as a single file with assembly info but gerberx3 provides assembly info

[Edit]
I apologise for the noise. Sometimes my brain is a bit slow in syncrhonising with other people’s thoughts. [/Edit]

Pcbnew / File / Plot / General Options / [x] Check zone fills before plotting
(Third time in this thread!)


(Fourth time in this thread!)

It very likely also is an performance issue. Some KiCad users make BIG PCB’s with more then 20 copper layers which certainly will have many zones on those layers.

The best guard for you is probably not to rely on a checkbox somewhere in KiCad, but make a checklist, and follow that checklist before you place an order to have boards manufactured.

3rd time in this thread,
The OP provided the *.kicad_pcb file to the fabrication house NOT GERBER files . A design can progress without ever doing a zone refill and there is only a couple of prompts to the user to actually refill

  1. when DRC is performed
  2. when artwork is generated.

Now I would question why someone provided any data without a final DRC is a different question but if the user never initiates these steps then Kicad will NEVER prompt to refill and we end up with the OP situation

@OP always run DRC before sending data,

2 Likes

I have read and understood this the first two times.
And again I am not blaming KiCad, I should have run the DRC before sending the file.

The question was: Why (eg. when I move a via) is the zone fill not updated automatically? Is there a setting for that?

I am NOT referring to plot output.

Only to add noise to this thread.
Does the manufaturer make the pcb from the kicad file or do they generate the gerber files out of the kicad file?

I prefer to send my gerber and drill files. If the manufacturer follows my files and there is an error, it is my fault. Otherwise it is their fault.

2 Likes

my reply was to @ paulvdh who still thinks this is associated with GERBER files. There are a lot of places to automatically regenerate it to mitigate this but if you never do these steps (DRC or GERBER) then there are risks.

To your question as to why the refill isn’t automatic. Imagine every time you did a little thing with the layout: move a trace, move a via, move a component it had to refill all the floods. The UI/UX would be atrocious with any form of reasonable card you would not be able to work on it. The compromise is that it is user triggered and prompts at critical stages.

1 Like

I was thinking that refreshing automatically on saving could be and option but sometimes I use the “holes” in the plane to guide my new routing if I am trying to shave some mm of space, it would not be nice it the disappeared just like that after saving.

I am not sure anymore which error did I have (it must have been something pretty similar to yours) but I got used to generate gerber files and then check those with another program (gerbv), sometimes staring at KiCAD for hours blend some issues away, when the color scheme changes you are able to see some mistakes pretty fast.

Off course all this can be scripted (there are already some scripts available), when you are ready, you click a button and automatically generate your Gerbers, Drill File, Position Files, iBOM, etc.

2 Likes

That I do too.

I look for similar problems here and follow as best as I could.

So here’s a suggestion for improvement:
Mostly there’s no functional reason for not immediately refreshing the planes, it’s just often too slow to be acceptable. Excepions are the use cases described by der.ule and Mediser.

Make the “refill on change” behavior user selectable:

  • never/manual (as today)
  • on save
  • always (might be better for smaller board/beginners/experienced users making dumb mistakes)
  • in background

“in background” would mean that every edit triggers a refill in a background process, which would either be displayed when finished or discarded when a new edit was done. I mean how many CPU cores does a current PC have? 8? 12? 16? I have lost track actually. One could just do these refills instead of running the idle task.

Some form of option for two of your options seems reasonable

  • never/manual (as today)
  • on save

The other two… the amount of recalculations will be quite severe and the frequency… every little thing would trigger the recalc and a refill could take 1second (more for larger cards ESPECIALLY with complex clearance rules that must all be adhere). don’t underestimate how much this would induce rage, think about how often you would move a trace… should it recalculate for every 1nm of movement or when you release, what if you then decided it didn’t work so you need to move.

Always and background would be beyond painful. Background could work if it aligned with a auto-save but then that would be covered by the “on save option”

“always” would only work for simple boards.
But what’s the problem with “in background”? That is how all spell checkers work - you type a word and with some delay get red squiggles below. Or source code indexing in any code editor… Even if it takes 10 s - so what? If it runs in the background and doesn’t hinder your work?

You can’t really compare spell check with refill.
I agree spellcheck does occur in the background but

  1. it is a significantly low priority task and sometime it takes 10-20 seconds for an update to appear
  2. Such updates do not actually modify what you are doing, just indicate

What is being discussed here is modification while modification is taking place. Lets remove the CPU overhead from the problem for now, lets assume you have a stupidly powerful computer and the refill is threaded so it would use an “unused core”, lets assume the user does not mind KiCAD now taking 100% continuously and sounding like their computer would take off.

if you are doing updates to the design and something is modifying something not in your immediate focus, this is a major distraction as well contention as to whom is modifying something.

Anyway… I opened a ticket lets see what the dev’s think
https://gitlab.com/kicad/code/kicad/-/issues/6413

Probably depends on how you use the planes. I had a relatively simple four layer board - outer signal layers and power/GND inner layers. The GND plane was GND only, no traces, cutouts whatever. So I had it turned off (not visible) most of the time. I don’t see how updating this in the background would do any harm.
Of course if you have a layer with multiple supply fills and some extra tracks you are working on, that might be a different story.
I agree that firing up an unused core might cause a notebook fan to go into siren mode.

.kicad_pcb isn’t a static file format… things change.

Relying on a standard (ancient) interchange format causes less trouble, as the interpretation of your board data is been tested millions of times.

You are putting a lot of trust into your fab house to use the correct KiCAD version to open your files and generate the Gerbers from, as that is what their CAM system will use.

2 Likes