X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Fri, 14 Dec 2012 05:13:03 +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: <5AA18F19-2EA9-4E7D-9378-F768D8E1E5DD@jump-ing.de>
Message-ID: <alpine.DEB.2.00.1212140501300.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> <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> <5AA18F19-2EA9-4E7D-9378-F768D8E1E5DD AT jump-ing DOT de>
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 Fri, 14 Dec 2012, Markus Hitter wrote:

> Possible solution: instead of drawing tracks, board design starts with rat 
> lines. Like we currently have them. Then, these rat lines are - sort of - 
> pinned down to become, or being morphed into tracks. Perhaps with a tool 
> similar to how paths are edited in drawing applications. Add vertices, drag 
> these vertices, join them to forks, and so on, until the board is done. But 
> never disconnect a track in this process.
>

This is one of the many ways you could build your tracks. In some cases 
this is not the most efficient way.

Imagine a large city with a river cutting it in two halves. You need to 
plan your route from one end of the city to the other end, crossing the 
river. There are much less bridges over the river than streets on each 
side, and you sure need to cross the river which means you will walk one 
of the bridges. In cases like this it often simplifies the situation if 
you can pick one of the bridges and then route to/from the bridge on the 
sides.

In PCB I very often see a bottleneck, sort of a bridge over an obstacle 
cutting accrsoss my board, and I know i will be routing multiple nets over 
that narrow bridge. Often I prepare this while I am working on the 
obstacle and the bridge, for example placing a 1206 resistor and two, 
thinner-than-normal traces in between the pads, unconnected. For toner 
transfer this helps.

An other cases is when I have 2 parallel signal traces, goung around the 
whole board. I route them mostly as you suggest, building at the end of 
the current trace. However, when I reach the final destination, I figure 
it'd be easier to swap them (possible with or without back annotation of 
the change, for example at the last two pins of a SIP/DIP). In the latter 
case I first disconnect both long traces from the startpoint, connect 
them in reverse and the crossing rats are solved on the other end.

> This way, tracks are never disconnected from a net. Finding a short becomes 
> trivial. Probably a number of other tasks, like track length measurement, too.

Yup, if you choose to live with that restriction. If you don't, and want 
to delete objects from the middle of a trace and rewire things, it would 
break. My personal opinion, as a PCB user, is that it'd be a inconvinient 
feature considering the methods I use for designing my boards.


On the other hand, when you connect two tagged nets, it could show the 
short at the point they are connected; this very same feature can be 
produced with the historic approach (bisecting the undo buffer). Tagging 
does not solve the same problem as the historic approach can't: what if 
the netlist changes?


Regards,

Tibor