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.ghila...@ieee.org>: > >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
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp