Schematic junction implementation

[eelik]

The next is copied from https://bugs.launchpad.net/kicad/+bug/1842355.

I'm not sure if this is the right place to talk about this, but I find the concept of independent junction dot weird. Junction should be a property of two or more wires crossing (or endpoints touching, or endpoint touching another line) and there shouldn't exist any junction without two wire lines.

From the standpoint of implementation it may be easier to have separate junctions but they should very strictly depend on existence of a wire crossing. For example, instead of

junction: xcoord,ycoord

there could be

junction:
   wire: id
   wire: id

But at least, if they are separate independent entities, they should be updated very stricly with any change made to wires. The update mechanism should be "waterproof". I've seen different situations when junction don't correctly reflect changes made to the wires.

It shouldn't be possible to add junctions where there are no wires crossing, and there should never be need to remove junctions except from where wires are crossing. "Add junction" shouldn't blindly add a junction dot, it should only make a junction out of two wires crossing each other.

[eelik (eelik)]

Some problems: see the attached picture. The junction dot was added automatically by KiCad when I drew the end of the vertical wire close to the other wire, but not touching it. However, when I update PCB, the net tie doesn't belong to SOMENET. I removed the automatically created dot from the C1/SOMENET crossing. However, after an update C1 belongs to SOMENET.

These, along with freely floating junction dots and dots in wrong places, should be enough to show that the concept of junction is poorly implemented, or is basically wrong.

Even at the moment I don't see a theoretical reason why junction items should exist at all. Every time more than two wire endpoints hit the same coordinates there's a junction (or are there exceptions?). When a junction dot is added to a 4-way crossing it actually cuts wires to segments and there will be 4 endpoints in the same coordinates. Adding a junction dot to almost-touching wire endpoint/another wire doesn't necessarily connect those wires.

A dot could as well be a visual property of a point where three or more wire endpoints meet, or a visual property of a pin endpoint where it touches a wire. Every such touchpoint would be a junction.

If there are junction items in the file is a matter of practicalness, but they should be more like a cache for "real" junctions and reflect them in all situations, immediately and exactly.

The only place where I see possible need for junction items is like in the attached picture where cutting a non-90deg wire isn't possible. Even in that case it could be forced if the endpoint of the vertical line would have the property "forced junction". It would connect any nearby wires with some radius (IMO the radius should reflect the visual dot size).

In the end I don't care if the junction items are kept in files. However, as I said, it should be implemented so that the user need to handle only real junctions, not junction items or dots.

[Seth Hillbrand (sethh)]

On optional junctions:

The only reason to have junction items as user-generated content is because circuit diagrams exist to communicate designer intent with other designers, not just the layout program. Adding additional junctions can help to clarify intent even if not required.

Right now, we only have a single junction type, so it gets a bit muddled between the automatically added junction and a user-generated one. Altium solves this by having two: user-generated and automatic. The user-generated junctions are not cleared or added by moving items around. They exist as circuit elements independent (and have separate properties for color/size/etc). The automatic ones are (optionally) created by moving wires/components around. I believe that the automatic ones are also not saved in the schematic but I can't verify in the new binary form.

Zuken (back in the day) had a checkbox for making a junction persistent. So there were not separate components but had an additional property that prevented them from being removed.

I don't have a strong preference but I can see why Altium's might be favored by teams.

[Seth Hillbrand (sethh)]

On "watertight" updates:

One way to achieve this is to unify the undo/redo paradigm between eeschema and pcbnew. The eeschema method is much harder to get right and keep right because updates can happen in many different places. This is why updating junctions (which happens after every schematic change) can break in certain corner cases: the junction update code gets called by many, many different paths.

If we unify to the pcbnew paradigm, then the junction update can happen when we push a undo/redo commit to the schematic sheet and the call only happens in one place.

[eelik (eelik)]

Thanks for comments.

"The only reason to have junction items as user-generated content is"
"because circuit diagrams exist to communicate designer intent with other designers"

