Wish: Eeschema: Hidden net labels

Description

When working with confusing circuits, or when building a board in steps (small chunks of schematic, then F8, some routing, then more chunks of schematic, F8 again, etc..), i often use local net labels, not to connect two things on the same page without a wire, but just to put a Name to the nets so that i can see what's what during the routing, and/or to be able to use NetClass or Fill Zone.

Legit Label usage, connects two or more things without a wire:

Labels only used to Name the net:

I wish there was an alternative visual mode for the local net labels, where they become less visible and perhaps smaller, with the option to show/hide them (similar to hidden pins), and which would NOT be plotted in the schematic.pdf (or at least not by default).

Why:

1. Some (local) nets are important, it's necesairy that their label is shown in the .pdf, thus i reserve enough space for those labels to look good.
2. Some (local) nets are less important, i don't need the label in the .pdf, but i still want to have a Name for them, i would prefer this to NOT take too much extra space or clutter the schematic display.
3. Other (local) nets are not important, no need to Names/labels on them

The problems:

Right now in KiCad v5, i just put net labels for both cases.

Places where this happens is for example:

• Switching regulators sub-circuit in a Hierarchical sheet, i use local net labels to put names on Feedback/Compensation/Dividers/HighSide/LowSide nets and other such nets which require more caution, and these often need a NetClass and/or a Fill Zone. Using normal net labels for all of these makes the circuit big. Many of these labels could be made "invisible".
• Audio sub-circuits with OpAmps and passive components, i use local net labels on most nets because NetClasses, and because Feedback signals are typically more sensitive so i want to see their names during routing.

Unfortunately, using normal net labels for everything makes the schematic more crowded-looking when i have labels on the "less important" nets.

NOTE: Those are labels on nets intended to only put a (stable and meaningful) Name, they do not connect multiple wires/pins together, thus i could remove them, but i won't because without a Name, these nets will get auto-generated names (like Net-(D41-Pad2)), and those are a problem whenever you re-annotate the schematic, since D41 might become D39 then, and any NetClass or Fill Zone associations get lost.

Invisible net labels

Here's what i suggest:

• A way to make "less-visible" Net Labels

• normal labels are black, this one could be gray (tho this is gonna be subject to the theme/colors, so maybe it can be the same color as hidden pins on symbols)

• maybe the Text Size should be smaller (half size, so 0.635mm), since inside Eeschema, you can normally zoom in-out no problem, while zooming in a .pdf viewer is less fun and this label isn't supposed to be shown in the .pdf at all.
• Same behavior as normal Net Labels (puts a name on a net, local to the sheet).
• An Eeschema option to toggle the visibility of these "invisible" Net Labels (similar to the option for hidden pins), default should be "visible" (with their gray-ish color)
• These "invisible" labels (or labels with this "invisible" property enabled) shall not be plotted to the .pdf.

Perhaps this could be added as a mode/property to the normal net label, thus a checkbox in the Label Properties dialog "Visible".

Example image (Hidden labels shown):

Steps to reproduce

1. None, this is a wish

KiCad Version

Application: Eeschema
Version: 5.1.12+dfsg1-1, release build
Libraries:
    wxWidgets 3.0.5
    libcurl/7.74.0 OpenSSL/1.1.1k zlib/1.2.11 brotli/1.0.9 libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.43.0 librtmp/2.3
Platform: Linux 5.10.0-9-amd64 x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.5 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24
    Boost: 1.74.0
    OpenCASCADE Technology: 7.5.0
    Curl: 7.72.0
    Compiler: GCC 10.2.1 with C++ ABI 1014

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=OFF
    KICAD_USE_OCC=ON
    KICAD_SPICE=ON

added priorityundecided statusnew labels

mentioned in issue #5838

I have had a use for this as well but I want to say that this needs to be thoroughly thought out before implementing.

I REALLY like how KiCAD uses labels to connect nets. I've used PADS Std/Std+ and now use Xpedition for work and they do this by having a net name property on each net. Sounds great, right? The one thing I hate about this is that you can have a net that is named, but the net name is not set to visible on schematic so you can have hidden connections that you might not realize. A thorough engineer will rarely have any problems with this (I never did, thankfully) but it's a risk that shouldn't exist, in my opinion.

