kicad-developers team mailing list archive
Mailing list archive
Re: [PATCH] Board statistics dialog
> 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
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
> 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?
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-)