Floating Wire Warning in ERC

[Rene_Poschl]

@eelik

I don’t understand at all why junction dots are manual. They should be fully automatic

They are generally automatic in v5.

The manual tool might be left in to be able to connect a crossing that was originally meant to be not connected or was drawn such that kicad assumed it is not meant to be connected. (A point where two wires cross without connection converted into a junction where 4 wires meet.)

Another reason might be to protect against possible bugs of this new feature. Or simply because it was there in the past and removing it felt wrong. (Choose your poison.)

@nickm

But why was it added deliberately? Makes no sense, possibly was a mishap, user was interrupted by $whatever. So this should generate an error.

In this case it was done to generate the screenshot. As mentioned above: There is normally no longer a need to manually add junction dots unless you made a mistake while drawing the schematic. (Might speed up a fix as you only need to add a junction instead of removing the offending wire and redrawing it such that it connects.)

---

I am more and more convinced that case 2 should not be handled by ERC but by the junction tool itself. (would also prevent stuff like @Sprig showed from happening.)

[nickm]

@Rene_Poschl

Might speed up a fix as you only need to add a junction instead of removing the offending wire and redrawing it such that it connects.

Full acknowledgement. And I’d like to be able to manually add a junction.

With regards to DRC:
A misplaced junction dot is an error. No matter how it happened. And even if it should not be possible to make one. Maybe it came here by reading a schematic generated in an older KiCAD-version or some import?

I usually place a comment in code that does “useless” checks and it reads:
“// should not happen”

Better safe than sorry.

Nick

[dchisholm]

@jos

Case 0 should check out provided pin definitions are correct (i.e. no I/O collisions etc.) . . . .

Actually, all 5 of those cases passed ERC on my (rather old) version of KiCAD.

Going back to origins . . . . I was hoping @brandondrury (the thread originator) would tell us which of those four examples caused him to purchase a stack of coffee cup coasters rather than a pile of prototype PCB’s. As he wrote:

@brandondrury

I just received my non-functional PCBs in the mail today. After some investigation, I realized that I have a rather-overt mistake on my part in which a wire is floating and not connected to where it should . . . .

In my mind, any of the four error cases could arise as a reasonably intelligent circuit designer works at creating a schematic: adding symbols here, removing symbols there, re-routing a connection wire, deleting some other connection wire, shoving blocks of components around on the canvas, etc.

@brandondrury started this thread to ask if KiCAD had a feature that would prevent him from repeating this kind of error in the future. The answer is

Well, no, not at this time. The best you can do is supply certain strategic people with servings of their favorite malt beverages, in exchange for their not mentioning the incident to your boss.

In a case like this, where boards have been purchased and delivered, you have to allow for the whole purchasing department, receiving, incoming inspection, etc.

I suspect that my example Case 3 and Case 4 might be detectable by ERC without a major code re-write. I didn’t intend to re-initiate hostilities over the Junction Dot issue, but the dots DO provide a visual clue that Case 2 is an error. Case 1? That would require clairvoyance to detect as an error. As they say,

You can never make things fool-proof, because we fools are just too ingenious!

If @brandondrury was bitten by an error similar to my Case 3 or Case 4, I’d suggest that he submit a bug report asking for an improved ERC feature that can identify those types of errors.

Dale

[brandondrury]

Case 3 was the reason I created this thread.

Look in the KiCad demos folder for the video project

Indeed, the schematic shows the use of the green square in a professional schematic.

I’m confused about the difference between PTRDY- and PTNUM1. (bottom left). PTRDY- contains no square. PTNUM1 contains a square. I realize that the square can disappear if the label for PTNUM1 is moved a bit to the left. Is there any additional information the square passes on to the Netlist file?

I incorrectly thought the green square meant that there was no connection to the wire, but the square still exists if a label is added to some other point of the wire. I was under the impression that the idea was to remove all green squares from a finalized schematic.
I always shortened wires so that they would land exactly on labels.

So what, exactly, does the green square do?

[dchisholm]

@brandondrury

. . . So what, exactly, does the green square do?

