Mailing list archives : pcb-rnd

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>