| ID: | 3886 |
| From: | ge...@igor2.repo.hu |
| Date: | Tue, 31 Mar 2020 09:20:34 +0200 (CEST) |
| Subject: | [pcb-rnd] new: drc_query (part 2: call for ideas) |
| in-reply-to: | 3885 from ge...@igor2.repo.hu |
| replies: | 3894 from Hannu Vuolasaho <vu...@msn.com> |
Hi all, (please read the whole mail _before_ starting to write down your ideas!) so we have the new drc in a fully usable, beta testing state. What's missing: - some GUI features (but everything works from the cli/config files) - some low level accessor functions in query(), which I will implement as we find out what we need - rewrite of the old, hardwired C code DRC (plugin drc_orig) as query scripts for the new drc - this is being done in the background now Long term the only way to really exploit the possibilities of the new drc is to write new rules and share them, e.g. on edakrill, where I will set up a new krill type for drc rules. For the new rules, I want to collect ideas from the community. This is a call for focused feature requests and pondering about possible new drc scirpts. To avoid explosion of ideas and discussions that wouldn't get implemented at the end **** * I ask everyone to strictly stick to the following rules: **** - scope: we are collecting ideas for DRC rules - so not for gui, not how drc could connect to other subsystems or what else we could use drc for. It's really about actual checks you want pcb-rnd to perform on your board to catch errors - please write your idea only if you really want to use the result when it gets implemented; in other words: I am absolutely not interested in fancy, "would be cool, maybe someone would some day need that" kind of ideas, I have tons of those myself too. But I am very much interested in "I often do this chekc by hand now" or "I remember getting bitten by this kind of bug on my last board" kind of practical ideas that would result in a rule that _you_ are surely going to test and use. - but do not hesitate writing down wild ideas - we are not going to implement an AI, so it may be that after some pondering I'll just say we can't formalize the check and we can't check that from program code; but in other cases wild-looking ideas may turn out to be real easy to implement. So if you need a check, don't keep it back only because it sounds like impossible to implement! - please write ONLY ONE IDEA PER MAIL. This is very important if we want to keep track on ideas and discussions. I will simply ignore any mail/thread with more than one ideas. (You will notice that, because I will definitely answer any idea that is considered). - please give your mail a meaningful subject, starting with "drc: " - please throttle your ideas; if you have 10 or 100 ideas, please first send the most important 3 only (on per mail), then once we discussed and decided about them, send in the next few, etc. Don't worry, we don't have a deadline, we won't need to discard some of your lower prio ideas. This method is important to keep the mailing list relatively low traffic. - please use the mailing list for sending in your ideas; please do read the ideas sent by others - this is how we can avoid redundant/duplicate ideas! - if someone posts an idea that is very similar to yours, please try to think in the frame set up by the idea alreayd posted and post a reply to that thread explaining how the already posted idea could be expanded to handle your case - in general, it is a bit more useful to hear _what_ you want checked instead to hear _how_ exactly the check should work. Rationale: I've spent a lot of time designing, implementing and testing the query() language which is the engine of the new DRC. So I am in a very good position to decide how to translate from "what" to "how". If an unimplementable "how" is posted, we will first need to spend time on translating it back to "what" first (reverse engineering it) just so that I can do the what->how translation to the implementable form. We can save that extra step if you just tell what you need, not how you think it would be implemented. Example on a well formed idea (already implemented): " Subject: drc: overlapping holes My fab is mad at me breaking too many drill bits because of overlapping drilled holes. I want a test that finds holes that overlap more than a predefined percentage. " A possible answer that extends this could look like this: "There could be an upper limit on drill diameter tho: drills alrger than 5mm don't tend to break." Best regards, Igor2
Reply subtree:
3886 [pcb-rnd] new: drc_query (part 2: call for ideas) from ge...@igor2.repo.hu
3894 [pcb-rnd] drc: Antenna detection from Hannu Vuolasaho <vu...@msn.com>