Floating Wire Warning in ERC

Schematic
15

For me, junction dots are an essential information. They signal exactly what they are named after.
So case 2 is an error. There is no junction, so the dots were placed there with a different goal that doesn’t make sense.
Case 3 is an error, because the signal ends nowhere, but why is there a line? User has to correct that.
Case 4 is an error. A signal line without any signal has no purpose.

We sometimes do have brain farts, and I really like it if the CAD at least catches a few of them.
It has to be clear, precise and strict with the rules.

I see no reason to place junction dots or dead end lines on a schematic. It only confuses others and after a few years even you.

Nick

16

Case 2 can not “naturally” ocour in current kicad versions. Meaning it was delibriatly constructed using the add junction tool. Maybe the add junction tool could ask if one really wants to do such a thing. (Removal at erc run seems more like treading symptoms instead of dealing with the real problem. )

17

Be carefull when ranting about junction dots.
It is apparently a religious topic and it might get this thread blocked.

1 Like
18

From an electically consistent point of view it shouldn’t even be possible to place a junction dot on less than three wires.

If someone want’s a dot, an ordinary graphic primitive will do.

19

That’s OK!
But why was it added deliberately? Makes no sense, possibly was a mishap, user was interrupted by $whatever. So this should generate an error.
Automatically removing it during DRC doesn’t seem to be good to me. There is a reason why the dot was there in the first place.

Nick

20

I don’t understand at all why junction dots are manual. They should be fully automatic: they are in every junction and nowhere else, or just nowhere (depending on preferences). And of course not in pin/wire or label/wire etc. connection points. They should be a visual feature of wire/wire junction.

1 Like
21

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.)

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.)

22

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

23

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:

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. :beer:

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. :beers: :beers: :beers: :beers: :beers: :beers: :beers: :beers: :beers: :beers:

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

1 Like
24

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.

image
image1126×593 13.2 KB

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?

25

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

26

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

27

Why do green squares exist?

Not connected square
Not connected square2835×1503 36 KB

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.

2 Likes
28

And that is how I view it.

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. :stuck_out_tongue_winking_eye:

29

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)

1 Like
30

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?:
Silly

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!).

1 Like
31

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.

32

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.

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

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

4 Likes
33

Sound like below also relative to this issue:

34

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…

1 Like