KiCad doesn't delete tracks and vias after changing number of layers

[Paweł Seweryn]

Tracks and vias on internal layers are not deleted after changing number of layers from 4 to 2. You can't see them, but they are still there. You can't make another vias, because of those on internal layers.

[Guillaume Simard (gsimard)]

Correct.

But is it really important ? When would you switch from N layers to M layers where M < N ?

If you really have to do it, then you can delete everything on layers N>M before changing the number of layers using the block tool while disabling other layers to be conserved in the Layer widget.

By the way, as of now, if you go from 4 layers to 2, and then from 2 to 4, you get your tracks back, which is normal, because as you said PCBNEW does not delete them.

I think this shouldn't get fixed, as someone may by accident request a number of layers smaller than the one he is working with.

Guillaume

[Guillaume Simard (gsimard)]

Maybe we could add a warning to the user if selecting less layers in the dialog.

[Paweł Seweryn (pawel-seweryn88)]

W dniu 2011-12-15 23:12, Guillaume Simard pisze:
> Correct.
>
> But is it really important ? When would you switch from N layers to M
> layers where M< N ?

Sometimes it can be important. We've made a project of 4-layer
mainboard, which consisted few modules. Then we decided to divide the
mainboard to smaller modules. Some of them doesn't need 4-layer PCB and
we decided to change it to 2-layer due to lower costs.
> If you really have to do it, then you can delete everything on layers
> N>M before changing the number of layers using the block tool while
> disabling other layers to be conserved in the Layer widget.
Of course we can do that. But we had to know, that there is a problem
with layers ;)
> By the way, as of now, if you go from 4 layers to 2, and then from 2 to
> 4, you get your tracks back, which is normal, because as you said PCBNEW
> does not delete them.
>
> I think this shouldn't get fixed, as someone may by accident request a
> number of layers smaller than the one he is working with.
Then KiCad can just confirm deleting the traces or just ignore the traces.
> Guillaume
>
> ** Changed in: kicad
> Status: New => Won't Fix
>
> ** Changed in: kicad
> Importance: Undecided => Low
>
Pawel Seweryn
<email address hidden>

[Nicholas Savenlid (nicholas-z)]

i started with 8 layers but ended up with 6
not always easy to judge exactly from the beginning how many layers you will need.

i have now 8 layers but only 6 are used.

i assume i can keep it that way since there is no real-stackup with prepreg/copper thickness and impedance calculations anyway and just ignore to plot them

hmm of course some layer numbering can become confusing at fab-out

[Chris Pavlina (pavlina-chris)]

This needs to be revisited, it's totally unacceptable and can't be left sitting around for *five years*. This results in false connections and causes DRC to claim nets are connected when they're not.

[Novak Tamas (novak-7)]

The actual solution makes (some) sense (7083 nightly in Win7 GAL). If you decrease the number of layers

- buried vias are deleted, so no collisions with them when routing after decreasing the nr of layers.

- tracks are preserved on vanishing layers...if number of layers would be increasing back later, tracks on inner layers appearing again (but buried vias connecting them will be missing: they must be re-created after layer increase)

- normal (top-to-bottom) vias are preserved even if connecting tracks are on deleted layers.

Some enhancements may be:

- simply remove all objects on layers opted out: if you increase back the nr of layers later, "revived" layers will be empty. Decrease by 2 layers is "serious decision"; user probably is making a backup to return to if decreased number of layers would not be enough.

- when decreasing number of layers, user should select which layers to remove (E.g when I decrease nr of layers from 8 to 6, not neccessarily in5Cu and in6Cu should be gone.)

- when deleting a layer, vias which have only connections on disappering layers can be deleted as well. (after deleting all layers to remove, unconnected vias can be deleted)

-and a minor bug: if you strike hotkey Shift-Alt-V for buried via, View menu (for Alt-V) also invoked (this may be specific to Windows only).
V stands for normal via, Ctrl-V for microvia, so simple Shift-V couldn't be fine for buried via?

