kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #02074
Re: pcbnew - thermal stubs
-
To:
kicad-devel@xxxxxxxxxxxxxxx
-
From:
"jean-pierre.charras@..." <jean-pierre.charras@...>
-
Date:
Sun, 11 Jan 2009 16:47:14 +0100
-
In-reply-to:
<4969B773.1010004@...>
-
User-agent:
Thunderbird 2.0.0.19 (Windows/20081209)
Rok Markovic a écrit :
>
> Hi
>
> I have implemented a solution proposed by Jean-Pierre but there is a
> real problem of determing which point to test to be sure that there
> is a zone area to connect to. If you have SO footprint the alghorithm I
> wrote works correctly. But if there is a TQFP footprint with much
> smaller raster you acctualy test for zone too far away, and you can
> remove zone (with thermals) from neighbour pad, if it is on the same
> NET. The solution is to use more points to test where is the zone, and
> to test if the point is on the pad. This can make zone calculation even
> slower, I didn't test how fast is TestIfPointIsInside Zone(), does anyone
> knows.
>
> For calculating the points for testing it would be very convinient and
> fast to use vector calculations. Is there already any vector(matrix)
> computational library already in use in this project?
>
I am thinking TestIfPointIsInside Zone() is fast.
When calculating zone filling the computation time is due to kbool
operations on polygons
(there are thousand (often 15000 to 25000) of segments to process).
Others calculations times (conversion of pads and tracks to polygons and
insulated islands) are not noticeable.
Note, i recently commit some changes in zones calculations, mainly to
avoid kbool problems.
These changes are also useful in thermal shapes enhancements.
Small pads can have problems in thermal shape calculation.
Perhaps a fixed thermal gap size (like i did) is not a good idea.
One can imagine to calculate a better size based on pads sizes.
The manner to choose thermal shapes parameters, (size of antipad (or
gap), size of copper bridges..) can be changed
after tries and tests.
--
Jean-Pierre CHARRAS
Maître de conférences
Directeur d'études 2ieme année.
Génie Electrique et Informatique Industrielle 2
Institut Universitaire de Technologie 1 de Grenoble
BP 67, 38402 St Martin d'Heres Cedex
Recherche :
GIPSA-LIS - INPG
Rue de la Houille Blanche
38400 Saint Martin d'Heres
--------------020109010103080300070308 Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Rok Markovic a écrit :
<blockquote cite="mid:4969B773.1010004@..." type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
<div>
<div>
<div>
<p>Hi<br>
<br>
I have implemented a solution proposed by Jean-Pierre but there is a<br>
real problem of determing which point to test to be sure that there<br>
is a zone area to connect to. If you have SO footprint the alghorithm I<br>
wrote works correctly. But if there is a TQFP footprint with much<br>
smaller raster you acctualy test for zone too far away, and you can<br>
remove zone (with thermals) from neighbour pad, if it is on the same<br>
NET. The solution is to use more points to test where is the zone, and<br>
to test if the point is on the pad. This can make zone calculation even<br>
slower, I didn't test how fast is TestIfPointIsInside Zone(), does
anyone<br>
knows.<br>
<br>
For calculating the points for testing it would be very convinient and<br>
fast to use vector calculations. Is there already any vector(matrix)<br>
computational library already in use in this project?<br>
</p>
</div>
</div>
</div>
</blockquote>
I am thinking TestIfPointIsInside Zone() is fast.<br>
When calculating zone filling the computation time is due to kbool
operations on polygons<br>
(there are thousand (often 15000 to 25000) of segments to process).<br>
Others calculations times (conversion of pads and tracks to polygons
and insulated islands) are not noticeable.<br>
<br>
Note, i recently commit some changes in zones calculations, mainly to
avoid kbool problems.<br>
These changes are also useful in thermal shapes enhancements.<br>
<br>
Small pads can have problems in thermal shape calculation.<br>
Perhaps a fixed thermal gap size (like i did) is not a good idea.<br>
One can imagine to calculate a better size based on pads sizes.<br>
The manner to choose thermal shapes parameters, (size of antipad (or
gap), size of copper bridges..) can be changed<br>
after tries and tests.<br>
<pre class="moz-signature" cols="72">--
Jean-Pierre CHARRAS
Maître de conférences
Directeur d'études 2ieme année.
Génie Electrique et Informatique Industrielle 2
Institut Universitaire de Technologie 1 de Grenoble
BP 67, 38402 St Martin d'Heres Cedex
Recherche :
GIPSA-LIS - INPG
Rue de la Houille Blanche
38400 Saint Martin d'Heres
</pre>
</body>
</html>
--------------020109010103080300070308--
Follow ups
References