ID: | 3910 |
From: | ge...@igor2.repo.hu |
Date: | Sat, 4 Apr 2020 05:26:54 +0200 (CEST) |
Subject: | Re: [pcb-rnd] please ACK your bugreports! |
in-reply-to: | 3908 from Gabriel Paubert <pa...@iram.es> |
replies: | 3927 from Gabriel Paubert <pa...@iram.es> |
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-47284208-1585970814=:10103 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Hello Gabriel, On Fri, 3 Apr 2020, Gabriel Paubert wrote: >=09Hi Igor2, > >First, congratulations on getting funded to work almost exclusively on >your EDA system. Thanks! >I've been silent for a few weeks, first adapting to confinement and >because right now I'm mostly writing VHDL code for FPGAs for 3 different >projects, having changed priorities (I was going to assemble a few >prototype boards at work and probably designing a second version of the >PCBs to fix the inevitable bugs on a board with ~500 components). 500 component boards, wow, no wonder you need all the optimizations in the= =20 code! >+ FEATURE: configurable layer keys plus {l l} and {l k} for next and previ= ous layer ml=3D3411 [report: Gabriel] > >FINE: I've not used it much, but it works as expected as far as I can >tell. > >+ BUG: changing padstack prototypes from the padstack editor dialog won't = set the board change flag [report: Gabriel] > >FIXED.=20 Thanks! > >+ BUG: bug_files/drc/ - redundant drc hits, see README there [report: gpau= bert] -> in the new drc at most 2 hits per short are possible: from the two= directions (two networks), because clearance requirements may be different= per net > >That one is going to take more time, I tried to run drc on my most >recent complex board and I got 23260 violations, taking ~2h20mn in the >process on a core-i7. I'm sure that I have to tune the settings for the >new DRC. So expect a follow up message when I find time. Or: - we still have the rtree imbalance problem that generally slows down the= =20 DRCs (sorry, I didn't yet have the time to go on with the debugging, it's= =20 a quiet complex problem) - the new DRC is not yet optimized Plus: - by default both the new and old drc are enabled, so running the thing as= =20 is will take at least 2x the time it did before; for large boards I=20 recommend turning off one of them - with the new drc you can manually run rules one by one so you can=20 measure which one takes a lot of time I am going to add a feature today to make the new drc remember last=20 execution time for each rule, that will ease these things. > >+ BUG: bug_files/arcedit.lht - grab the lower endpoint for move and it tur= ns the arc into 360 deg [report: gpaubert] > >- mostly fixed for the editing side, although here are still a few > surprises and/or inconsistent behaviour: it's unpredictable whether we > get either 360=C2=B0 or 0=C2=B0 when the mouse is released on the starti= ng > point, but it's a minor issue. > > Load the attached example file, move the upper left point of the arc > on top of the lower right: on the left arc, you get a 360=C2=B0 arc, on = the > right arc, you get 0=C2=B0. If you move the lower right point on top of = the > upper left it's just the opposite. The wireframe shown during editing > correctly indicates what will happen when releasing the mouse button. > > > What amazes me is that the only difference I have seen (there may be > others that I've missed) between the two arcs is that one has a > starting angle of -90=C2=B0 and the other 270=C2=B0. Thanks, this is something I also found, but after looking around in the=20 code a bit I accepted that behaviour: - when the two endpoints are the same coord, both 0 and 360 delta values=20 are valid solutions - both the 0 and the 360 are special cases; it is very easy to mess them=20 up when using the GUI, e.g. getting 1 instead of 0 or 358 instead of=20 360, because of grid settings and inaccurate placement. As an user, I'd=20 always use the property editor if I wanted to make sure I have 0 or 360=20 deg. So I think this is not a bug (not a feature either, just how it is) and=20 take the bug resolved. >- a remaining bug: edit one of the arcs, undo the edit, the enclosing > polygon is not refreshed on undo. Thanks, this is a new bug. Added to the TODO, will be handled soon. Best regards, Igor2 --0-47284208-1585970814=:10103--
Reply subtree:
3910 Re: [pcb-rnd] please ACK your bugreports! from ge...@igor2.repo.hu
3927 Re: [pcb-rnd] please ACK your bugreports! from Gabriel Paubert <pa...@iram.es>