delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2012/12/08/22:17:00

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: <alpine.DEB.2.00.1212090407031.26605@igor2priv>
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
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


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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019