Mailing list archives : pcb-rnd

ID:2496
From:ge...@igor2.repo.hu
Date:Sat, 1 Dec 2018 17:23:06 +0100 (CET)
Subject:Re: [pcb-rnd] drc: new DRC dialogs, drc is safe to use now
in-reply-to:2495 from Alain Vigne <al...@gmail.com>
 
 
On Sat, 1 Dec 2018, Alain Vigne wrote:
 
>My point is : previously, you had a fix image, now a "dynamic" one.
>"the preview is automatically updated as the board changes, so it is never
>outdated." says the pool node.
>I do see cases where the "PCB choice" is better than the "never outdated"
>one...
>
>Now, as the view is "updated", the "fixed" information user might provide is
>even more relevant: you fix some violations, browse the list, see a DRC
>violation, but don't know where it is as the layout changed, and error might
>have been corrected.
 
Or the same situation with screenshot-like preview: you did change the 
layout already and it is showing a violation that you spend long minutes 
trying to find just to figure the preview is just outdated. I don't see 
this option better, sorry.
 
In both cases if you are unsure, you press refresh.
 
Supporting the screenshot version would be extra code, extra complication 
(both in the APIs and in the docs - it's not even possible at the moment 
with the APIs). I did think it over, and my conclusion was that it is not 
worth the complication. So no, there's no plan having that feature, sorry.
 
>You can reply me then : Delete this error with the Del. button.
>OK that is the new use case now, fine.
 
If you fixed something, press del. If you are unsure, you could press del 
too, and get it listed again if it exists, in a subsequent refresh.
 
>And I guess I will re-run DRC checks (refresh ?) as it is fast ? I don't
>know how fast or slow it is on "complicated" PCB. From Integrated Circuit
>dev. perspective, I just know we want to run as LESS as possible the DRC
>runs.
 
Human working hours are still more expensive than CPU cycles. So I 
recommend doing this method:
 
- iterate over all the violations
 
- if you find it and see how it went wrong, fix it and del it
 
- if you don't find it or don't see how it went wrong just del it
 
- once you are at the end of the list, refresh and repeat
 
This way you will be able to solve majority of the problems fast, with 
minimal brain power spent. After a few iterations you will have only a 
few, but hard problems left, that each needs more investigation. But at 
this stage it is unlikely you have tons of interfering violations.
 
I recommend really trying this on actual boards, and then see if the 
non-screenshot preview is really a problem, because playing a lot with the 
DRC this week my experience is that it is rather an improvement.
 
>      determine if
>      there's a violated gap, but it can't tell where it happened.
>      It's not
>      something that's going to change soon and it's outside the
>      scope.
>
>Will it be in the future ?
 
Yes, later on, when I remove this old, limited drc implementation in favor 
of a new, programmable/dynamic DRC (ddrc)^1. The current work of basic 
infra and GUI rewrite was a prerequirement. But I can't jump on it right 
now, because there are 1000 other things scheduled for this cycle - can't 
get stuck with DRC for more than a week.
 
So please be patient - this old DRC code was good enough for the past 15+ 
years, so it should be sufficient for another couple of months.
 
On the other hand I foresee xschem will be pulling the the ddrc effort 
within a few months. It's evolving fast, matching up the development speed 
of pcb-rnd. So all we need and gschem/lepton couldn't give us will be 
provided by xschem soon. It's relevant, because the ddrc is a very 
important glue between the sch and board, a whole new level of "specify 
design detials on schematics, execute/enforce/check on layout".
 
HTH,
 
Igor2
 

Reply subtree:
2496 Re: [pcb-rnd] drc: new DRC dialogs, drc is safe to use now from ge...@igor2.repo.hu