X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Sun, 9 Dec 2012 04:24:07 +0100 (CET) X-X-Sender: igor2 AT igor2priv To: geda-user AT delorie DOT com X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu" From: gedau AT igor2 DOT repo DOT hu Subject: Re: [geda-user] Find rat lines In-Reply-To: <1355011808.19390.8.camel@localhost> Message-ID: References: <20121204183305 DOT 6b04c0dc AT jive DOT levalinux DOT org> <20121208112649 DOT 388a9d22 AT jive DOT levalinux DOT org> <1355011808 DOT 19390 DOT 8 DOT camel AT localhost> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Sun, 9 Dec 2012, Peter Clifton wrote: > On Sat, 2012-12-08 at 11:26 +0100, Levente Kovacs wrote: >> Please note that when I start to draw a line from a copper object, highlighting >> works as before. This might help find the problem. > > That behaviour was deliberately left, as it is required by > auto-enforce-drc. (You will also find the "Find" button in the GTK HID > netlist window still has the old behaviour too I think). > > > I have worked up a test-case for the original issue, and having looked > at it closely, one key issue we should fix is that bad rat-lines are > being added which compound the shorted mess. > > That problem has hit me multiple times: a mistake in a big board shorting gnd and vcc, two random orange and a lot of legal-looking green and rats. I think just looking at the current state it is impossible to decide which part of the connection is wrong (which object to highlight in orange). I mean sometimes I start moving a two terminal component along a trace: when I remove the coponent from it's original place I connect the trace over the gap and I intend to break it somewhere else to insert the component again. During this process I have a short which could be resolved multiple ways. The final resolution does not depend on objective data of the current layout (shortest paths, closest pads, etc), but on my plans about moving the component. However, if we rephase the question from "what causes the short" to "what user modification introduced the short", it could highlight something that may be useful in more often. Proper implementation would be complicated (need to save history of nets), but I see a reasonable cheat here: use the undo buffer. This assumes there was no short at a point after loading the board and the user is interested in which object he touched that first caused the short. Regards, Tibor