I don't understand, I see this as non sequitur. The clearest communication is either having dots in all junctions or not having dots at all (and having only 3-way junctions). There shouldn't be junctions in places which don't look like junctions and there should be junctions in all places which look like junctions. How "user-generated content" is related to that?

"Adding additional junctions can help to clarify intent even if not required."

Can you clarify your intent? I don't understand how adding an extra dot would clarify intent, if there are rules for what is a junction and what is not. Especially if there is an automatic dot in every junction anyways. Can you give some example?

[Seth Hillbrand (sethh)]

I'd rather not debate whether junction dots should or should not exist in a schematic. Or whether a specific dot is useful to the designer.

We should address any issues in netlisting of the junction dots. I don't see us removing the ability for users to add their own junction dots. The comments above were for how we might address the disappearing dots issue and keep the auto-junctions.

[eelik (eelik)]

Visual indicator of junctions or lack of them is a different thing and I'm not interested about it, if that's what you meant by "whether junction dots should or should not exist". I think my main point is I'm perplexed by existence of junction dots (sheet items) without junctions. What use case can they serve? In my experience they can only lead to confusion and mistakes. If a junction dot and a real junction are two different things, why not just use a graphic item. Having a junction dot without a junction feels like having a connection wire without a connection.

Maybe one big reason for my confusion is the current ambiguities in the perceived behavior in different situations. What happens may be bug or intented, I can't tell. You already saw my example above. I can have a dot without a junction or a junction without a dot. I can place a lone dot without any wires. On the other hand dots are destroyed when wires are destroyed.

Having a bugless or "watertight" implementation would help seeing the real logic (or maybe the lack of it) behind the feature.

I'm still interested about agreements (or disagreements) about the current logic of junctions. Am I correct if I suppose the following points about current behavior of KiCad as far as automatic junctions are concerned:

(0. Exactly two endpoints in the same location isn't a junction, it's a corner.)
1. There is always a junction (real junction, i.e. only one net) in a coordinate point where three or more wire ends are located.
2. There is no real junction in a coordinate point where two (or possibly more) wires cross each other but there's no end point of a wire.
3. A wire endpoint can't touch another wire in the middle of that another wire - when it's placed there the other wire is cut half and there are three endpoints, i.e. a junction.
4. A pin endpoint behaves like a wire endpoint - it cuts a wire if it touches it.

These can be boiled down to:
5. There's a junction always if and only if three or more endpoints collide.
6. When an endpoint and a point "inside" a wire come in touch by moving or placing one or the other, the wire is cut so that there will be a (automatic) junction.

[Seth Hillbrand (sethh)]

- Three or more endpoints create a junction
- One or more endpoints and a line create a junction

If KiCad creates a junction but doesn't join the nets in the netlist, that is a bug.

[Wayne Stambaugh (stambaughw)]

I'm with Seth on this. The only ambiguous case is crossing wires. In this case I would prefer that the user must explicitly add a junction when a connection is desired. Otherwise, crossed wires are not connected.

[eelik (eelik)]

@Seth: OK, so I have misunderstood the logic.

To be clear, I'm not for or against any use case, nor do I want to require anything. If the current tools and file items exist it's OK for me. I can of course just not use them, and what's inside the file doesn't bother me unless I some day try to write a script and junctions make it difficult for some reason or another.

There just are too many strange things in junctions that I don't understand what's intented behavior and what's a side effect and what's a bug.

For example, nobody commented the example which I gave as a screenshot. There is a junction dot but no junction, and junction without the dot. Are they how it should be?

Another example showing the ambiguousness of the idea of junctions shows up when I add a junction with the tool. I can add a junction in the middle of nowhere so that there's no wires, pins or junction there. Is it a junction or not? Why? What use case does it serve? Because I can add it I guess it's a first class citizen. But when I try to move it with M or G it disappears. Heck, if I even move a wire somewhere else, it disappears. This gives me a hint that it's not a first class citizen and its existence isn't wanted. And if I draw a wire which touches that junction it disappears. Another hint that it wasn't a junction and isn't wanted.

