| ID: | 3420 |
| From: | ge...@igor2.repo.hu |
| Date: | Fri, 27 Sep 2019 09:19:15 +0200 (CEST) |
| Subject: | "donut" rats (was: Re: [pcb-rnd] Connection find inconsistent |
| in-reply-to: | 3416 from Gabriel Paubert <pa...@iram.es> |
| replies: | 3421 from Gabriel Paubert <pa...@iram.es> |
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!
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.
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
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
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.
{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.
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)
Best regards,
Igor2
Reply subtree:
3420 "donut" rats (was: Re: [pcb-rnd] Connection find inconsistent from ge...@igor2.repo.hu
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