[Maurice Ribble (mribble)]

I filed a bug that was marked as a duplicate of this (1670502). Now that I know about this I won't have problems with it again, but I can say it really confused me. I had switched from 4 layers to 2 layers and never thought about the old interior ground plane which was creating a very confusing DRC results with my new fragmented ground plane.

I think Novak's solution sound good. I would just make sure there was a warning when removing layers saying that the layers being removed will be permanently deleted.

Thanks to Chris Pavlina and Jean-Pierre Charras for root causing this as a duplicate and explaining to me what was happening!

[Kristoffer (kristoffer-odmark)]

I just got hit by this where we did modules of a more advanced 4 layer design with impedance checks etc.

The modules made one 4 layer board and one 2 layer board based on the earlier model that had everything on the same design. When I then removed 2 layers and removed the things that were now a module.

This in turn left some "invisible" zones and tracks that I did not notice on the layers that were now deleted. This caused kicad to claim that the some nets was indeed correctly connected. And it was shipped for fabrication. Turns out that after a lot of debugging, a gnd zone had become a isolated, but was still connected through vias on the now deleted layers.

So this did cost us a lot, mostly time and frustration. I would argue that anything that can cause the DRC to malfunction should be a critical bug. And the solution should in my opinion be very straight-forward. Delete EVERYTHING on those layers that is removed, just inform the user that this will happen.

TLDR; This bug caused DRC to lie, resulting in faulty PCBs sent and fabricated. Costing us a lot of time and money.

[John Beard (john-j-beard)]

At the very least, having DRC complain about any feature on an internal copper layer that isn't in the pcb layup would be a start.

[Chris Pavlina (pavlina-chris)]

I wonder how many times this will have to happen before we admit there is a
problem.

On Mar 28, 2017 07:16, "Kristoffer" <email address hidden> wrote:

> I just got hit by this where we did modules of a more advanced 4 layer
> design with impedance checks etc.
>
> The modules made one 4 layer board and one 2 layer board based on the
> earlier model that had everything on the same design. When I then
> removed 2 layers and removed the things that were now a module.
>
> This in turn left some "invisible" zones and tracks that I did not
> notice on the layers that were now deleted. This caused kicad to claim
> that the some nets was indeed correctly connected. And it was shipped
> for fabrication. Turns out that after a lot of debugging, a gnd zone had
> become a isolated, but was still connected through vias on the now
> deleted layers.
>
> So this did cost us a lot, mostly time and frustration. I would argue
> that anything that can cause the DRC to malfunction should be a critical
> bug. And the solution should in my opinion be very straight-forward.
> Delete EVERYTHING on those layers that is removed, just inform the user
> that this will happen.
>
> TLDR; This bug caused DRC to lie, resulting in faulty PCBs sent and
> fabricated. Costing us a lot of time and money.
>
> --
> You received this bug notification because you are a member of KiCad Bug
> Squad, which is subscribed to KiCad.
> https://bugs.launchpad.net/bugs/893950
>
> Title:
> KiCad doesn't delete tracks and vias after changing number of layers
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/kicad/+bug/893950/+subscriptions
>

[slowcoder (slowcoder)]

Well, here's another guy that ran into this issue. I filed 1713754, which seems to be this issue as well.

I started with 4 layers, as that's what I expected to need. Routing went better than expected, so I figured I might be able to do it with two layers (cheaper). I changed to 2 layers, fixed a few obvious things, and ran DRC to see what I missed. DRC said everything was OK, so I happily sent the gerbers off for fabrication.

Needless to say, the boards were quite non-functional..

[KiCad Janitor (kicad-janitor)]

Fixed in revision ded4ad9b17c9c62a79fd367e7e0f6ce96c34b967
https://git.launchpad.net/kicad/patch/?id=ded4ad9b17c9c62a79fd367e7e0f6ce96c34b967