X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Envelope-From: paubert AT iram DOT es Date: Tue, 18 Dec 2012 09:13:16 +0100 From: Gabriel Paubert To: geda-user AT delorie DOT com Subject: Re: [geda-user] Find rat lines Message-ID: <20121218081316.GB24102@visitor2.iram.es> References: <20121204183305 DOT 6b04c0dc AT jive DOT levalinux DOT org> <1355577174 DOT 24123 DOT 61 DOT camel AT thinkpad DOT richardbarlow DOT co DOT uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1355577174.24123.61.camel@thinkpad.richardbarlow.co.uk> User-Agent: Mutt/1.5.20 (2009-06-14) X-SPF-Received: 2 X-Spamina-Bogosity: Unsure X-Spam-Score: -1.4 (-) X-Spam-Report: Content analysis details: (-1.4 points) pts rule name description ---- ---------------------- -------------------------------------------------- -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 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 Sat, Dec 15, 2012 at 01:12:54PM +0000, Richard Barlow wrote: > On Fri, 2012-12-14 at 10:29 +0100, Levente wrote: > > I lost track of this thread, but I have an idea. I've seen this > > implementation in Zuzken CR5000 Board designer. Each copper object had > > an attribute called "net". When you place a track you could click on > > an object to connect to. This way, there is no need to do any graphs, > > etc. Just compare touching copper objects net attribute. If it is not > > the same emit warning. > > A few weeks ago I had to layout a board using Eagle, due to the project > already using Eagle. From my experience Eagle uses this method and I > found it to be extremely annoying to use. For the most part it was fine, > but the one thing that was very hard to do was place vias and then route > traces to/from them. It's fine if you're placing a trace and switch > layers; Eagle places a via and all the net attributes are correct. > However this isn't that great a work-flow if you're laying out a very > dense board, where you have to jiggle things around to get an wide bus > onto another layer. Eagle complains continuously about nets being > shorted. I've never used Eagle, but a long time ago I used a package that also insisted on giving a net attribute to every copper segment, and this was a nightmare. While not perfect, current PCB approach makes my life much simpler. > I also encountered other annoying situations caused by this manual > assignment of net attributes to everything, where I found myself > effectively managing the EDA's state for it, rather than getting on with > the task in hand. Exactly. > I find PCB's method of tracking connectivity to be less constraining and > allows for more varied work-flows. It's also closer to reality in that > ultimately what matters is the actual connection between things, the > copper doesn't care what net it belongs to. The only bad thing with > PCB's method is the highlighting of shorts and it seems that it should > be possible to preserve PCB's current behaviour while vastly improving > this using some graph theory. If at all possible I think we should > strive to keep the notion of copper being 'free' in PCB. 100% agreed. The only real issues with PCB happen when you create a short. And the really nasty problems only appear when you load a new netlist which modifies the partitioning of existing routed nets (accidental shorts during manual routing are easily found and fixed by undo, or using automatic DRC, but there are real life cases where you can't use it). Note that a non negligible number of the accidental shorts happen because the automatic rubberbanding sometimes does strange things. Gabriel