Recovering from bridged nets (auto-resolve pin conflicts)?

In a hierarchical schematic with multiple instances, nets got bridged after moving - now everything that was GND is included in the +5V net.

It should ™ be possible to recover the net names based on labels and supply symbols, well, depending on whether eeschema can resolve pin conflicts or not.

It would be doable (yet mildly annoying) to delete all the faulty nets, so I hope someone can help me out with a hint :slight_smile: If you don’t know how it’s done, also drop a comment - I’d be interested to hear how often splitting / rebuilding net names is needed. (Other tools have different concepts of nets and allow renaming, then asking whether to apply the change locally or for all members).

bridged_nets

In kicad you do not set a netname. You tell it what should be connected and then it selects the netname to fit that via certain rules. Which means it looks what is on the net and then goes through the following list to get the resulting name.

  1. If a global label is present (including power symbol) then take its name
  2. If a hierarchical label is present then take its full name (including hierarchical path)
  3. If a local label is present then take its full name (including full path of the hierarchy)
  4. Autogenerate name from refdes/pin

If multiple labels of the same scope are on the net then one of them wins (no guarantee which one, assume it is random). ERC will complain to warn you about that.

So in your screenshot it seems like you have somewhere connected your 5V net to GND. And this was most likely done in a place not pictured as i can not see a reason for it.

1 Like

Thank you, running DRC definitely helped (irgnoring ~200 errors from unfinished sections). Good to know KiCad seamlessly updates this, or at least isn’t too persistent and impedes resolutions.

As it turns out, the 74LVC3157 symbols were flipped upside-down, and the symbol GND pin ended up connected to +5V… and won. I would have expected a pin to act recessively. It’s still an issue worth warning about, however now I’m getting lots of errors that “VCC is connected to +5V”.

Finally, the symbol is for a single gate device,

but has units A and B:

A:

B:

Which KiCad version are you using?
KiCad V5.1 connects nets with different net labels silently.
KiCad V5.99 gives warnings but these can be flagged by right clicking on the message and then choose “Exclude this Violation”.

This is still a quite new feature, and seems only partially implemented. For example when you run ERC check again, it is flagged again as a warning

1 Like

testing nightlies while pretending to do work :slight_smile: - still, Error “More than one name given to this bus or net” for connecting only +5V to a pin that would rather it be called “VCC” doesn’t seem right. Shouldn’t supply symbols be equivalent to labels (mostly global ones, but nut necessarily so) and supersede ordinary symbol pin names?

I suggest to avoid using symbols with hidden power input pins. These are converted to global labels. Yes sadly the official lib still has such symbols but just make your own ones without this nonesense.

But they are labels.

KiCad V5.99 apparently always creates warnings for different net labels connected together. See:

This is a good thing, as it catches simple typo’s that would result in different nets if it is handled silently.

It is a bad thing when ERC keeps nagging about the same warning even if you’ve told it to ignore that particular error. As I wrote before, it’s a new feature and probably not well tested yet, or still in development.

It is my opinion that once you’ve flagged a warning as an exclusion, it stays excluded even when ERC is run multiple times or when you exit KiCad and go back to it a week later, which would necessitate these exclusions to be stored in a file.

Your warning text:

“More than one name given to this bus or net”

is different from the text I got in the other thread:

“Both AAA and BBB are attached to the same items, AAA will be used in the netlist.”

This could be because it is a different warning, but it could also be that we simply have different sub versions of V5.99 and this feature is still in development.

The difference is due to right-click menu nomenclature:

So I think the root cause of my problems was the invisible pin -> global label conversion, combined with the flipped symbol.

Together with the (as of yet open) question how to make supply symbols local to a subsheet, I’m beginning to see that some things have yet to be added and rectified.

Power pins always create global labels (At least in KiCad V5.1)
The only workaround I know is to change the schematic symbols, and put the power pins on them, and then connect them with local labels only.

Please report this bug.

The different text is because we try to show a specific message where possible (“both X and Y are connected to the same items”) but also we need a “generic” name for each error message, for example to show it in the list of error severities.

The invisible power pins being global labels thing is just a fact of life with KiCad; it cannot be removed for compatibility reasons. The best bet is to just not use those symbols, and don’t use invisible power pins when creating your own symbols.

For similar reasons, we are extremely unlikely to implement “power ports local to a single sheet” as a feature.

Issue created as:

1 Like

Strictly speaking labels fit the bill, only that using them makes the schematic look rather amateurish (they’re deficient in position, alignment and border options).

I do miss tag-shaped labels and power rail labels (e.g. using the arrow symbol).

Hierarchical labels are tag-shaped; nothing stops you from using them instead of local labels even in a non-hierarchical schematic

You can make your own power symbols, in case that’s useful for replicating a style of power rail label that is different from the ones in the KiCad standard library.