X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Cam-AntiVirus: no malware found
X-Cam-SpamDetails: not scanned
X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/
Message-ID: <1356100142.17705.1.camel@localhost>
Subject: Re: [geda-user] Find rat lines - summary
From: Peter Clifton <pcjc2 AT cam DOT ac DOT uk>
To: geda-user AT delorie DOT com
Date: Fri, 21 Dec 2012 14:29:02 +0000
In-Reply-To: <20121221100329.GA4516@visitor2.iram.es>
References: <alpine DOT DEB DOT 2 DOT 00 DOT 1212120740300 DOT 26605 AT igor2priv>
	 <CAN0Jx-_+HNgHFNwjNkZRos--yRa9KWLeijjaE7zh5imjp5omuw AT mail DOT gmail DOT com>
	 <alpine DOT DEB DOT 2 DOT 00 DOT 1212150453530 DOT 26605 AT igor2priv>
	 <CAN0Jx-8mr2XmLHr7AzcTygk205H1H4_X1Y9VcQHw3zia5eGynQ AT mail DOT gmail DOT com>
	 <CAN-_CWyXNvnumf5OC+m-xRV0zMf3cCvyzLU3be_pC8DkNVZG0Q AT mail DOT gmail DOT com>
	 <1355861174 DOT 13534 DOT 14 DOT camel AT localhost>
	 <20121220101819 DOT GA26060 AT visitor2 DOT iram DOT es>
	 <1356003432 DOT 4776 DOT 10 DOT camel AT localhost>
	 <20121220122149 DOT GB20493 AT visitor2 DOT iram DOT es>
	 <1356047475 DOT 5629 DOT 4 DOT camel AT localhost>
	 <20121221100329 DOT GA4516 AT visitor2 DOT iram DOT es>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.6.2-0ubuntu2 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
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, 2012-12-21 at 11:03 +0100, Gabriel Paubert wrote:

[snip]

> As far as I can say, it was related to that change, but the absence of
> fullpoly flag at the time forced me to generate 2 polygons instead of one.
> The weirdest part may have been that the two halves were actually connected
> on one end through a line which had not the clearline file set.

[...]

> Anyway, this was the real problem. This was also when there was only
> one thermal, so I had to put copper rings around each via instead
> of using the solid thermal. This may have been the cause of some connectivity
> breakage.


As an absolute rule, I won't tolerate changes which break existing board
geometry. As an example, we have a rather strange set of maths in our
current thermal code, which produces strange and invalid thermal patters
for certain size and clearance vias / pins.

I started to write alternative thermal code to fix this geometry,
however I never figured out just how to introduce it without risking
changing the electrical / thermal resistance of some existing designs.
(Or changing the geometry enough to make or break a short).

I figured we would actually have to keep both sets of thermal geometry
maths - and use the current (somewhat broken) code for existing designs,
and the new stuff for newly created vias / thermals, or if asked
directly by the user to upgrade the board.

To avoid future mess like this, I was thinking about embedding the raw
geometry for the thermal into the layout file somewhere (perhaps stored
as a sub-object of the polygons, or the pin its self).

This would mean we had an exact copy of the thermal geometry when the
user last saw the thermal. We wouldn't have to re-calculate it at board
load time, so then would not have to keep around "n" different (possibly
buggy) versions of the thermal code.


The reason to introduce this caching of geometry is of course, to avoid
needing to keep maintaining every single version of every piece of
geometry maths we ever have, then change.

An alternative is to specify the geometric meaning of our thermals in
the file format specification once and for all, and REALLY ENSURE we get
the geometry + maths right this time.  (Yea right).


-- 
Peter Clifton <peter DOT clifton AT clifton-electronics DOT co DOT uk>

Clifton Electronics