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