kicad-developers team mailing list archive

[Dino Ghilardi <dino.ghilardi@xxxxxxxx>]

Hi Alexander,

>
> Maybe that's not too bad, as far as I remember, copper layers are
> polygons with get area method already implemented. But for sure that
> will take hours for debug.
>


A little bit of "brainstorming":
copper layer weight:
	For the covered area extimation one possible way could be generating a 
black-and-white bitmap of the layer (may be using cairo), and count 
black and white pixels, then calculate a "layer cover" percentage to be 
multipliedy by the area and the weight-per-surface-area to get the 
copper weight of that layer

To generate that bitmap the same routines that now are used to plot or 
print or to display on screen could be used.
P.S.: This is just an idea to investigate, i did not look into deep in 
the code to see if it is simpler than using the other methods.

If area calculation is made starting from the copper area definitions 
and track segments may be there are some critical points to be checked 
twice: if you have two segments of a track, that are connected in one 
point, around that point the two segments partially overlap, so the area 
is not the sum of the two areas. (As I said above I did not dig into 
this part of the code, so may be the problem has been considered yet).

About the "bitmap" method:
Pros: it will work even if some elements overlap (partially or fully).
Cons: Its precision will depend on the resolution used to create the 
bitmap since every "half-covered" pixel will introduce an approximation 
error.


About the hours to debug.... yes, it will need some time (but to check 
it I'll use the plot functions in kicad, open the image in gimp, create 
a bitmap and count black and white pixels...) That would be easier if in 
the text report we will have not only the end result (the weight of the 
board), but also the single parts (the weight of the layer or its copper 
coverage percent), so it can be checked layer-by-layer on a multilayer 
board.



> If we will understand what should be in eeschema statistics dialog, I
> can do that as well. Maybe they can even use one parent class...
> It's probably can show pads number as well... But what else?
>
>

Eeschema Statistics:
About the eeschema Stats items I can think about:
-Number of nets (probably the most important since it is used for a 
rough extimation of the routing cost)
-number of components (as above, but less important. P.S.: power 
symbols, and power flags will not be components, so they should be 
excluded from this count)

Other generic stats that can be of some use:
-number of symbol pins
-number of component pins
-number of connection segments?

And of course may be more that at the moment I'm not able to think about

The number of symbols and symbol pins could be used to evaluate the 
complexity and the cost of the schematic entry (since at the moment we 
do not have a timer that measures the time spent working on a project 
moving the mouse and pressing keys  -may be another future extension, 
but will require a change in file format to save that data, so it will 
not be in the 5.1 series if it is not yet coded into the file format-)

Cheers,
Dino.