It gives the designer a visual clue that something may not be correct. In my experience, the green squares happen when I’m moving the mouse too fast, and terminate a connection wire before it actually gets to the grid location of the intended connection. Green squares also happen when symbols have been created using a grid size which is not compatible with the grid size of your drawing.

EESchema has a dedicated symbol for pins and wires that are deliberately unconnected. Since the program developers provided the specific “No Connection” symbol, it seems reasonable (to me) that ERC should check for situations where that symbol may be missing.

Dale

[brandondrury]

This is why I’m confused why the video example still contains green squares. Surely, they are there for a reason.

If the green squares only indicate the potential for error, it seems there should at least be an option to include them in ERC. This is contrary to what Seth_h stated above.

Brandon

[Seth_h]

Why do green squares exist?

In the example above, you can see that there is a green square in the SDA line. The two lines are offset by maybe 1-2 mil. It is not enough to see normally when viewing a schematic but it is enough to disconnect the lines in the netlist. The green square creates a constant-sized visual indicator to the designer that something is not connected.

Now, the green square is an indicator but it doesn’t mean that there is an error in the schematic. Your net may be connected in other ways such as labels.

This is different from the “Not Connected” X. This it a notation to indicate that a pin does not connect to anything else on the schematic. As you see in the video schematic, an NC flag on the wires would not be appropriate because the pins do actually connect to other pins.

[brandondrury]

@Seth_h

The green square creates a constant-sized visual indicator to the designer that something is not connected

And that is how I view it.

@Seth_h

Now, the green square is an indicator but it doesn’t mean that there is an error in the schematic. Your net may be connected in other ways such as labels.

This is where the waters get murky to me. I’ve still not seen the functional benefit of leaving floating wires that result in the square boxes and am still scratching my head as to why a user would leave them in a schematic.

My particular approach of drawing schematics in such a way that the green boxes 100% indicate an error explains why I was disappointed when I missed the green box on my last board design and why it would be helpful to have the option to receive a warning in ERC.

I’ll put in the feature request. If the powers that be deny it, I guess I could try being careful for the first time.

[Rene_Poschl]

@brandondrury

This is where the waters get murky to me. I’ve still not seen the functional benefit of leaving floating wires that result in the square boxes and am still scratching my head as to why a user would leave them in a schematic.

Some people simply do not care about it. I personally place labels such that there is no square but other users might prefer to have a longer tail outside the label which will result in a square being shown. (Everyone their own)

[Sprig]

@Seth_h

Now, the green square is an indicator but it doesn’t mean that there is an error in the schematic.

Oh, YES IT DOES!!! indicate that there is an error in the drawn schematic, it represents a net to no-where.

KiCad developers currently think that this is perfectly acceptable practice?:

After losing the Junction Dots in my on screen schematic, my second most wanted feature in Eeschema is the ability to ENLARGE the Not Connected Square, and make it bold line, and make it a color other than green (as Green typically means Good to Go!).

[Sprig]

@brandondrury

I’ve still not seen the functional benefit of leaving floating wires that result in the square boxes and am still scratching my head as to why a user would leave them in a schematic.

Professional schematics, in the industry of my experience, do not have “floating wires to no-where”.

It is my opinion that KiCad should Flag these as errors; and I thought it used to.

[Seth_h]

@Sprig

KiCad developers currently think that this is perfectly acceptable practice?

No one said acceptable practice. That would be up to your employer. The dangling end does not mean an error.

Please note that adding an optional warning for this case is already in development[1] and slated for v6.

@Sprig

my second most wanted feature in Eeschema is the ability to ENLARGE the Not Connected Square, and make it bold line, and make it a color other than green

As always, please submit wishlist items to the bug tracker.

[1] https://bugs.launchpad.net/kicad/+bug/1826437

[nhatkhai]

Sound like below also relative to this issue:

Bug #1802008 “EESchema ERC did not flag loose hanging label” : Bugs : KiCad

[novaktamas]

IMO not a good example. Edge connector fingers must be a footprint. If they were simply made on wire segments, they would be covered by soldermask and not accessible…