Do you now understand why I don't understand how junctions work and how they should work? There just are too many problems to find any logic behind it or even discuss about it. I feel we are not on the same page and talk about different things. The biggest problem is that the manual junction tool allows things which I don't think it should allow, and that I still don't see any use case for adding a visible junction which isn't a junction (I will accept any real-world use case and I'm curious to hear if anyone has one).

Of course there should be a tool which allows creating a junction where there are wires and/or pins and KiCad doesn't recognize a junction there automatically but user wants it. But this use case doesn't describe the behavior of the junction tool very well, although it can do that, too. At least sometimes.

Can you at least explain the goal of the junction tool, the reason for its existence, what it must be able to do and what it doesn't have to do?

[Seth Hillbrand (sethh)]

The junction tool originally existed to add the required junctions to a schematic.

Now that we add junctions to the schematic where required, the junction tool exists to add a junction where the user wants to force (in the case of crossed wires) or indicate a junction.

Junctions are automatically added and removed when a schematic element is changed. The add/remove logic is what I described in #7.

Junctions are not currently first-class citizens as they are actively managed by the system. There may be a wishlist item to prevent removal along the lines of what I suggested in #2.

The example you gave sounds like a bug. I obliquely referenced this in #7. If KiCad creates the junction but doesn't join the netlist, that is a bug. If you create the junction, it will only join the nets that exist at that exact point on the schematic. It may be a wishlist item to join all nets that visually overlap the junction.

[eelik (eelik)]

Here is a real world problem with junctions without dots: https://forum.kicad.info/t/nets-have-gone-haywaire/19418.

Otherwise, I have taken time to think about this a bit more. It's still a difficult subject and I'm not sure you have understood all I have said or asked. Probably my main points now are:

1. Now there can be junctions without dots and dots without junctions. Both cases are bugs IMO. As I said in the forum discussion, " A junction and the visual dot should be so tightly coupled that there’s no one without the other." At least for automatic junctions.

2. If (and only if) existence and non-existence of junctions can be logically derived from wires (them crossing each other, and wires/enpoints overlapping), there should be no need for independent graphical junction items. Dots could be just visual indicators of deducted junctions. As far as I have understood, junctions CAN now be derived from wires. Junction dot doesn't create a junction where there is no junction implicitly. (If the manual tool creates a new junction, it does so by editing the wires so that there's an implicit junction.)

3. There shouldn't even be need to place *independent junction dots* manually. What the junction tool MUST be able to do is to create a junction on an existing wire. The only situations when this is necessary are these: A) When two wires cross each other without a junction, and the user wants to change that crossing into a junction. In this case the tool cuts the wires so that instead of two crossing wires there will be 4 wires, and there's an implicit junction. B) When two wires almost but not quite touch each other. As far as I can see this would be the only situation when an explicit independent junction item could be needed. But it doesn't work right now because the dot doesn't create a junction when the wires don't touch.

The point 1 is the most important. The point 2 is more about the implementation. So is the point 3 which is less important. So, I wouldn't oppose having forced manual junctions like described in #2, provided that automatic junctions/dots would work independently.

I'm not sure we would actually disagree on anything if we would understand each other. I understand #7 and agree with #8.

What I don't yet understand is if anyone actually thinks that the user must be able to place junction dots in places where there won't be junctions. I didn't understand what Seth said in #2: " Adding additional junctions can help to clarify intent even if not required." I don't see how adding a junction dot to somewhere where there isn't a junction helps. Or I misunderstood the sentence. Nor do I understand "or indicate a junction" in #10. If there is a junction, shouldn't there be a dot already? And if there isn't, why would a user want to add a junction dot there?

[Seth Hillbrand (sethh)]

If there's a specific issue with a specific version, then it would be helpful to post a new bug report with that information that we can fix.

[eelik (eelik)]

Done, https://bugs.launchpad.net/kicad/+bug/1848450.

