Right. everything was going relative smoothly until I tried to route J1 and discovered mangled net allocations!
I now have 2x LCD_D5 and that means that the LCD_RS on pin 11 is gone! Same with LCD_D6 and LCD_D7 all are now LCD_D6.
These nets only involve U9, J1 and U13 (SAMC subsheet).
I am baffled and extremely worried. How can this possibly be happening?SLKCD012.zip (166.5 KB)
What happened is that the connection between U10/14 to U11/14 got linked to LCD_D5
Remove those and connect them new. Thatās all.
Do you mean U13? I donāt understand. each net goes to a separate pin of U13, how can this happen or is it some sort of bug?
I donāt understand, either, because I canāt see by any means that those U10 and U11 pins would be linked to LCD_D5.
Thoroughly check that criss/cross section between U10 and U14 on the main sheet.
There is another link betwen LCD_D6 and LCD_D7 as well.
Just remove them and connect new. You must however pull the connection wire in one go from U10/U14. If you stop in between that will result in a connection to wherever you stop.
I suggest to do the vertical wires first, then pull the horizontal ones all the way across from U9 to the labels.
AFTER that you place the dots.
I see, so itās a bug. I did indeed redo those links a couple of times but unless they have a junction dot on them this should not happen.
You are right. Could be seen as a bug.
A junction should never lack a dot (if the dots are visible at all). In my opinion this is a serious bug.
Highlight wires does the trick.
first thing you learn about drawing schematics is how to clearly illustrate crossing wires and junctions. In the early days you showed one wire jumping over the other with wires that simply crossed being junctions. At some point dots for junctions became accepted and wires simply passing were not joined. This is the very basis of schematics and KiCad should be coded such that only dots make up a junction not the coincidence of 2 or more wires ending together. I see where it arises from though. If i continue a line rather than do it all in one place would I then need to put a junction in the middle of the wire? The code needs to differentiate between 2 wire ends at the same coordinates and more than 2. 2 = joined/same net, 3+ = not joined and different nets unless a junction dot is placed. A fairly reasonable oversight i guess.
Yes, as long as you are aware of that feature and remember to use it.
In 5.99 ERC warns about net name clashes, it could help, too, but itās not for production work.
You mean highlight net? yes thatās a good tool.
That would appear a workable fix.
It is the ālogicā the software would have to run through to differentiate a segmented wire from a junction.
Oh, itās on a wish list, not important at all 
Probably because there wasnāt one single bug pointed, I just complained about the overall difficulties. You could report this specific situation as a bug, maybe they listen better with a clear use caseā¦
For two wires it gets a bit tricky.
The logic of creating a junction automatically isnāt so much of an issue in my opinion. The big problem is that there is an automatic junction without a dot. A junction and the visual dot should be so tightly coupled that thereās no one without the other. Thatās my main point in the bug report, although it was beried under other questions and complaints. Under the hood I didnāt understand why junction dots should be file format items at all, because logically junctions could be derived from wires. A visual dot could be just a visible result of that logic. Is there a junction in this wire crossing? Yes->draw a dot, No->donāt draw a dot.
No itān not a difficult thing to work out. Itās not about the wire direction only the coordinates of the end. If 2 wire ends share the same coordinate they are the same net. If more than 2 wire ends share the same coordinates they are not the same net unless there is a dot. I think the issue might arise in the code that automatically puts a dot on a T-junction.