Zombie nets, possible bug?

Thanks Hermit, I need all the help I can get:grinning:


project zip

No, i’m obviously still persona non grata, thanks for your help guys it is appreciated

1 Like

If you use sheet files, are you aware of what the difference between global, local and hierarchical labels is? Are you aware that connecting hierarchical pins in a higher level to another label can overwrite the net name? You might want to take a look at: Hierarchical or flat schematic design, what is best for me? (How to deal with multi page schematics?)

I have promoted @RobertG4FDP one level, so he can post now


If I understand your schematic description, it is a feature that is working as intended.

I think I brought up the idea of Hierarchical Power Symbols some time ago, but it was dismissed as there are other ways to skin that cat with KiCad.

ON EDIT: I know of two(2) ways to solve the issue you are experiencing.

  1. Create the hierarchical sheets and duplicate schematics with each one having a seperate file name.

The downside to this method is that every change has to be made to every duplicate sheet. A workaround would be to get as close to finished as possible and only split the sheets to different files when the sheet is 100% complete (yeah right). Another workaround is to use a text editor to copy paste the “baseline” schematic into the other files.

  1. The current recommended method is to have the local regulators on the top level, and for the sheet to have a Hierarchical Pin labeled something like Pwr_In.

I think a further hierarchical sheet pin type of power input might help. This pin would then get a different distinct symbol which should make it easy to identify. I am of the opinion that a proper hierarchical design should not use any type of label (other than hierarchical pins) that crosses any sheet borders. Leafing the “local” power symbol restricted to the current sheet only. This would be quite a silly symbol to be honest.

In my opinion a proper (maintainable) abstraction should ensure that the schematic is readable without the use of any labels other than sheet pins. (possible exception is the root sheet or system level abstraction. But even this is only missing the new bus implementation to be viable without labels.)
This is similar to how a function in a programming language should not surpass some level of complexity to stay maintainable. (Yes i am aware that paper printouts of schematics would be useless with this design methodology. But dead trees are outdated technology anyways so why not trade this feature for the more powerful one?)

Thanks for the reply Sprig, I came across the threads on hierarchical names when I was searching the forum before posting my issue. That is an interesting discussion with pros and cons on both sides but I am anxious that it does not obscure what I am experiencing so I will try to restate clearly what I am seeing and how I got there. Hopefully I will get rights soon to upload my project which will make examination much easier.

I am laying out a design for a GPS locked 10MHz oscillator that has been kindly made available by another radio amateur but with modifications that suit my requirements and available components.
The original design connected all the supply pins of the circuit on one sheet to the +5V_DIG power symbol which is actually sourced by an Arduino nano on another sheet. When I had drawn this I thought I would like a little more isolation and placed a separate regulator on this sheet, deleted all the +5V_DIG symbols, created a new symbol called +5V_PHASE (which I have subsequently replaced by another symbol +5V_B as part of my investigations) and connected the new local regulator and all the nodes that had previously been connected to +5V_DIG to +5V_PHASE. This should have removed all the connections between these nodes and +5V_DIG.

Running the ERC gave an error saying that the output of the local regulator (tied on the schematic to +5V_PHASE) was connected to +5V_DIG. This was before I had generated the net list. When I did subsequently generated the net list and the board I could see that this was the case.

After doing a number of mods to the schematic and transferring that through to the board I can see that three of the ICs on the sheet are permanently connected to +5V_DIG while the other three are not. Even if you remove all power symbols from the three affected ICs and send the updated schematic to the board the ICs remain connected to +5V_DIG.

Obviously with de facto global power symbols in KiCad, the process of using a different named symbol and deleting all the previously used +5V_DIG symbols should have cleared all the connections between +5V_DIG and the nodes that had used it.

I am new to KiCad and may have done something silly, though I cannot see what it is but suspect that something has got corrupted in the KiCad data structures that cannot be recovered. The fact that it shows up at ERC which I assume is pre net list must be significant but it needs someone who understands KiCad at an advanced level to look and see if I have done something silly or if this is a bug. Hopefully I will be able to upload the project soon to enable this.