Having the placed net labels is actually really nice since it's impossible to have a hidden connection. If these net names have no impact on connectivity, it should be clear to the user.

I think Xpedition has a note feature for nets where the schematic designer can put notes on nets for the layouter. I have not used this specific feature yet. I think that may be a good feature to implement (a note property for nets?) that could be helpful for this. Or both of these could be implemented since the note property would presumably not be shown on the schematic without clicking on the net. I think it should indicate on the schematic at a glance when a net has a note on it.

i guess:

"Invisible net label is meant to put a name on a net, not to connect multiple things toghether."

and:

"If an Invisible net label ocurs more than once in the same level (schematic hierarchy), or has the same Name as a visible (normal) label in the same level => ERC Warning."

changed title from Wish: Eeschema: Invisible net labels to Wish: Eeschema: Hidden net labels

changed milestone to %7.0

assigned to @jeffyoung

added prioritywishlist label and removed priorityundecided label

changed milestone to %7.0

and i want to add, in case things change, i'd like this scenario to be legit and not trigger ERC:

if not for the normal local label, then at least for the hidden net label

mentioned in issue #10793 (closed)

mentioned in issue #10757 (closed)

unassigned @jeffyoung

removed milestone %7.0

added feature-request label

mentioned in issue #14590 (closed)

Having hidden net names caters for cleaner, easier-to-read schematics, while still helping by applying meaningful track and pin names during routing. I would then suggest that (net)labels always begin their "life" by being visible, and can then be made invisible by intent from the designer. Thereby the responsibility for not creating unintentional net connections lie upon said designer. Further, there is no such thing as "unlabelled" nets, since KiCAD creates auto-generated names for all nets. Those names are invisible in eeSchema, but visible in PCBNew (like it or not). So perhaps one solution would be to allow the user access to modify those auto-generated names to their content? Of course guarding that each name remains unique, or whatever requirements the underlying system may have. (My personal, perhaps provoking opinion, is that underlying system requirements should never hamper or constrain a user from doing a good job, merely guide and help them; even in ways beyond the initial design intent) The picture illustrates a typical scenario. The net labels DI/DO are clearly redundant, since the same information can easily be read out from the symbols' pin names. While in a dense PCB routing scenario, or even while making component placement decisions, such information is vital to the designer. By making it clearly visible in the right places (while hiding it when it's less appropriate), makes for an efficient design and routing experience, in my opinion.

assigned to @jeffyoung

We built a prototype of a separate type of label (using a Directive Label with a "Net Name Hint" field), but there was concern in the lead development team that it would lead to too much confusion about how net names were assigned.

We also built a prototype of primary/secondary "shapes" for net labels, but it wasn't felt to be a good return on investment.

Note: the first can be found at https://gitlab.com/jeffyoung/kicad/-/tree/netnames?ref_type=heads; the second at https://gitlab.com/jeffyoung/kicad/-/tree/labelshapes?ref_type=heads.

closed

unassigned @jeffyoung

Thank you for the information about how this matter has been approached, @jeffyoung . But I still feel this issues state is a bit unclear. Since you now closed it, should that be interpreted as "We hear you, but won't do anything about it (at the moment)", or "We're thinking about a way on how to implement it, but there are disagreements, so we're kinda stuck right now", or "This isn't much of an issue to start with, so unless more users chime in, we'll leave it as is" ? I'm just trying to see your standpoint in this. I do understand there are lot more urgent issues to deal with at the moment, and you have made a fantastic job this far - this is not a complaint in any way; but I'm trying to figure out if it's worth pursuing this further, or if this door is shut for the foreseeable future

I'd say it's closer to "We hear you, but won't do anything about it (at the moment)". There's also an element of "This isn't much of an issue to start with", though there's a bit of internal disagreement on that front.

Ok, with the risk of being seen as unreasonable (I hope I'm not), has the idea of having a simple "Show" checkbox in the Label Properties dialogue box, been on the table?

Yes, but it was felt that you could mimic that well enough by just setting a colour that is transparent. (The downside is that it would still be selectable.)

Oh, now I feel like an idiot Of course! That actually will do everything I want. I don't mind it being selectable at all. All I wanted was to get rid of clutter, and transparency will do just that. I can't see why I didn't think about it myself. (Others probably can) Thanks!

mentioned in issue #14646 (closed)