|
From: Chad P. <par...@gm...> - 2019-09-29 19:20:49
|
I've been thinking about this some. Your original assertion that they should be ignored because such errors would violate the netlist, is a little bit problematic, because the netlist check isn't done by the DRC; it's done by the rat-optimizer. Additionally, the errors show up in the message window, not the DRC window. So, if you've finished your layout, you're probably not thinking about optimizing rats anymore, and you many not even have the message window open. Then you run the DRC and such an error would be easily overlooked with catastrophic consequences. The DRC does explicitly tell you do open the log and use the rat-optimizer, but I think most people read that text once, and then never look at it again. They probably just see it as a "cover-our-butts" message from the developers (which, to be fair, it kind of is), and pay it no mind. Yes, yes, it's fairly clear that this is a test that the DRC *should* do. I'm not sure why it doesn't. That could be called a bug in the DRC. My previous efforts were primarily focused of fixing what it already did, as opposed to adding new tests. So it didn't occur to me to do this. The other reason that I'm very reluctant to revert this behavior is that it creates a special case in the code. I've been trying to eliminate special cases, to the extent possible, as they generally make things less predictable and the code base harder to work with. If the code base were less convoluted, I'd be less reluctant, but in its current state, special cases are just waiting to cause trouble. The two actual solutions that I see to this are: 1) as Kaimartin suggested, to make the thermal tool work for pads. 2) extend the DRC so that you can specify different parameters for different kinds of objects. That would let you specify 0 for the minimum clearance on pads. Neither solution is trivial. Seeing as how I've actually started the first already, I suppose I will try to prioritize that. If you want, I can create a special branch for you in the git repo that reverts this behavior in the interim, however, I don't want to do this in the master branch as I don't think it's a good long term solution. --Chad -- You received this bug notification because you are a member of PCB Bug Team, which is subscribed to pcb. https://bugs.launchpad.net/bugs/1843834 Title: New DRC flags zero-clearance pads Status in pcb: New Bug description: As of version 4.2.0 my PCB layout has 176 new DRC errors. I have many pads which are connected to polys by setting the pad clearance to zero. The DRC previously ignored theses. I understand that this looks like a legitimate clearance violation but there is no way, as far as I can tell, to tell PCB that the connection from the pad to the poly is intentional. I believe the DRC should just ignore zero-clearance pads as it did in previous versions. If the resulting connections were errors, they would be detected as such anyway because they would violate the netlist. An alternative but less ideal solution would be to add a flag, say "noclear", that could be added to the pad to indicate connection to the poly was intentional. This is fairly easy to reproduce. 1. Start a new project 2. Add a poly rectangle on the top layer. 3. Add a component that has a pad. 4. Set the clearance of a pad to zero (Shift-K). 5. Run the DRC. See attached file. To manage notifications about this bug go to: https://bugs.launchpad.net/pcb/+bug/1843834/+subscriptions |