Thanks again to everyone who has taken an interest and made suggestions.


David many thanks for giving me rights, here is the project, I would be very grateful for any help.

RobertK6JCA 10MHz reference osc-hirachacal.zip (312.4 KB)

Could be the problem here, on U14, U10 or U13?


The power symbol +5V_DIG seems to have been deleted without being replaced by +5V_B.
The name of the nets of the hidden VCC pins is still +5V_DIG.

A hidden power input pin is a global label. Meaning no matter if the symbol is connected to it it will connect to the name of that pin.

In other words: Never ever use hidden power input pins for anything other than creating power symbols.

Hi Pedro, Rene, I deliberately left U14 disconnected in my upload to show that it is connected in the PCB to +5V_DIG even though it has no connection in the schematic. In this screen shot I have turned on show hidden pins and there doesn’t appear to be any connection to +5V_DIG on the schematic, am I missing something?

Thanks Robert

The wire is connected. An unconnected wire keeps the small square at its end and the unconnected pin keeps the small circle at its end too. The same for the 0V connection.


After Re-reading OP’s original post, I realised he only wanted to change the +5V_DIG on one of the sheets, and together with the other edit that makes this post pretty much useless. Pedro’s find of U14 (& U13, maybe more) and Rene’s mention of the nets being connected through the hidden global VCC labels makes a lot of sense.

16:05 Opened schematic and got the “Project Rescue Helper”.
Why? It’s supposed to be made with:

while I’ve got V5.1.0 myself.

16:12 Opened the project and descended into sheet

K6JCA GPS Locked Osc Logic

And it’s got 5 of the suppoesedly removed "+5V_DIG labels:


After reading Rene’s post below and re-starting KiCad the other “missign” +5V symbols were indeed resqued properly. Looking forward to KiCad V6…

Also, Some of the resqueing went wrong, some symbols that look like they should be power symbols are missing:

Then I made a .pdf of the schematic and did a search for “+5V_DIG”, which occurs 15 times.

I can not correlate this with the troubles OP is experiencing. It’s also one of those days that I can’t seem to focus on anything, and I’m getting confused here.
Could it be that the Resque thing put the labels in there and they look differently on my PC compared to OP’s original schematic?

10MHz reference osc-hirachacal.pdf
(152.0 KB)

Because you do not have the same library setup. This is normal when viewing schematics that use other libs than you. (Just accept it. There is no problem as long as the cache lib is included. KiCad will then fix it for viewing. If you extracted everything then you should be ok. Worst case you need to restart KiCad after having rescued the schematic. And this step is only necessary because there is a bug in kicad where it sometimes does not properly read the rescue lib right after rescuing.)

1 Like

I already explained to you that hidden power pins (like the ones of your symbol) are global labels. This is why there is a connection. You need to change the symbol to use visible power pins and connect them properly.

In this case the plus pin of U14 will connect to any other symbol that has a VCC hidden pin. This can be a power symbol or another symbol that is implemented in the same manner. I would assume that you have some other symbol also with a hidden VCC pin somewhere that is connected to +5V_DIG.


Ok I understand what you are saying now, I did not generate any of the symbols with hidden power pins they came straight from the KiCad library and are a foreign concept to me I will regenerate the symbols with visible power pins and suggest that no one expends any more effort on this until I have done that. Thank you for your assistance.


Back when version 4 was the current version i wrote up a tutorial that explains how one can easily convert such a symbol into one with visible power pins: IC footprint VCC+GND

The v5 symbol editor has a slightly different interface. The general workflow described is however still basically the same. If you need help with the v5 symbol editor then maybe take a look at: Tutorial: How to make a symbol (KiCad v5.1.x)

1 Like

Thank you Rene, I have generated symbols with visible power pins and updated the board and all the nets are now correct but I will check out your tutorial, again thanks to everyone who has tried to help, i’m a little bit further up the KiCad learning curve.

Dead tree technology works very well without any sort of power.

1 Like

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