| ID: | 4368 |
| From: | ge...@igor2.repo.hu |
| Date: | Fri, 18 Sep 2020 05:17:19 +0200 (CEST) |
| Subject: | [pcb-rnd] upcoming change: show/enforce DRC clearance |
| replies: | 4375 from N <ni...@gmail.com> , 4379 from ge...@igor2.repo.hu |
Hi all, as part of the ongoing DRC upgrade, there is a part of the code that needs to change. This will probably affect a lot of users. If you ever used the features mentioned in tehe subject, please read this mail. I am planning to do these changes in svn HEAD this weekend, so there are a few days available now for commenting on them before the code happens and gets 'final'. 1. how the old setup worked The old DRC had 6 data fields and hardwired C code to check those few things that 6 data fields allowed. You san see still these fields in the preferences dialog, Sizes & DRC. They are already marked for removal, see: http://repo.hu/cgi-bin/pool.cgi?cmd=show&node=deprecation#olddrc That is because the new DRC is a much more flexible and modular system, where we can not really have a static number of hardwired fields to work from. The new settings are easily accessible both in the conf tree and ni the drc rule listing's 'Definitions' tab. (You canget to that dialog from the preferences dialog clicking the "drc_query" button). For compatibility reasons, some DRC rules can still pick up values from the old fields when there's no value defined in the new conf nodes. So if you load an old, pre-drc-query board, the stock drc_query rules will happily pick up those 6 fields from the file. We still have the preferences window section for editing those old 6 fields, but I am going to remove those now. The show and enforce drc clearance (in Mode menu, Routing submenu and Cursor/snap submenu) also works from one of these old values at the moment. 2. Why these don't work with the new setup The new DRC system is way more flexible than simply having a global "Minimum copper spacing" value. The stock DRC rules distributed with pcb-rnd releases emulate the old behavior, but the system is capable of much more: you can easily load extra drc rules doing extra checks based on whatever properties. For example we recently got a feature request for per network clearance checks in DRC. And we had a feature request that got implemented as a DRC script for zone based clearance: http://repo.hu/cgi-bin/pool.cgi?cmd=show&node=drc_zone_clr The new system can create new data fields in the conf system on the fly: when you load a new DRC rule that needs a few more settings, they are just created. That's why the old preferences window 6 hardwired fields need to be removed. The show/enforce DRC clearance needs to change too: with flexible rules, we can not point to a single DRC clearance value that needs to be universally shown/enforced everywhere on the board. The other problem is that the new DRC is more flexible, and can consider a lot of properties of other objects. For example with the above zone based DRC script to decide what would pass the DRC at the is not a local choice, but a global one, it depends on other objects (like the zone polygons) and we could figure that only by running the drc script. Furthermore the DRC scripts don't tell you how to draw things, they only tell you whether what you already drew violates any rule. This is an essential property of the design, this makes it relatively easy to describe real complicated looking rules in the DRC scripts. But this property also makes it unable to tell the code how near you can go with a yet-non-existing-object (the one you are trying to draw at the moment) to an existing object before you violate the rule. 3. What the new setup will look like The DRC & sizes tab of the preferences window will get much smaller, as those 6 data fields will be removed. I have't yet decided, but it's very likely that with those fields removed, you won't be able to control what DRC settings are saved in the old, alien pcb format. That means, if you draw a board in pcb-rnd and set up pcb-rnd's DRC for the checks, then you save your board in the old geda/pcb file format and load it with geda/pcb and run the drc there, it won't have the same result. I find this reasonable because the two DRC systems are totally different - the same happens with pcb-rnd -> kicad too, since kicad's DRC system is different from both geda/pcb's and pcb-rnd's. The "show/enforce DRC clearance" features will be renamed and changed to "show/enforce style celarance". I think this is the major change. It makes more sense with DRC replaced with the routing style: - While we are drawing, we can not enforce the actual DRC rules because of the reasons described above. So trying to depend on DRC values in any way there would be a lie: it would make the user believe we use the DRC to decide, and if somehting can be drawn with the "enforce DRC clearance" feature, that will surely pass the DRC tests, which is obviously not true when using complex DRC scripts. - All other indication while drawing are consistently showing routing style parameters - the clearance is the only part that is coming from elsewhere.... - ... which also introduces another incosistency: when your old DRC value "Minimal Copper Spacing" differs from the style's clearance value, what the "show DRC clearance" draws around your line will be different from what you get as actual copper distance within a polygon. - With the original system you could have only one indication, for the "Minimal Copper Spacing". That is fine for most 2 layer hobby boards, but for anything more complex, with different parts of the board having to have different gaps between copper features, it would render the indication useless. If we simply use the style's clearance, you can easily define as many styles as you want, with different clearance value, and have that way have different indication and enforcement. Of course the "enforce clearance" part will remain local, that is, it will make a decision based solely on the current style, while copper gaps happen between 2 objects. For example if you have object A already placed on the board and you are drawing object B, and A wants 12 mil gap (via net, zone or whatever method) while B wants only 8 mil gap, the indication will show 8 mil and the enforce will bump at 8 mil. Because locally, looking from B's point of view, that's the gap we need. Then when you run the DRC on the whole thing, globally, it will figure A wanted a bigger gap and will throw an error. This may sound inconvenient, but: - this is not new; the old system had this problem too, except you simply couldn't set up a complex DRC rule where this could be exposed - I have a long term plan for an alternative solution, see in the next mail Best regards, Igor2
Reply subtree:
4368 [pcb-rnd] upcoming change: show/enforce DRC clearance from ge...@igor2.repo.hu
4375 Re: [pcb-rnd] upcoming change: show/enforce DRC clearance from N <ni...@gmail.com>
4379 Re: [pcb-rnd] upcoming change: show/enforce DRC clearance from ge...@igor2.repo.hu