kicad-developers team mailing list archive

[Alexander Shuklin <jasuramme@xxxxxxx>]

Hi Dino,

Thanks for direction. I'm not sure, that counting pixels is good way, but for sure I will look how Plot function is implemented.

>Среда, 31 июля 2019, 15:08 +03:00 от 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.


-- 
Alexander Shuklin