No, it’s vice versa. If more than two endpoints of wires share the same coordinates they belong to the same net, always and automatically, whether there is a dot or not. @Seth_h said in a comment in the bug report:
- Three or more endpoints create a junction
- One or more endpoints and a line create a junction
The lack of a dot is the problem here. There should be a dot there because there’s a junction.
Well yes it’s do they need to fix how junctions are created or whether or not to show a dot.
Showing a dot, in my opinion. It would be possible to change the junction logic, too, but it would be more radical move. The current logic is good IMO, but the visual dots should follow it.
BTW, your problematic wires can be fixed by first adding dots manually and then deleting them. Deleting the dot removes the breaks in wires so that they cross each other without overlapping endpoints, i.e. without an implicit junction.
Do you remember how you created those unwanted junctions? I can’t find a way to create such 4-way dotless junctions.
I got muddled up as to what was going where, so I did end up with wires that were supposed to cross being two wires that met and one going through them.
But how exactly did you create them? I can’t find a way to create such junctions so that there would be no visible dots.
This would be important for a bug report. I can file a report but it would be good to get more information about the steps which can reproduce the bug. The end result is of course visible in the file, but I’m very curious how that came up. It may help fixing the bug.
A first step would be if @Sparky_Labs could post their kicad version string via help->about kicad->copy version info
I can give version information, it’s not a problem, because I already confirmed the problem with a post-5.1.4 nightly build and a 5.99 nightly build.
It’s the latest stable download.
i can’t complenely remember how I created them. I think I may have deleted the dots and put new ones in.
Well the question is which version allows this problem to arise not which versions display it as designed. As you could not reproduce the original problem maybe something has been fixed in nightly that is not fixed in stable.
I didn’t think it that way. But there’s a bug anyways because KiCad should show a dot if there is a junction. And that’s weird, that it doesn’t show the dots, but I don’t find a way to create such a junction. It would might just be easier to find the root of the problem if the steps would be known. But the bug in graphics can still be found.
I doubt it is a graphics problem. Dots are after all part of the file format right now (Format as far as i can tell: Connection ~ x y).
So my guess is that the renderer simply places a dot where the file format tells it to place one. (V5 uses the V4 file format but got a bit smarter about junction dots while the user draws the schematic.)
One of the phantom connections is at 4200 3250. There is no “connection” line in the file for this junction. It would be beneficial if it could be determined how this could have happened (this is why the version string of @Sparky_Labs is important)
I use 5.1.4 stable and if I trigger the connectivity algorithm to update this junction (for example by grabbing it and moving it 50 mil to the right) then it gets a dot (and a respective line in the file).
Grabbing U10 and moving it 50 mil upwards generates quite a few new junction dots. (As it triggers the connectivity algorithm to update all connected wires)
One could argue that kicad should be able to fix damaged files (I assume this is what you are after - here the kicad version of @Sparky_Labs is indeed not important).
I can think of three options on how this can be done:
TlDr: There are two bug reports possible. One that investigates how the file ended up in this state and one that deals with how kicad should deal with files damaged in this manner.
Maybe a third one asking for the removal of the “connection” from the file format as the dots might be best calculated based on how the connectivity algorithm would generate the netlist for pcb_new.
Yes, sorry, I was vague. By “graphics” I meant (graphical, visual) dot vs. an implicit junction.
I can see only one good option, namely that KiCad can’t create such damaged files. That would be “watertight” or “waterproof” updating of dots which was mentioned in the bug report 1842438. Being able to repair bad files would be nice, but if KiCad would work correctly that wouldn’t be needed (as far as I know the developers aren’t very willing to take care of results of faulty scipts or hand editing which can lead to broken files).
That case is handled by many SCH programs having a background simple automatic redundant corner removal.
ie you may create a line in many steps, but the SW auto-cleans it to be a single segment, where possible.
Some SCH pgms also do a connect-on-touch, that can split a line and add an end-point where something new connects (usually with a dot).
Maybe the auto-corner removal I mention above, is enough to push the risk of this down into the noise ?
It seems leaving hidden and surplus line-ends in a design, is exposing things to later problems, should another line be added/moved to intersect that ‘dormant’ junction ?
Point 1 i never argued against that. (There is a reason why i asked for the kicad version of the person who created this file.)
Point 2: As long as the connections are in the file format there are ways to get such a damaged file. It could simply be by having some external tool delete such a line (imagine a git merge that goes wrong). Also consider opening a version 4 file where the user was fully responsible for managing junction dots.
Meaning kicad should have a way to fix such “damaged” files. (Assuming v6 does no longer store this info in the file then it would still need to have this fix algorithm as part of the legacy file format.)
Application: KiCad
Version: (5.1.4)-1, release build
Libraries:
wxWidgets 3.0.4
libcurl/7.61.1 OpenSSL/1.1.1 (WinSSL) zlib/1.2.11 brotli/1.0.6 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) nghttp2/1.34.0
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.68.0
OpenCASCADE Community Edition: 6.9.1
Curl: 7.61.1
Compiler: GCC 8.2.0 with C++ ABI 1013
Build settings:
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_PYTHON3=OFF
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_USE_OCC=OFF
KICAD_SPICE=ON
I think we agree mostly about everything. I’ll leave it to the developers to decide if KiCad should fix files damaged by other programs. But you have a good point there.
Thanks for the input. Even this short discussion shows how complicated the whole junction thing is. It touches several areas: UI, visible elements, invisible logic, data structures, file format, several algorithms, other programs etc., and it’s difficult to say what a bug actually is and what should be changed. I think in this case only the end result (“broken” view which doesn’t show junction dots where there should be dots) can be reported. And leave it to the developers to decide how to fix it and what to fix.