Stacked N/C pins get common net assigned in PCBNew

[Enrico]

If I stack N/C pins in the symbol editor (make all but one not visible) they get a common net assigned in PCBNew and the connections between the pads counts as unconnected traces. Same happens if the stacked pins are declared as anything else but N/C and I assign N/C flag manually. I don't remember this behavior from earlier versions (but I'm not 100% sure) and think it's a bug because it makes no sense to connect all the N/Cs of one IC together or get them listed as unconnected otherwise.
I hope my explanation is comprehensible, see attached screenshot as well.

Application: KiCad
Version: 5.1.4-e60b266~84~ubuntu18.04.1, release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.58.0 OpenSSL/1.1.1 zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0 librtmp/2.3
Platform: Linux 4.15.0-66-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.22
    Boost: 1.65.1
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.58.0
    Compiler: GCC 7.4.0 with C++ ABI 1011

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=ON
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON

[Seth Hillbrand (sethh)]

I seem to recall a similar discussion about this previously but I can't find.

In any event, I agree that not-connected means not connected to everything and should be fixed. I've tagged v6 as this will change netlist output and the netlister is also substantially revised in v6

[Rene Poeschl (poeschlr)]

> I don't remember this behavior from earlier versions (but I'm not 100% sure)

This was the case in v4. I can not say how it was in versions before that as i never used these.

---

We had a discussion regarding this as part of the discussion of eagle import. See https://bugs.launchpad.net/kicad/+bug/1821319

[Rene Poeschl (poeschlr)]

I generally think stacking pins is a workaround. Mabe a better option would be if pins can be setup to connect to multiple footprint pads. This would allow ERC to know more about such a "stack". And could give more options. One example could be a setting for "connect all" vs. "connect any (example the typical push buttons)". The latter together with not connecting these pins to any outside net would allow them to stay completely unconnected.

The pin type would then really only be used for ERC instead of having a second purpose (see the current use of hidden power input pins for why using one setting for two different purposes might be a bad idea in the long term.)

[Seth Hillbrand (sethh)]

Thanks Rene! I knew we had some conversation about this previously. I generally agree with you on some useful features in the future.

For the purposes of this bug, it is only defining the netlist behavior when a pin is set to type NC. I propose that each NC-type pin will be given its own, unique net. The NC schematic item will not affect this.

[Rene Poeschl (poeschlr)]

If we really want to give the pin type double usage maybe a separate new pin type that guarantees something can not be connected would be a better solution as it would allow old schematics to export unchanged.

[Enrico (eatis)]

> If we really want to give the pin type double usage maybe a separate new pin type that guarantees something can not be connected would be a better solution as it would allow old schematics to export unchanged.

This is a very good idea in my opinion. I have another project where some ICs have redundant pads for some signals to make routing easier. Right now I have to delete the net assignment of the unused pads in PCBNew manually. But every time the board gets updated, the net assignment is back in place. So a new pin type with the property "can be connected" would be very nice. In my case there would have to be some kind of "pin group" where at least pin has to be connected. But this is a very specific case, I don't know if the normal user has any advantage from this functionality.
Another possibility would be to add a check box to lock the net assignment to each pad (as with vias). In this case I could manually select which pins will be connected or N/C and the assignment doesn't get overwritten every time the board gets updated.

[Wayne Stambaugh (stambaughw)]

The stacked pin issue will go away with the new symbol library file format. That does not address the at hand. I would think that the net list generator would not create a net from stacked N/C pins. The ERC should generate an error if N/C pins are stacked with non-N/C pins. I'm guessing this does not affect 5.1 and is a regression in the new net list generation code.

[Seth Hillbrand (sethh)]

@Wayne, This bug is against 5.1.4. But I haven't gone back to see how far back it goes.

@Rene, I don't want to add a new "really not connected" pin. That will only be confusing. There is no part that I have ever seen that in its datasheet asks the NC type pins to be connected to something. If users want a set of pins connected to themselves and nothing else, they can use the Passive type, so we lose no function here.

[Rene Poeschl (poeschlr)]

I am ok with this as long as users are informed about this change on updating a schematic from v5 to v6. (So there should be a warning generated if the updating algorithm discovers a symbol with stacked NC pins.)

---

Also NC pins can be connected to a wire right now. I read your commend as if this would no longer be the case in the future. If so then this would be another thing where a warning would need to be generated should it be discovered.

ERC does complain about it right now. There are legitimate parts where one can connect a pin that is documented as NC in the datasheet. The guidelines of the official lib (KLC) would not allow such a pin to be of type NC but users do not need to follow KLC for their personal lib. And of course there are symbols in the official lib where this was missed. One example https://github.com/KiCad/kicad-symbols/issues/2249 (A EMC protection device where half its pins are not connected internally but will in most cases be connected on the pcb)

[Seth Hillbrand (sethh)]

The problem is that there are two types of NC. The one in your issue is when NC on the sheet means "it doesn't matter where you connect this pin". Then there is the type where NC means "this pin is used internally and you _must_ not connect it". I take our NC type to only mean the second (hence the ERC error).

We might want a new type for pins that are allowed to be connected anywhere. This would address the concern in the part you linked.

[Wayne Stambaugh (stambaughw)]

On 11/6/19 2:27 PM, Seth Hillbrand wrote:
> The problem is that there are two types of NC. The one in your issue is
> when NC on the sheet means "it doesn't matter where you connect this
> pin". Then there is the type where NC means "this pin is used
> internally and you _must_ not connect it". I take our NC type to only
> mean the second (hence the ERC error).
>
> We might want a new type for pins that are allowed to be connected
> anywhere. This would address the concern in the part you linked.

@Seth, wouldn't this be a passive or undefined pin type?

[Seth Hillbrand (sethh)]

Unspecified is currently closest. None of the electrical types currently allow arbitrary re-netting in pcbnew, so if we're going to permit it with a current type, I'd say unspecified is our best option.

[Rene Poeschl (poeschlr)]

Unspecified currently always creates an error. I think that one is meant for making generic symbols for reconfigurable pins where the library team wants to ensure the user then specifies the correct pin type with a project specific symbol. (beneficial in a strict workflow where bidirectional is not good enough for gpio pins)

So a new type might actually be the best choice. The current NC pins would however need to map to the lenient type (on v6 import) not the one that does not allow connection at all.

[Rene Poeschl (poeschlr)]

Mabe the type names could be "not internally connected" vs "Do not connect"

The latter being the one that would not allow connection at all (not even within the equivalent to the current stack).
The former would allow connection but would not complain if left unconnected (A stack equivalent of this type would however still require connection. Otherwise, we would need a third type for compatibility with anything before version 6)

[KiCad Janitor (kicad-janitor)]

KiCad bug tracker has moved to Gitlab. This report is now available here: https://gitlab.com/kicad/code/kicad/-/issues/1826