X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Message-ID: <50CB1C30.5050401@zepler.net>
Date: Fri, 14 Dec 2012 12:31:44 +0000
From: Chris Smith <cjs94 AT zepler DOT net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] Find rat lines
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>  <alpine DOT DEB DOT 2 DOT 00 DOT 1212090407031 DOT 26605 AT igor2priv>  <1355188647 DOT 12937 DOT 14 DOT camel AT localhost>  <A7B4EDBD-3704-4837-9350-A16559C60A2A AT noqsi DOT com>  <201212140010 DOT qBE0ABjV023762 AT envy DOT delorie DOT com>  <172CCAAB-0423-43EF-8A04-5A9961F1D5B9 AT noqsi DOT com>  <201212140122 DOT qBE1MoKM019255 AT envy DOT delorie DOT com> <1355450625 DOT 2993 DOT 18 DOT camel AT localhost>
In-Reply-To: <1355450625.2993.18.camel@localhost>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Reply-To: geda-user AT delorie DOT com

On 14/12/2012 02:03, Peter Clifton wrote:
> 
> It is really important that we can handle the "it's already shorted"
> case with the algorithm.
> 
> This is important for the reasons DJ mentioned (e.g. bulk moves /
> breakage), but ALSO, for netlist changes driven from the schematic.
> 
> Lets say I have all my ICs connected to a common power-rail, but later I
> decide to split some sensitive analogue parts onto their own rail,
> filtered with a pi-network or similar.
> 
> Bang.. all pre-assigned nets are wrong, and you get to keep the broken
> pieces.

I don't see why this is a problem.  A netlist change should surely
affect only pins, not existing track segments regardless of net
association.  The result would be that following a netlist update all
the changed pins would show as being shorted to the existing track
because the netname is different.

To resolve the newly identified shorts, the user would select the
appropriate tracks and change the net association to the new netname.
This should reduce the short to a single point where tracks for the two
power rails meet, and which is probably where you want to break that
connection to place a new footprint.

To my mind this seems entirely fair and reasonable.

Regards,
Chris
-- 
Chris Smith <cjs94 AT zepler DOT net>