Mail Archives: geda-user/2018/07/15/04:58:13
On Sun, 15 Jul 2018, Luis de Arquer (ldearquer AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:
> Hi Igor2,
>
> 2018-07-15 5:44 GMT+02:00, gedau AT igor2 DOT repo DOT hu <gedau AT igor2 DOT repo DOT hu>:
>
>>
>> Solutoin:
>>
>> This generic problem is well known in pcb-rnd and I have a plan for it: we
>> simply need to track two bounding boxes for every object. One is the naked
>> ("copper") bounding box that is the base object without any side effect,
>> and the other is the final bounding box, the object with all side effects
>> including clearance. We need to keep the second only for historical
>> reasons because the code depends on it everywhere. As long as the only
>> such side effect we have is clearance it is cheap to calculate: most of
>> the cases you just bloat up the naked box by clearance on all sides to get
>> the final box. Then each part of the code can decide which bbox to use.
>>
>> So in case of drc, we'd use the naked bbox and would add the drc
>> clearance on top of it.
>
> That would be a nicer solution. What about including a third bbox so
> that DRC code can store the bloated bbox? It may be useful to provide
> a placeholder to the DRC bbox, but only if it needs to be used many
> times over the DRC check.
At the moment I think the third bbox would be simply naked+clearance on
all 4 coords. That's too cheap to calculate. On the other hand if we start
caching it, there will be a few real bad corner cases when our cache would
go out of date - for example if you change the drc config.
Optimally I would have only one bbox, the naked one, and then wherever
it's just a +clearance, I'd do that locally. But we already have too much
code depending on the clearance-bloated bbox that such a modification
would be a big risk in stability. That's why I think we'd go with 2
bboxes.
Of course calculating bbox for a line object is cheap, so you could say
why not just calculate it in the drc from the line object itself, ignoring
whatever bbox we have stored. And that's true for lines - but it's getting
more expensive with arcs, padstacks and polygons. However, as far as I can
tell, the naked+clearance method would work fine on those too.
Bonus: the naked bbox update needs to be done exactly the same times when
the current bbox is updated, and that's not too often - so it's realtively
simple and risk-free to introduce it.
>> Approach #2 is that you have a board with different objects and you want
>> to fab the board. At the end, the dabbing process will go wrong (or at
>> least will get very expensive) if you have thin hair of objects (copper,
>> or even silk!) or you don't meet the minimal overlap.
>>
>
> In this case, DRC was complaining about a line clearance to a polygon,
> where both are actually connected. You can see it in the attached file
> (the line is actually made of two lines, one of them triggers the
> DRC). This may not be too good design for a PCB, but on non-trivial
> PCBs it is easier to have derived things polluting the DRC.
I can reproduce the warning, thanks.
I agree, this is a false positive and we should not have it.
>> Caveat/risk/challenge: the line end cap is a true half cirlce, while the
>> clearance arc cutout is emulated with straight line approximation (the
>> polygon code can't yet handle arc-in-contour). IIRC there's some
>> provisions for this in the polygon code, making the rounding in favor of
>> "rather staying farther than closer than the clearance", but we will need
>> to double check that. Worst case we can end up in a situation where the
>> clearance causes a 1..2 nanometer drc error because of the approximation.
>>
>
> For arcs the issues are the same, but to be honest I haven't looked into them...
Yeah, but above I meant the plain old straight line object end-cap, which
cuts out an arc shaped clearance in the polygon.
>>
>> If you say yes to commiting your drc fixes in pcb-rnd, I can add the
>> 2-bbox system in the code today/tomorrow, so you don't need to worry
>> about that part.
>>
>
> I'll do, sooner or later. However my time is very limited, so I can't tell when!
> We fixed PCB first as our company uses it in production and we needed
> the fix asap.
Ok, then I'll add the double-bbox system so you can work with it.
Regards,
Igor2
- Raw text -