Thread Previous • Date Previous • Date Next • Thread Next |
Hi all, On Thu, 21 Mar 2019 at 16:41, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote: > Hey JP, > > On 3/21/2019 3:48 AM, jp charras wrote: > > Le 20/03/2019 à 19:27, Wayne Stambaugh a écrit : > >> Hi JP, > >> > >> Rather than pollute the bug report[1] with feedback about your zone > >> hatch filling patch, I moved the conversation to the mailing list. If > >> anyone else would like to test and comment on this patch, the patch can > >> be found in the bug report. > >> > >> I did some testing and the results look pretty good although it can be a > >> bit time consuming filling complex zones. This is to be expected. One > >> thing I did notice was that the hatched zone filling appears to leave > >> really small cutouts in some cases (see attached image). I know there > >> is no setting for this but maybe we should use the "Minimum width" > >> setting to removed excessively small cutouts as well as copper areas. > >> I'm not sure what users are going to expect here but it's something to > >> think about. > > > > Removing excessively small cutouts is not an easy task for many reasons: > > - How to recognize a "excessively small cutout"? For an human this is > > easy. For a computer it is not. > > - Calculation time will be certainly very expensive. > > - Most important, our filled areas are polygons with thick outlines. > > Therefore the polygon itself is small, and its shape is not exactly the > > filled area shape. > > Making "excessively small cutout" very hard to detect (the hole area is > > much bigger than the final hole area) > > Converting polygons with thick outlines to polygon only creates a lot of > > vertices. > > I tried that in Pcbnew a long time ago, and abandoned this idea due to > > significant calculation time, although it has many advantages. > > I wonder how much time it would add to calculate a simple bounding box > for each cutout polygon and if either bounding box dimension is less > than the minimum width, remove the cutout. Have you (or anyone else for > that matter) looked at how other EDA products handle this? It might be > helpful to know in advance so we can make an informed decision. > > I attach some screenshots of another EDA application suite. Here a simple "Fill non-square hatch areas" checkbox is the only option in the "Hatch Options" tab. Regards, Michael > > > > As I said previously, grid shaped fill mode can be used only in specific > > cases, not for "normal" ground planes. > > > >> > >> I also would like you to change the terminology from "grid pattern" to > >> "hatch" for UI strings, source code naming, and file formatting. In > >> other words, the file format token "pattern_thickness" should be > >> "hatch_thickness", the source code name "m_GridPatternThickness" should > >> be "m_HatchThickness", and the dialog fill type string type "Grid > >> Pattern" should be "Hatch". I think "hatch" is more descriptive when > >> describing this type of zone fill. > > > > Yes, but we are already using Hatch option in Outline Display mode in > > zone settings dialog (and hatch as keyword in .kicad_pcb file). > > > > So it can create unclear options in dialog. > > (and somewhat in file) > > I took another look at the file format changes and I noticed another > issue that I missed. The new file format tokens are in the "zone" > settings section. They should be in the "fill" settings section since > they are specific to the zone filling. There is also a extra > indentation which appears to be incorrect as well. Here is an example > of what I'm thinking it should look like: > > (zone (net 0) (net_name "") (layer F.Cu) (tstamp 0) (hatch edge 0.508) > (connect_pads (clearance 0.508)) > (min_thickness 0.254) > (fill yes (mode hatch) (arc_segments 32) (thermal_gap 0.508) > (thermal_bridge_width 0.508) (hatch_thickness 0.635) > (hatch_gap 0.635) (hatch_orientation 0) > (hatch_smoothing_level 1) (hatch_smoothing_value 0.25)) > ) # end fill parameters > ... > ) #end zone > > This puts the hatch parameter under the "fill" section which makes it > clear that it is a fill parameter rather than a "zone" parameter. > Reusing tokens is fine as long as they are grouped correctly so that it > is obvious which group the token belongs to. In the case above, hatch > is obviously the type of fill mode. > > > > > Thoughts? > > > >> > >> Cheers, > >> > >> Wayne > >> > >> [1]: https://bugs.launchpad.net/kicad/+bug/1820493 > > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp >
Attachment:
Plane Classes and Parameters 1.PNG
Description: PNG image
Attachment:
Plane Classes and Parameters 2.PNG
Description: PNG image
Attachment:
Plane Classes and Parameters 3.PNG
Description: PNG image
Thread Previous • Date Previous • Date Next • Thread Next |