Well… seems 5.1.5 is no good for me. At first, this “weird angles” bug. Now I ran into another issue: with my new project I have routed few traces. Now there are segments that I cannot select for some reason. If I click on track, PCBNew does… nothing. No selection, no popup. Hit Del over such track and gues what… nothing. Like there was no track at all.
Trying to route another track part that connects to the strange one, and the layout editor snaps to the track end. I cannot force it to connect somewhere in the middle.
Now if I look for some “spot” where two segments are joined at an angle, I can have the “clarify selection” popup where I can select my problematic segment. I can then delete it and re-route this part, but this is really annoying for me.
There’s nothing obvious for the affected segment, the DRC does not indicate any violation.
Anyone noticed this? Win7/64 btw. Maybe some known bug report on the bugtracker?
The first page of the commit log shows what has been fixed since the 5.1.5 release on the 5.1.x branch
If your problem is not here, please file a bug report
Don’t know whats under the “Prevent extra selection” commit.
Could anyone try with my minimal PCBNEW file to see if one can select the horizontal segments of ZD1, ZD3 networks?
On 5.1.5, Win64 I can’t.select_trace_kicad_bug.kicad_pcb (33.4 KB)
I tried to download your pcb file but i just get redirected to a " Oops! That page doesn’t exist or is private." Site.
Can you check your Link?
I have the same error
There have been a few file extension related bugs on the new forum software, so could you try “zipping” it
I can select both.
But its awkward. ZD1 can be selected on both ends and ZD3 only on the left, from the clarify selection drop down menu.
I noticed that the two tracks are ever so slightly tilted (0.0003mm over ~25.5mm)and not horizontal. If you edit them to be horizontal, they can be selected normally again.
Yes I know they can be selected at the end, but normally they should be selectable when clicked at any part of the trace - e.g. in the middle (at least it is that way with other traces).
Tilted you say… possible its the effect of this “weird angle” bug introduced in 5.1.5. Anyway, such tilt should not prevent the tace from being selected.
Just checked: after I manually correct this slight tilt by entering equal Y coordinates for both ends of the segment, it can be selected “normally” - so the weird angle is the culprit here. However:
- why they’re tilted?? (probably the 5.1.5 Interactive router weird track angles bug)
- why can’t select trace with uneven coordinates?
I can confirm with 5.99.0-556-gb53501d8c on Windows 10. It’s clearly a bug and I don’t remember seeing a report about this. Please report it and attach the same file.
As a temporary workaround you can select the segment by drawing a selection box to the left (a blue, inclusive selection box) so that it crosses the midline of the segment.
Application: Pcbnew
Version: (5.99.0-556-gb53501d8c), release build
Libraries:
wxWidgets 3.0.4
libcurl/7.66.0 OpenSSL/1.1.1d (Schannel) zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.1.1) nghttp2/1.39.2
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
Build date: Dec 21 2019 22:14:29
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.71.0
OpenCASCADE Community Edition: 6.9.1
Curl: 7.66.0
Compiler: GCC 9.2.0 with C++ ABI 1013
Build settings:
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
The correct “canonical” link to the 5.1 log (gitlab, not github, although github should still be a mirror):
And to the bug database:
Unfortunately I can’t find a milestone for 5.1.6 in the bug reports.
The 5.1.6 milestone is here right now. The plan is to make these milestones into group-wide ones so that we have a single milestone to track the code and library issues.
OK just reported the issue:
The bug has been closed, but I only see commits to Master, although the bug is tagged for 5.1.6
It has happened before that a bug which affected both versions was closed after fixing it for only one version. Sometimes the fix is cherry-picked into the other branch a bit later. If it doesn’t appear within a couple of days, it’s worth commenting in the bug report.
As it was tagged for 5.1.6 in the first place, this would not be cherry picking, the commit was to the wrong branch, so I may have to submit a new bug report as the defect remains unfixed
In my opinion the commit was to the right branch, it just wasn’t applied to another right branch, and the report lacks another right version tag.
it depends on the situation whether some developer fixes 5.1 or 5.99 first and then cherry-picks the fix to the other. But finally the bug report should reflect both IMO.
I don’t know if the gitlab issue system could handle versioning for bugs so that it could be marked as affecting two versions and then marked as fixed for only one. At least as of now those situations are handled ad-hoc manually and therefore there may be inconsistencies. I suggest commenting on the same report.
I opened this discussion in the dev mailing list.
The bug exists in both 5.1 and master branches, therefore it is milestoned with the oldest release it exists in as per KiCad issue tracker guidelines.
In this case the fix gets committed to the master branch, then usually after a few days of testing in the nightlies (to make sure it doesn’t break anything major) it gets cherrypicked to the 5.1 branch.
There has now been a commit to 5.1.x to fix this bug, so can @fred4u try the latest pre 5.1.6 Nightly build to see if all is well now?
This may seem trivial, but where can I find the latest nightlies for pre-5.1.6 (and not the pre-6 nightlies).
I assume only several fixes are cherrypicked onto the 5.1.5 “stable” branch there, so I might give it a try.