www.delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2015/02/16/23:46:12

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Tue, 17 Feb 2015 05:44:57 +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] Star connection points in PCB?
In-Reply-To: <201502170248.t1H2mgtn024098@envy.delorie.com>
Message-ID: <alpine.DEB.2.00.1502170533380.7324@igor2priv>
References: <1502170242 DOT AA18887 AT ivan DOT Harhan DOT ORG> <201502170248 DOT t1H2mgtn024098 AT envy DOT delorie DOT com>
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 Mon, 16 Feb 2015, DJ Delorie wrote:

>
>> all is bad too for those special nets.  But I might be totally off-
>> base here, not having looked at the code at all yet.  Anyone familiar
>> with PCB's handling of shorts who is reading this - is my idea on the
>> right track or totally off-base?
>
> We can't even tell you where existing shorts are *now*.  I suspect any
> work involving shorts will need the code replaced to use a different
> algorithm which gives us the information we need.

I think my mincut thing more or less solves it without replacing find.c.

Check the examples at http://repo.hu/projects/pcb-rnd/mincut.html

(Note: there's still a bug, find.c highlights two pins of the nets that I 
don't yet unhighlight - in these simple test cases this is annoying but 
it's easy to ignore them on a bigger design)

The idea is that the true location of the short is impossible to detect 
because it depends on the intention of the user and iformation that exists 
only in his head. For example a sequence of planned edit operations, some 
causing temporary shorts that will be resolved by later operations. My 
typical example is when I have a bus and have to shift connectors on both 
end by one to make room for another trace in between two existing traces 
of the bus - instead, I just add another trace on one side and shift the 
traces on both ends so at the end I have a trace in the middle that was 
originally connected to the connectors but is now unconnected on both 
ends.

In my opinion the next best thing is to find the part of the short that 
can be solved by remuving the least number of objects. This can be 
achieved with a minimum cut on the graph of the two networks. Since using 
this patch, I found that most often it highlighted the spot I needed; when 
it didn't, the original PCB code wouldn't have done a better job.

Back then when this first came up a few years ago, there was a long debate 
on the mailing list; other solutions I found viable included tracking the 
history of edits to determine how they led to the short.

Regards,

Igor2

- Raw text -


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