delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2012/12/14/12:11:05

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.ud03.udmedia.de; h=
message-id:date:from:mime-version:to:subject:references
:in-reply-to:content-type:content-transfer-encoding; s=beta; bh=
jjKXHmtt+r+L6hRTOUOQkcUM4HC1e3Sj0D6bohQCNZs=; b=Ubw+PmThPzYB2CaD
gAVez+/6f8HdoWldvr3OqnNfpb52S3OVkku7kef5wU8HEYWx8NlwmvPJy7AE2+/S
P27UtL6/YGG5SUdk8MfC3PApbN2M2TpBLAFrQw9dEkXJ6m3IRbk1ZRAwOfESkGbt
rkNwbhXnMdYkBR5YMVp1+BJfvHY=
Message-ID: <50CB5D82.8060507@jump-ing.de>
Date: Fri, 14 Dec 2012 18:10:26 +0100
From: Markus Hitter <mah AT jump-ing DOT de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; 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> <5AA18F19-2EA9-4E7D-9378-F768D8E1E5DD AT jump-ing DOT de> <alpine DOT DEB DOT 2 DOT 00 DOT 1212140501300 DOT 26605 AT igor2priv>
In-Reply-To: <alpine.DEB.2.00.1212140501300.26605@igor2priv>
Reply-To: geda-user AT delorie DOT com

Am 14.12.2012 05:13, schrieb gedau AT igor2 DOT repo DOT hu:
>
> 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.

For this case I'd see even more advantage when rat lines are supposed to 
be pinned down. You'd simply pin down the rat line on both ends of the 
bridge. After that, you have a track tagged to the net over the bridge 
and two rat lines for the rest.

With the current, non-tagging pcb, such a strategy isn't supported by 
the rat line optimizer. The optimizer doesn't care about tracks not 
connected to any pin, so the track over the bridge would be ignored.

> 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

That's true, this wouldn't work. Looks like automatic connection 
searching is still required, to be used in such cases.

- You disconnect one end: a rat line filling the gap appears.

- You disconnect both ends: two rat lines appear, the tracks keep the 
net assignemnt.

- You reconnect one end: tracks get assigned to the new net, these two 
short rat lines from before are replaced with one long, direct one.

- In case you reconnect something still connected to a pin of another 
net, it's marked as short.

Well, yes, that looks pretty much what others suggested before.

> If you [...] want
> to delete objects from the middle of a trace and rewire things, it would
> break.

Removing tracks would fill the gap with a rat line.


> what if the netlist changes?

Following the discussion so far, this is apparently _the_ problem to 
solve. If just the name of a net changes, it could be re-searched. If 
the name of a component changes, automatic detection is thinkable, too. 
If none of the trivial cases fits, ask the user for help / give him 
visual hints.

I could even think as far as automatic shortening of tracks connected to 
the wrong pin. Just enough to disconnect the pin. That's the strategy I 
currently use manually when resolving non-trivial shorts.

Am 14.12.2012 11:43, schrieb gedau AT igor2 DOT repo DOT hu:>
 >
 > There are some open questions
 > (what do you do with untagged objects and how it would perform
 > significantly better than other proposals - for the extra cost of
 > a lot of manual net attachment).

Clearly, requiring manual track tagging isn't helpful. This tagging / 
net attachment has to happen automatically some way or another. Pinning 
down rat lines would be one way for automatic tagging, another one would 
be, as others suggested, to find the tags by searching, starting at 
pins. So far I see two methods which could co-exist nicely.


Markus

-- 
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/

- Raw text -


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