At least one problem with not rendering the “dangling end” is that the user can draw a dangling end and leaving it to be continued later, and still name the net/wire with a label. The fact that in the screenshot the dangling end is near a label shouldn’t affect the interpretation. KiCad has no way to know what you are going to do with it.
As has been said already, you can get rid of it by placing the label’s anchor to the end of the wire.
You do not have any electrical problems. You’ve given the net a name, and since ERC does not flag anything, it means this net is in fact connected somewhere else.
KiCAD will of course report an error if the label is in fact not connected to anything else.
These are all valid if their net names are connected to anything (in this case INA and INB are errors)
EDIT: In this case INA and INB should be errors!
Are you paid by Altium to post this non-sense?
Common sense is that dangling wire lines should be flagged by ERC. The discussion has NOTHING to do with some sort of personal preference.
Your comment is NOT correct. I can NOT know that is the intent when recieving a schematic from someone else.
The intent is to have that net be called MISO, and since there is no ERC then it is connected.
You would have to check that somehow, even if the wire was terminated on the label or not.
I’m not the one being wrong here friend.
I’ll let someone else step in. I’ve said all I have to say.
This is not how KiCad currently works. Many users prefer their schematics to look like @alexanderbrevig has them on the left side without the dangling ends being an error.
I of course understand that you want to avoid dangling ends and get an ERC error there, but again, this isn’t how it works currently (and that’s intentional and not a bug). I wouldn’t mind a setting to optionally create errors on dangling ends, but I feel like these squares are visible enough on their own and you don’t need an additional red arrow.
What I would like are rubber band wires from pins so that the square end can be moved in or out as desired, and then you could avoid dangling ends. This could lead to tidier schematics instead of pin wires being all one length, sometimes too long and sometimes too short.
Does your ERC really return ERROR for INA and INB pin?
In my case simply naming the wire produces no errors, although wire is not reallly connected to anything (There is only one pin with specific name). I’m using 6.0.
Fig. 1: Unnamed, unconnected pin, returns error
Fig. 2: Named, unconnected pin, no errors
Fig. 3: I noticed something was wrong when I was routing PCB 
Well. This is awkward…
So it seems we’re back to this then:
I almost exclusively use global labels and in fact use that warning as part of my workflow. I design pinouts in vendor software, then transfer everything to mCU with labels, and fill in in other schematic blocks.
I could’ve sworn that labels triggered the same warning, but seems like it does not.
I agree now, this is a bug.
I found the problem: eeschema/connection_graph.cpp · master · KiCad / KiCad Source Code / kicad · GitLab
It is by design, but I totally agree that this check should be for local labels too. Would be an easy fix, could also be behind a new settings flag? Are there any devs on here or should one reach out on gitlab?
EDIT: @Sprig would’ve saved us (at least me) a lot of headache if we knew from the start that MISO in fact was not wired to anything… .
I apologize for jumping to conclusions.
Local labels can also be used just to add a net name to a wire.
The wire can easily be completely visible, with no open ends.
In such a case there just is no 2nd local label with the same name.
Sorry for spamming, but I’ve had a think and I have realized that I use global labels as indication of connection. While local labels are net labels. Not really meant to indicate connection.
I guess this is the reasoning behind it, and because I do it without thinking I’ve never seen this before.
This will then lead back to the topic, and I do agree Sprig. The intent is hard to understand in your schematic.
Intent would’ve been clear with the proper tool, namely gobal labels.
EDIT: I’m back in the “no bug” camp.
But according to eeschema documentation, labels are used for creating local connections.
I think it doesn’t really matter if pin is labeled or not. If pin doesn’t have a complete connection, ERC should at least trigger a warning.
Flagging nets with only a local label (and no other connection - as shown by @ZeptoAto / @alexanderbrevig ) is already on the gitlab-wishlist:
I can’t believe V5 didn’t flag this an error. What about spelling errors? What about dyslexic users like me? I’m better than I thought. I’ve fabbed 7 or 8 boards with no misspellings on net names and no alzheimer’s forgets ?
Like;
mnm vs nmn
bad1here vs badIhere
I can’t even write this here without the spelling checker fixing half the stuff I say.
Unfortunately I’m having enough trouble with V6 that I can’t go back to V5 to check.
Hello,
I just did my first simple test layout with KiCad 6.0.0 and only noticed by accident that a signal was not routed because I made a mistake with a label (RESET instead of RESET#).
Please restore the behavior of KiCad 5.x. A warning was generated there.
Regards, Bernd.
Asking for it here does not help.
Following the link mf_ibfeew posted to gitlab and giving that topic a thumbsup does help.
Hello,
the attached Free Pascal program helps me to find “dangling” labels. However, this requires exporting the netlist in KiCad format. The program expects the name of the netlist file as parameter.
Regards, Bernd.
k6dangling.pas (906 Bytes)
Are there really two or more kinds of labels.
Sure, text labels are made with the T tool and are just annotation and have no effect on the netlist.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
