kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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.

> 
> 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
> 
>