Prioritize power symbols over hidden power pins on non-power symbols when determining net name

added priorityundecided statusnew labels

added eeschema label

changed milestone to %6.0.0-rc1

This is because the pins are defined as Power Input and hidden.

Right now we treat these as defining power nets even if they aren't on a power symbol. To fix this, change your symbol so that these hidden pins are a different type (such as Passive).

@kicad/code/lead_devs anyone have opinions on if we should keep this behavior vs. limiting the hidden power input behavior to symbols defined as power symbols? I'm not sure what the use case is for this and it definitely confuses users who aren't familiar.

By definition, power input hidden pins are intended to create automatic connections, like global labels.

Changing this behavior makes no sense for me and breaks old designs.

(by the way putting a power input pin at the same position as an other pin in a symbol is more a bad design than an issue)

So the behavior shown here is not a but.

This issue is the usual issue found when 2 labels are in the same net: one must choose the best name.

The enhancement could be be just give a bigger priority to a name coming from a power symbol to select the net name.

OK. I will put the second part as an enhancement for later, as adding a new label priority introduces some room for bugs that I would rather not put in 6.0

Sorry JP, but I don't think it makes as much sense to lots of other people. The number of people I see confused by power pins making automatic connections is pretty high. Frankly, it has always felt like a hack to me. If it were to be removed it would have to be done in a way that doesn't break old designs (ideally, by adding a more explicit way to specify this behavior, then converting old files), but if that were to be done a great many KiCad users would be absolutely thrilled. This only makes sense to long-time "power" users and dev team members IMO.

This only makes sense to long-time "power" users and dev team members IMO.

Doesn't make sense to this dev team member :)

It could be changed by adding a new flag to pins "treat pin as global power label" or something. Then this flag could be set for hidden power input pins stored in a format version before this change, but cleared by default for new symbols.

It's all black magic to me. If I had a big chip with 20 power pins I'd expect to see 20 pins in my schematic with 20 little wires all joined together going to +5V.

I won't even use hidden pins on a opamp:

Haha, I didn't want to pick TOO much of a fight over this feature since everyone already knows I hate it ;)

I definitely think adding an explicit flag to make the pin into a power connection is the right path. My absolute ideal would be to go back in time and never have made this in the first place, but with time machines still out of the question we do need to preserve functionality :)

removed milestone %6.0.0-rc1

added prioritywishlist label and removed priorityundecided label

changed title from Power symbol net conflict with component pin name to Prioritize power symbols over hidden power pins on non-power symbols when determining net name

I'm wondering if just add a warning as soon as the hidden pins are used in the footprint editor or during the DRC pass could be enough for the end user to self debug the issue.

IIRC the use of hidden pins stacked with power ones is suggested by KLC, the only thing that i've removed from my mind at the time i've designed my faulty symbol, was to set the stacked invisible pins to passive and left out the only one visible as power input.

While I personally never use this feature as I also prefer to have explicit pins for all my symbols, I should point out that removing it will make it very difficult to import certain CADSTAR designs. The in-built CADSTAR library has many symbols with hidden power pins connected to a net (usually VCC and GND).

I therefore suspect many CADSTAR users will have designs with hidden power pins.

Of course if we can figure out a way to import that "makes sense" and graphically looks okay, I would be happy to implement in the importer.

Nobody is proposing removing it, just making it optional and non-default. The flag could be set on CADSTAR imports if CADSTAR has this feature.

Ok thanks for clarifying, sorry for the noise

Please don't do anything for V6. This feature (bug?) has been around as long as I can remember. The probability of breaking the existing behavior is high and there is a well known work around for the issue. V7 will support symbol pin lists so this issue will go away.

V7 will support symbol pin lists so this issue will go away.

This issue is not targeted for V6, don't worry. But, symbol pin lists will not make this issue go away unless we also implement a behavior change in the connectivity code (and appropriate treatment of legacy designs as described above)

Does changing the remaining stacked pins to the passive type not resolve the net naming issue? If someone used the same design paradigm (visible pin is power in and hidden stacked pins are passive) in 5.1, would the net name be different? If it's the former, then I would say this is as designed and the user wasn't aware of this limitation. If it's the latter, then that is a regression that we should fix.

Changing them to passive type "resolves" the issue. The rest of this thread is saying that this is perhaps not a satisfactory resolution, and we should change KiCad's design so that this is no longer the default behavior (but still preserve the old behavior where needed, such as when opening legacy designs)

That's fine but I am suggesting that using pin lists is the solution for this problem. Pin lists would preserve the current behavior and provide a more desirable solution. If pin lists aren't a sufficient solution, then we need to propose something else and add it to the V7 work package list.

Where is the spec for pin lists? I don't understand how they have anything to do with this problem ("this problem" meaning the non-intuitive behavior of hidden power input pins).

It's S22 on the work package doc. It's called "Stacked pin definitions" but it's really just a single pin with a list of pin numbers (instead of a single pin number) of all of the pins connected to the same signal. It was in the original symbol library file format document. I just ran out of time and it didn't get implemented so it was deferred to V7.

So pin lists would give users another alternative to accomplish this goal, but would not prevent them from shooting themselves in the foot if they decide to use hidden power input pins for whatever reason. This is why I think they are separate: even if we provide a new way (pin lists) the old way is still "broken" in terms of users' expectations.

I just did some testing and the net naming should probably be prioritized so it's always "12V" rather than dependent on what appears to be the drawing order but the actual net connectivity does not change. Only the name of the net changes. I don't see how adding net name prioritization scheme the new connectivity code would break anything. It would only change the net names which really seems trivial (although it could impact the real time connectivity performance) to me since we already have that issue for most nets without a label. Does 5.1 behave the same way?

The problem is not the given example, it's the general property that hidden power input pins form implicit connections. In the example, the problem is only the net naming priority. But in other past examples and forum threads, the problem is accidentally creating global labels from the pin names that cause unintentional connections to other pins elsewhere in the schematic.

I am focusing in on the problem noted by Alexis, Jeff and me that hidden power input pins act like global labels even if they are not on power symbols. This behavior is unintuitive, does not match any other software I know of, and continuously trips up new users. So I propose we make it no longer the default behavior.

I'm fine with that but obviously that would be a V7 thing because I can see things going sideways for existing designs.

changed milestone to %7.0

closed with commit 3a9ed47b

added statusfix-committed label and removed statusnew label

mentioned in issue #12811 (closed)

This does not seem to work when a hidden power pin shares location with a visible power pin

I use the latest nightly

Application: KiCad Schematic Editor (64-bit)

Version: (6.99.0-4957-g01e517265f), release build

Libraries:
	wxWidgets 3.2.1
	FreeType 2.12.1
	HarfBuzz 5.0.1
	FontConfig 2.14.1
	libcurl/7.86.0-DEV Schannel zlib/1.2.13

Platform: Windows 11 (build 22621), 64-bit edition, 64 bit, Little endian, wxMSW

Build Info:
	Date: Dec 15 2022 06:39:46
	wxWidgets: 3.2.1 (wchar_t,wx containers)
	Boost: 1.80.0
	OCC: 7.6.2
	Curl: 7.86.0-DEV
	ngspice: 38
	Compiler: Visual C++ 1929 without C++ ABI

Build settings:
	KICAD_SPICE=ON

added statusfix-released label and removed statusfix-committed label

Prioritize power symbols over hidden power pins on non-power symbols when determining net name

Description

Steps to reproduce

KiCad Version

Designs

Child items ...

Activity