| ID: | 3421 |
| From: | Gabriel Paubert <pa...@iram.es> |
| Date: | Fri, 27 Sep 2019 12:36:54 +0200 |
| Subject: | Re: "donut" rats (was: Re: [pcb-rnd] Connection find inconsistent |
| in-reply-to: | 3420 from ge...@igor2.repo.hu |
| replies: | 3422 from ge...@igor2.repo.hu |
Hi,
On Fri, Sep 27, 2019 at 09:19:15AM +0200, gedau@igor2.repo.hu wrote:
> Hi Gabriel,
>
> On Thu, 26 Sep 2019, Gabriel Paubert wrote:
>
> > Hi,
> >
> >>From what I can see, it only happens when the connections should be to a
> >plane. In this case the rats marker used to be a circle, but they seem
> >to have become very infrequent, which is sad since when routing I had
> >become accustomed to disregard the circles when placing components.
>
>
> Thanks, I've made some fixes in a series of commits ending at r27708,
> please test!
>
Tested, it works well enough as it is for my cases, thank you very much.
> Background:
>
> (please read carefully because I may have introduced some new bugs that
> we should detect before the release)
>
> The problem is a bit more generic than what you described. There are many
> cases to be handled and some cases that can not be handled at the moment:
>
> 1. connection point above a polygon on a different layer group than the
> polygon's: a line or arc ending over a polygon that should be connected
> should behave the same as padstack, producing a "donut" rat. It should
> work now.
Yes, and this was the most important case.
>
> 2. connection point within a polygon on the same layer group, sitting in
> a clearance, should produce a "donut" rat, indicating it's only the
> clearance that needs to be removed, but:
>
> 2.a. this will happen if the poly is fully enclosing the connection pont;
> in other words, the connection pont is sitting on an island-like polygon
> hole, and not in a peninsula
>
> 2.b. but will _not_ happen otherwise; especially if you draw a clearing
> line into a polygon and they should be connected, you will get a short
> rat line from the line end to a nearby poly corner that is part of the
> round clearance cutout
>
> 3. a special case similar to 1: we have polygon-clears-polygon, so in
> theory a poly-clearing poly inside another poly that it should connect to,
> would need to produce a "donut" rat, just like lines, arcs and padstacks;
> but I would find that too confusing so at the momeny any poly-poly rat
> is drawn as a rat line
Fine with me. In practice I avoid using explicit (non-padstacks)
polygons with polygon-clears-polygon flag set.
I never tested it, but what happens if two polygons (or a polygon and
a padstack) with this flag set overlap ?
The answer might well be: don't do that!
>
> 4. and we also have the text object, which is not really handled properly
> by find.c; eventually it will be (which will obviously break all the
> "place a text 'I' for connecting two nets without pcb-rnd know about it"
> kind of hacks for which we already have a proper solution). I didn't even
> look at how rats behave with copper text now, and I don't intend to do
> that until the big copper-text-cleanup that would happen some time in the
> far future
Absolutely fine with me. I never use such dirty tricks.
>
> The whole matter is way more complicated than it seems to be from user's
> point of view. The reason is that we have totally different data available
> when mapping a network with {c r} and when mapping a connection with {c
> f}, so there are corner cases which should not be.
>
I see.
> {c r} is the netlist code, {c f} is the find code. Basically the netlist
> code does a lot more, and knows a lot more about the situation, and could
> place the "donut" rats for 2.b. easily. But then find code would produce
> again the first bug you reported, not being able the figure where
> exactly the "donut" rat leads to: either jumping onto polygons that are
> really connected to different nets, and/or not jumping onto polygons that
> the rat was meant to connect.
>
> So at the end the problem is because some inherited broken concepts about
> how rats should work, which forces the find code to make guesses instead
> of just caching the results from the netlist code. Namely: find.c does
> geometric hops over rats, instead of simply being able to look at which
> two objects the rat is intended to connect.
>
> Almost every line of code got rewritten on the netlist side, but I didn't
> want to mess up existing boards so some of the original broken design
> concepts are still in the code. I will eventually get rid of them and rats
> will simply remember the objects they are connecting which will remove the
> guesses the find code needs to do now. Which means the extra info the
> netlist code has will be remembered by the time find.c runs, which will
> make it much faster and safer.
>
> However, this has effect on the file format too, and I will need to be
> very careful to maintain backward/alien-format compatibility.
>
Thanks for the explanation. Backward compatibility is important,
but ratsnest basically changes as soon as you edit the board, and it is
never used for physical (Gerber, etc) exports, so its persistence
across load/save is not critical in my opinion, and I would certainly
accept that a format change means that old ratsnest are ignored on load.
But it is the exception rather than the rule, all physical layers and
the netlist should be perfectly preserved across a trip to persistent
storage, even when you load a file written by a version from several
years earlier (with some tolerance for non-native formats).
> Conclusion:
>
> - for your original test case I do get "donuts" now
>
> - I believe you would get "donuts" for most legit cases now with your
> original board or other of your real nice complex boards
>
> - if you see some places where you, with human intelligence, judge that
> the "donut" rat would be reasonable but the new code still draws a rat
> line, it's most probably one of the corner cases where using the "donut"
> would mess with find.c - so there's a very high chance that it can not be
> fixed now (only long term)
>
> - I really really hope I did not introduce new bugs by this; if I did,
> please report them immediately; the fix I'd apply probably would turn off
> "donut" in some cases (which may include some legit cases too, if the
> broken and legit cases look the same at find.c)
>
I understand this concern. Right now it is much nicer for my use cases,
so I'm crossing fingers that you won't have to revert the changes ;-)
Best regards,
Gabriel
Reply subtree:
3421 Re: "donut" rats (was: Re: [pcb-rnd] Connection find inconsistent from Gabriel Paubert <pa...@iram.es>
3422 [pcb-rnd] poly-clear-poly detail (was: Re: "donut" rats) from ge...@igor2.repo.hu