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