The forum discussion about that specific situation had some intersting details. Rene Pöschl's opinion was that as long as there are independent junction items in files KiCad should be able to fix files which have implicit junctions without dots.

In my opinion the *absolute minimum* is that KiCad can't create a file where there are junctions without dots. In the implementation level the minimum which can guarantee this (also in the future, when other changes are made incrementally and there's a danger of "code rottting") is a "watertight" updating of junction items mentioned above by Seth. I still think that even better solution would be to at least make difference between automatic, implicit junctions where dots would be only a visible feature of such implicit junction, and explicit, forced junctions where a junction item would create a junction with all wires within its range.

Even more radical change would be to get rid of all junction items (in file format) and make a forced/manual junction a feature of a wire end. As far as I can see there can be no situation where a junction doesn't involve at least one wire end. Such a wire end would be always be marked with a dot and the junction/dot would follow the wire end when it's moved. That way the user could force a junction where the wires don't quite touch each other.

I still can't see any reason to allow "floating" junction dots or junction items which aren't involved in junctions (the exception could be a wire end manually marked as a forced junction; but even that could be automatically deleted when the wire is moved and isn't involved in a junction anymore).

[eelik (eelik)]

Another quirk came in the forum discussion. Seth said in #7 above:

"- One or more endpoints and a line create a junction"

This is true when drawing the wires, the junction is created automatically (is this what you meant by "create a junction"?). But it isn't true if I delete the junction dot. Two wires are left, the wire end is marked as non-connected and the wires belong to different nets. Why? I don't think that situation is wanted or needed. KiCad shouldn't allow deleting a junction from a 3-way crossing. There should be no need for having such independent wires which form a 3-way crossing, or is there any need which can't be fullfilled in some better way?

Again my understanding was shown to be incorrect. I thought that one or more endpoints and a line, or two or more endpoints, are always an implicit junction. But it isn't so.

[Jeff Young (jeyjey)]

In a crowded design the user might end up with the 3-way crossing unintentionally (for instance, by dragging another wire or component). One method of fixing it is to delete the junction dot and then drag the (now single) endpoint somewhere else. Without deleting the junction dot there are three endpoints there and they're going to drag all of them.

[eelik (eelik)]

Thanks for comment.

In that case I would just delete one of the wires and redraw it, but I can see how someone would want to drag just an endpoint.

Yet, your use case doesn't seem to work in practice. I can't drag that endpoint. In a 3-way crossing without a junction KiCad drags both wires. I don't find a way to drag only the endpoint. (In 5.1.4.)

[eelik (eelik)]

I found out that the continuous wire can then be dragged by grabbing it from somewhere else than the crossing. That wouldn't be possible with a junction.

But this isn't so important because the user at least can see that there's no junction because of the "no connection" box. Definitely the most important thing is that the junction dots (file items, if implemented as such) should always correspond with actual junctions and vice versa.

[Jeff Young (jeyjey)]

FWIW, the "can't drag it from the crossing after deleting the junction" issue was fixed for 6.0.

[eelik (eelik)]

Here's yet another viewpoint. V6 will have eeshcema python scripting API (if plans are realized). How is creating junctions scripted? It would be quite a big burden to require the script writer to take care of creating not only wires but also separate junction items. It would eventually lead to corrupt files where there are junctions without dots or other non-acceptable situations.

Rather, there should be a function which updates the list of explicit junctions by finding all implicit junctions. It would be called once when everything else is ready. Or would updating after each API call behind the scenes be possible?

But the cleaner solution would be to separate implicit junctions and junction items altogether so that implicit junctions wouldn't need junction items, yet would have a visual dot in the UI. Or get rid of the whole concept of junction items.

If a run-once-function is implemented it could be implemented in one way or antoher in the standard UI, too. Doing that in scripts would update all the junctions, anyways.

[KiCad Janitor (kicad-janitor)]

KiCad bug tracker has moved to Gitlab. This report is now available here: https://gitlab.com/kicad/code/kicad/-/issues/3429