Re: [Kicad-developers] 6.0 Zone filling differences

[Jeff Young]

Hi Eeli,

Fixes in.  (I built my own test case so I can’t be 100% sure it will fix yours, 
but I’d be 90% sure I got it.)

Cheers,
Jeff.


> On 25 Jun 2019, at 23:44, Eeli Kaikkonen  wrote:
> 
> Actually I didn't notice the hole offset thing in the lower oblong pad. I 
> just saw that the upper one doesn't have spokes at all. It's unexplainable 
> when the lower one, identical, does have one spoke (the 45 deg spoke to the 
> small SMD pad is actually a track). And the upper one doesn't have spokes on 
> the bottom layer either while there are two spokes there with the old 5.0.2 
> version.
> 
> Eeli Kaikkonen
> 
> 
> ke 26. kesäk. 2019 klo 1.08 Jeff Young (j...@rokeby.ie 
> ) kirjoitti:
> Great test-case: an offset and rotated pad.
> 
> So the old algorithm centred the spokes on the pad; the new one centres them 
> on the hole.  I assume old is preferred?
> 
> Cheers,
> Jeff.
> 
> 
>> On 25 Jun 2019, at 22:44, Eeli Kaikkonen > > wrote:
>> 
>> There's something wrong in creating the thermal for the oblong pad in the 
>> attached picture. Left side: 5.0.2. Right: includes your commit. Tested on 
>> Linux.
>> 
>> Here's also the footprint, taken from the board file:
>> 
>> (module "XX-X-USB:Microusb_female_thrhole_horn" (layer "F.Cu") (tedit 
>> 5C1B9BE7) (tstamp 5D08B5B8)
>> (at 119.25 105.8 90)
>> (descr "MICRO USB R/A-473460001")
>> (path "/5CDA4205")
>> (attr smd)
>> (fp_text reference "X2" (at 0.15 -6.15 90) (layer "F.SilkS")
>>   (effects (font (size 1 1) (thickness 0.15)))
>> )
>> (fp_text value "USB_B_Micro" (at -0.2 4.2 90) (layer "F.SilkS")
>>   (effects (font (size 1 1) (thickness 0.15)))
>> )
>> (fp_line (start -3.75 2.75) (end -3.75 -2.75) (layer "F.Fab") (width 
>> 0.127))
>> (fp_line (start 3.75 2.75) (end -3.75 2.75) (layer "F.Fab") (width 
>> 0.127))
>> (fp_line (start 3.75 -2.75) (end 3.75 2.75) (layer "F.Fab") (width 
>> 0.127))
>> (fp_line (start -3.75 -2.75) (end 3.75 -2.75) (layer "F.Fab") (width 
>> 0.127))
>> (fp_circle (center -1.7 -3.8) (end -1.6 -3.8) (layer "F.SilkS") (width 
>> 0.15))
>> (fp_line (start 4.25 2.65) (end -4.25 2.65) (layer "F.CrtYd") (width 
>> 0.05))
>> (fp_line (start 4.25 -3.75) (end 4.25 2.65) (layer "F.CrtYd") (width 
>> 0.05))
>> (fp_line (start -4.25 -3.75) (end 4.25 -3.75) (layer "F.CrtYd") (width 
>> 0.05))
>> (fp_line (start -4.25 2.65) (end -4.25 -3.75) (layer "F.CrtYd") (width 
>> 0.05))
>> (fp_line (start 3.9 -2.95) (end 3.65 -2.95) (layer "F.SilkS") (width 
>> 0.127))
>> (fp_line (start -3.9 -2.95) (end -3.65 -2.95) (layer "F.SilkS") (width 
>> 0.127))
>> (fp_line (start 3.9 -2.95) (end 3.9 -1.35) (layer "F.SilkS") (width 
>> 0.127))
>> (fp_line (start -3.9 -2.95) (end -3.9 -1.35) (layer "F.SilkS") (width 
>> 0.127))
>> (fp_line (start -5.45 1.35) (end 5.5 1.35) (layer "F.Fab") (width 0.127))
>> (fp_text user "%V" (at -0.15 4.15 90) (layer "F.Fab")
>>   (effects (font (size 1 1) (thickness 0.15)))
>> )
>> (pad "6" thru_hole oval (at -3.575 0 90) (size 1 2) (drill oval 0.6 1.2 
>> (offset 0 -0.15)) (layers *.Cu *.Mask "F.Paste")
>>   (net 2 "GND") (solder_paste_margin -0.01) (solder_paste_margin_ratio 
>> -0.0001))
>> (pad "6" thru_hole oval (at 3.575 0 90) (size 1 2) (drill oval 0.6 1.2 
>> (offset 0 -0.15)) (layers *.Cu *.Mask "F.Paste")
>>   (net 2 "GND") (solder_paste_margin -0.01) (solder_paste_margin_ratio 
>> -0.0001))
>> (pad "6" thru_hole circle (at -2.425 -2.73 90) (size 1 1) (drill 0.6) 
>> (layers *.Cu *.Mask "F.Paste")
>>   (net 2 "GND") (solder_paste_margin -0.01) (solder_paste_margin_ratio 
>> -0.0001))
>> (pad "6" thru_hole circle (at 2.425 -2.73 90) (size 1 1) (drill 0.6) 
>> (layers *.Cu *.Mask "F.Paste")
>>   (net 2 "GND") (solder_paste_margin -0.01) (solder_paste_margin_ratio 
>> -0.0001))
>> (pad "1" smd roundrect (at -1.3 -2.66 90) (size 0.4 1.5) (layers "F.Cu" 
>> "F.Paste" "F.Mask") (roundrect_rratio 0.25)
>>   (net 34 "VBUS") (clearance 0.19))
>> (pad "2" smd roundrect (at -0.65 -2.66 90) (size 0.4 1.5) (layers "F.Cu" 
>> "F.Paste" "F.Mask") (roundrect_rratio 0.25)
>>   (net 62 "D-"))
>> (pad "3" smd roundrect (at 0 -2.66 90) (size 0.4 1.5) (layers "F.Cu" 
>> "F.Paste" "F.Mask") (roundrect_rratio 0.25)
>>   (net 63 "D+"))
>> (pad "4" smd roundrect (at 0.65 -2.66 90) (size 0.4 1.5) (layers "F.Cu" 
>> "F.Paste" "F.Mask") (roundrect_rratio 0.25)
>>   (net 59 "id_r"))
>> (pad "5" smd roundrect (at 1.3 -2.66 90) (size 0.4 1.5) (layers "F.Cu" 
>> "F.Paste" "F.Mask") (roundrect_rratio 0.25)
>>   (net 2 "GND") (clearance 0.19))
>> (model 
>> "${KISYS3DMOD}/Connector_USB.3dshapes/USB_Micro-B_Molex_47346-0001.wrl"
>>   (offset (xyz 0 1.2 0))
>>   (scale (xyz 1 1 1))
>>   (rotate (xyz 0 0 0))
>> )
>>   )
>> 
>> 
>> __
>> BTW, highlighting items in pcbnew seems to be 

Re: [Kicad-developers] 6.0 Zone filling differences

[Eeli Kaikkonen]

Actually I didn't notice the hole offset thing in the lower oblong pad. I
just saw that the upper one doesn't have spokes at all. It's unexplainable
when the lower one, identical, does have one spoke (the 45 deg spoke to the
small SMD pad is actually a track). And the upper one doesn't have spokes
on the bottom layer either while there are two spokes there with the old
5.0.2 version.

Eeli Kaikkonen


ke 26. kesäk. 2019 klo 1.08 Jeff Young (j...@rokeby.ie) kirjoitti:

> Great test-case: an offset and rotated pad.
>
> So the old algorithm centred the spokes on the pad; the new one centres
> them on the hole.  I assume old is preferred?
>
> Cheers,
> Jeff.
>
>
> On 25 Jun 2019, at 22:44, Eeli Kaikkonen  wrote:
>
> There's something wrong in creating the thermal for the oblong pad in the
> attached picture. Left side: 5.0.2. Right: includes your commit. Tested on
> Linux.
>
> Here's also the footprint, taken from the board file:
>
> (module "XX-X-USB:Microusb_female_thrhole_horn" (layer "F.Cu") (tedit
> 5C1B9BE7) (tstamp 5D08B5B8)
> (at 119.25 105.8 90)
> (descr "MICRO USB R/A-473460001")
> (path "/5CDA4205")
> (attr smd)
> (fp_text reference "X2" (at 0.15 -6.15 90) (layer "F.SilkS")
>   (effects (font (size 1 1) (thickness 0.15)))
> )
> (fp_text value "USB_B_Micro" (at -0.2 4.2 90) (layer "F.SilkS")
>   (effects (font (size 1 1) (thickness 0.15)))
> )
> (fp_line (start -3.75 2.75) (end -3.75 -2.75) (layer "F.Fab") (width
> 0.127))
> (fp_line (start 3.75 2.75) (end -3.75 2.75) (layer "F.Fab") (width
> 0.127))
> (fp_line (start 3.75 -2.75) (end 3.75 2.75) (layer "F.Fab") (width
> 0.127))
> (fp_line (start -3.75 -2.75) (end 3.75 -2.75) (layer "F.Fab") (width
> 0.127))
> (fp_circle (center -1.7 -3.8) (end -1.6 -3.8) (layer "F.SilkS") (width
> 0.15))
> (fp_line (start 4.25 2.65) (end -4.25 2.65) (layer "F.CrtYd") (width
> 0.05))
> (fp_line (start 4.25 -3.75) (end 4.25 2.65) (layer "F.CrtYd") (width
> 0.05))
> (fp_line (start -4.25 -3.75) (end 4.25 -3.75) (layer "F.CrtYd") (width
> 0.05))
> (fp_line (start -4.25 2.65) (end -4.25 -3.75) (layer "F.CrtYd") (width
> 0.05))
> (fp_line (start 3.9 -2.95) (end 3.65 -2.95) (layer "F.SilkS") (width
> 0.127))
> (fp_line (start -3.9 -2.95) (end -3.65 -2.95) (layer "F.SilkS") (width
> 0.127))
> (fp_line (start 3.9 -2.95) (end 3.9 -1.35) (layer "F.SilkS") (width
> 0.127))
> (fp_line (start -3.9 -2.95) (end -3.9 -1.35) (layer "F.SilkS") (width
> 0.127))
> (fp_line (start -5.45 1.35) (end 5.5 1.35) (layer "F.Fab") (width
> 0.127))
> (fp_text user "%V" (at -0.15 4.15 90) (layer "F.Fab")
>   (effects (font (size 1 1) (thickness 0.15)))
> )
> (pad "6" thru_hole oval (at -3.575 0 90) (size 1 2) (drill oval 0.6
> 1.2 (offset 0 -0.15)) (layers *.Cu *.Mask "F.Paste")
>   (net 2 "GND") (solder_paste_margin -0.01) (solder_paste_margin_ratio
> -0.0001))
> (pad "6" thru_hole oval (at 3.575 0 90) (size 1 2) (drill oval 0.6 1.2
> (offset 0 -0.15)) (layers *.Cu *.Mask "F.Paste")
>   (net 2 "GND") (solder_paste_margin -0.01) (solder_paste_margin_ratio
> -0.0001))
> (pad "6" thru_hole circle (at -2.425 -2.73 90) (size 1 1) (drill 0.6)
> (layers *.Cu *.Mask "F.Paste")
>   (net 2 "GND") (solder_paste_margin -0.01) (solder_paste_margin_ratio
> -0.0001))
> (pad "6" thru_hole circle (at 2.425 -2.73 90) (size 1 1) (drill 0.6)
> (layers *.Cu *.Mask "F.Paste")
>   (net 2 "GND") (solder_paste_margin -0.01) (solder_paste_margin_ratio
> -0.0001))
> (pad "1" smd roundrect (at -1.3 -2.66 90) (size 0.4 1.5) (layers
> "F.Cu" "F.Paste" "F.Mask") (roundrect_rratio 0.25)
>   (net 34 "VBUS") (clearance 0.19))
> (pad "2" smd roundrect (at -0.65 -2.66 90) (size 0.4 1.5) (layers
> "F.Cu" "F.Paste" "F.Mask") (roundrect_rratio 0.25)
>   (net 62 "D-"))
> (pad "3" smd roundrect (at 0 -2.66 90) (size 0.4 1.5) (layers "F.Cu"
> "F.Paste" "F.Mask") (roundrect_rratio 0.25)
>   (net 63 "D+"))
> (pad "4" smd roundrect (at 0.65 -2.66 90) (size 0.4 1.5) (layers
> "F.Cu" "F.Paste" "F.Mask") (roundrect_rratio 0.25)
>   (net 59 "id_r"))
> (pad "5" smd roundrect (at 1.3 -2.66 90) (size 0.4 1.5) (layers "F.Cu"
> "F.Paste" "F.Mask") (roundrect_rratio 0.25)
>   (net 2 "GND") (clearance 0.19))
> (model
> "${KISYS3DMOD}/Connector_USB.3dshapes/USB_Micro-B_Molex_47346-0001.wrl"
>   (offset (xyz 0 1.2 0))
>   (scale (xyz 1 1 1))
>   (rotate (xyz 0 0 0))
> )
>   )
>
>
> __
> BTW, highlighting items in pcbnew seems to be broken, maybe because of the
> new "real-time highlighting" for delete tool. The delete tool highlight
> doesn't highlight tracks. The older selection clarification and DCR dialog
> item highlighting don't work well, only some things are highlighted
> sometimes. This happens with
>
> Application: Pcbnew
> Version: (5.1.0-1126-g107d206db), release build
> Libraries:
> wxWidgets 3.0.4
> Platform: Linux 

Re: [Kicad-developers] 6.0 Zone filling differences

[Jeff Young]

It’s all one-and-the-same.  The top pad doesn’t have spokes because the 
rotation for testing to see if the ends of the spokes are within the zone is 
done from the pad center.  (The bottom pad would also be missing its left and 
bottom spokes, if it had any.)

Cheers,
Jeff.


> On 25 Jun 2019, at 23:25, Ian McInerney  wrote:
> 
> Jeff,
> 
> I think Eeli was referring to the fact that with the new algorithm the top 
> oblong pad has no spokes connected to it, while the bottom one does rather 
> than the positioning of the spokes. But I do think it looks better with 
> spokes centered on the pad rather than the hole.
> 
> -Ian
> 
> On Tue, Jun 25, 2019 at 11:08 PM Jeff Young  > wrote:
> Great test-case: an offset and rotated pad.
> 
> So the old algorithm centred the spokes on the pad; the new one centres them 
> on the hole.  I assume old is preferred?
> 
> Cheers,
> Jeff.
> 
> 
>> On 25 Jun 2019, at 22:44, Eeli Kaikkonen > > wrote:
>> 
>> There's something wrong in creating the thermal for the oblong pad in the 
>> attached picture. Left side: 5.0.2. Right: includes your commit. Tested on 
>> Linux.
>> 
>> Here's also the footprint, taken from the board file:
>> 
>> (module "XX-X-USB:Microusb_female_thrhole_horn" (layer "F.Cu") (tedit 
>> 5C1B9BE7) (tstamp 5D08B5B8)
>> (at 119.25 105.8 90)
>> (descr "MICRO USB R/A-473460001")
>> (path "/5CDA4205")
>> (attr smd)
>> (fp_text reference "X2" (at 0.15 -6.15 90) (layer "F.SilkS")
>>   (effects (font (size 1 1) (thickness 0.15)))
>> )
>> (fp_text value "USB_B_Micro" (at -0.2 4.2 90) (layer "F.SilkS")
>>   (effects (font (size 1 1) (thickness 0.15)))
>> )
>> (fp_line (start -3.75 2.75) (end -3.75 -2.75) (layer "F.Fab") (width 
>> 0.127))
>> (fp_line (start 3.75 2.75) (end -3.75 2.75) (layer "F.Fab") (width 
>> 0.127))
>> (fp_line (start 3.75 -2.75) (end 3.75 2.75) (layer "F.Fab") (width 
>> 0.127))
>> (fp_line (start -3.75 -2.75) (end 3.75 -2.75) (layer "F.Fab") (width 
>> 0.127))
>> (fp_circle (center -1.7 -3.8) (end -1.6 -3.8) (layer "F.SilkS") (width 
>> 0.15))
>> (fp_line (start 4.25 2.65) (end -4.25 2.65) (layer "F.CrtYd") (width 
>> 0.05))
>> (fp_line (start 4.25 -3.75) (end 4.25 2.65) (layer "F.CrtYd") (width 
>> 0.05))
>> (fp_line (start -4.25 -3.75) (end 4.25 -3.75) (layer "F.CrtYd") (width 
>> 0.05))
>> (fp_line (start -4.25 2.65) (end -4.25 -3.75) (layer "F.CrtYd") (width 
>> 0.05))
>> (fp_line (start 3.9 -2.95) (end 3.65 -2.95) (layer "F.SilkS") (width 
>> 0.127))
>> (fp_line (start -3.9 -2.95) (end -3.65 -2.95) (layer "F.SilkS") (width 
>> 0.127))
>> (fp_line (start 3.9 -2.95) (end 3.9 -1.35) (layer "F.SilkS") (width 
>> 0.127))
>> (fp_line (start -3.9 -2.95) (end -3.9 -1.35) (layer "F.SilkS") (width 
>> 0.127))
>> (fp_line (start -5.45 1.35) (end 5.5 1.35) (layer "F.Fab") (width 0.127))
>> (fp_text user "%V" (at -0.15 4.15 90) (layer "F.Fab")
>>   (effects (font (size 1 1) (thickness 0.15)))
>> )
>> (pad "6" thru_hole oval (at -3.575 0 90) (size 1 2) (drill oval 0.6 1.2 
>> (offset 0 -0.15)) (layers *.Cu *.Mask "F.Paste")
>>   (net 2 "GND") (solder_paste_margin -0.01) (solder_paste_margin_ratio 
>> -0.0001))
>> (pad "6" thru_hole oval (at 3.575 0 90) (size 1 2) (drill oval 0.6 1.2 
>> (offset 0 -0.15)) (layers *.Cu *.Mask "F.Paste")
>>   (net 2 "GND") (solder_paste_margin -0.01) (solder_paste_margin_ratio 
>> -0.0001))
>> (pad "6" thru_hole circle (at -2.425 -2.73 90) (size 1 1) (drill 0.6) 
>> (layers *.Cu *.Mask "F.Paste")
>>   (net 2 "GND") (solder_paste_margin -0.01) (solder_paste_margin_ratio 
>> -0.0001))
>> (pad "6" thru_hole circle (at 2.425 -2.73 90) (size 1 1) (drill 0.6) 
>> (layers *.Cu *.Mask "F.Paste")
>>   (net 2 "GND") (solder_paste_margin -0.01) (solder_paste_margin_ratio 
>> -0.0001))
>> (pad "1" smd roundrect (at -1.3 -2.66 90) (size 0.4 1.5) (layers "F.Cu" 
>> "F.Paste" "F.Mask") (roundrect_rratio 0.25)
>>   (net 34 "VBUS") (clearance 0.19))
>> (pad "2" smd roundrect (at -0.65 -2.66 90) (size 0.4 1.5) (layers "F.Cu" 
>> "F.Paste" "F.Mask") (roundrect_rratio 0.25)
>>   (net 62 "D-"))
>> (pad "3" smd roundrect (at 0 -2.66 90) (size 0.4 1.5) (layers "F.Cu" 
>> "F.Paste" "F.Mask") (roundrect_rratio 0.25)
>>   (net 63 "D+"))
>> (pad "4" smd roundrect (at 0.65 -2.66 90) (size 0.4 1.5) (layers "F.Cu" 
>> "F.Paste" "F.Mask") (roundrect_rratio 0.25)
>>   (net 59 "id_r"))
>> (pad "5" smd roundrect (at 1.3 -2.66 90) (size 0.4 1.5) (layers "F.Cu" 
>> "F.Paste" "F.Mask") (roundrect_rratio 0.25)
>>   (net 2 "GND") (clearance 0.19))
>> (model 
>> "${KISYS3DMOD}/Connector_USB.3dshapes/USB_Micro-B_Molex_47346-0001.wrl"
>>   (offset (xyz 0 1.2 0))
>>   (scale (xyz 1 1 1))
>>   (rotate (xyz 0 0 0))
>> )
>>   )
>> 
>> 
>> __
>> BTW, highlighting items in pcbnew seems to be broken, 

Re: [Kicad-developers] 6.0 Zone filling differences

[Ian McInerney]

Jeff,

I think Eeli was referring to the fact that with the new algorithm the top
oblong pad has no spokes connected to it, while the bottom one does rather
than the positioning of the spokes. But I do think it looks better with
spokes centered on the pad rather than the hole.

-Ian

On Tue, Jun 25, 2019 at 11:08 PM Jeff Young  wrote:

> Great test-case: an offset and rotated pad.
>
> So the old algorithm centred the spokes on the pad; the new one centres
> them on the hole.  I assume old is preferred?
>
> Cheers,
> Jeff.
>
>
> On 25 Jun 2019, at 22:44, Eeli Kaikkonen  wrote:
>
> There's something wrong in creating the thermal for the oblong pad in the
> attached picture. Left side: 5.0.2. Right: includes your commit. Tested on
> Linux.
>
> Here's also the footprint, taken from the board file:
>
> (module "XX-X-USB:Microusb_female_thrhole_horn" (layer "F.Cu") (tedit
> 5C1B9BE7) (tstamp 5D08B5B8)
> (at 119.25 105.8 90)
> (descr "MICRO USB R/A-473460001")
> (path "/5CDA4205")
> (attr smd)
> (fp_text reference "X2" (at 0.15 -6.15 90) (layer "F.SilkS")
>   (effects (font (size 1 1) (thickness 0.15)))
> )
> (fp_text value "USB_B_Micro" (at -0.2 4.2 90) (layer "F.SilkS")
>   (effects (font (size 1 1) (thickness 0.15)))
> )
> (fp_line (start -3.75 2.75) (end -3.75 -2.75) (layer "F.Fab") (width
> 0.127))
> (fp_line (start 3.75 2.75) (end -3.75 2.75) (layer "F.Fab") (width
> 0.127))
> (fp_line (start 3.75 -2.75) (end 3.75 2.75) (layer "F.Fab") (width
> 0.127))
> (fp_line (start -3.75 -2.75) (end 3.75 -2.75) (layer "F.Fab") (width
> 0.127))
> (fp_circle (center -1.7 -3.8) (end -1.6 -3.8) (layer "F.SilkS") (width
> 0.15))
> (fp_line (start 4.25 2.65) (end -4.25 2.65) (layer "F.CrtYd") (width
> 0.05))
> (fp_line (start 4.25 -3.75) (end 4.25 2.65) (layer "F.CrtYd") (width
> 0.05))
> (fp_line (start -4.25 -3.75) (end 4.25 -3.75) (layer "F.CrtYd") (width
> 0.05))
> (fp_line (start -4.25 2.65) (end -4.25 -3.75) (layer "F.CrtYd") (width
> 0.05))
> (fp_line (start 3.9 -2.95) (end 3.65 -2.95) (layer "F.SilkS") (width
> 0.127))
> (fp_line (start -3.9 -2.95) (end -3.65 -2.95) (layer "F.SilkS") (width
> 0.127))
> (fp_line (start 3.9 -2.95) (end 3.9 -1.35) (layer "F.SilkS") (width
> 0.127))
> (fp_line (start -3.9 -2.95) (end -3.9 -1.35) (layer "F.SilkS") (width
> 0.127))
> (fp_line (start -5.45 1.35) (end 5.5 1.35) (layer "F.Fab") (width
> 0.127))
> (fp_text user "%V" (at -0.15 4.15 90) (layer "F.Fab")
>   (effects (font (size 1 1) (thickness 0.15)))
> )
> (pad "6" thru_hole oval (at -3.575 0 90) (size 1 2) (drill oval 0.6
> 1.2 (offset 0 -0.15)) (layers *.Cu *.Mask "F.Paste")
>   (net 2 "GND") (solder_paste_margin -0.01) (solder_paste_margin_ratio
> -0.0001))
> (pad "6" thru_hole oval (at 3.575 0 90) (size 1 2) (drill oval 0.6 1.2
> (offset 0 -0.15)) (layers *.Cu *.Mask "F.Paste")
>   (net 2 "GND") (solder_paste_margin -0.01) (solder_paste_margin_ratio
> -0.0001))
> (pad "6" thru_hole circle (at -2.425 -2.73 90) (size 1 1) (drill 0.6)
> (layers *.Cu *.Mask "F.Paste")
>   (net 2 "GND") (solder_paste_margin -0.01) (solder_paste_margin_ratio
> -0.0001))
> (pad "6" thru_hole circle (at 2.425 -2.73 90) (size 1 1) (drill 0.6)
> (layers *.Cu *.Mask "F.Paste")
>   (net 2 "GND") (solder_paste_margin -0.01) (solder_paste_margin_ratio
> -0.0001))
> (pad "1" smd roundrect (at -1.3 -2.66 90) (size 0.4 1.5) (layers
> "F.Cu" "F.Paste" "F.Mask") (roundrect_rratio 0.25)
>   (net 34 "VBUS") (clearance 0.19))
> (pad "2" smd roundrect (at -0.65 -2.66 90) (size 0.4 1.5) (layers
> "F.Cu" "F.Paste" "F.Mask") (roundrect_rratio 0.25)
>   (net 62 "D-"))
> (pad "3" smd roundrect (at 0 -2.66 90) (size 0.4 1.5) (layers "F.Cu"
> "F.Paste" "F.Mask") (roundrect_rratio 0.25)
>   (net 63 "D+"))
> (pad "4" smd roundrect (at 0.65 -2.66 90) (size 0.4 1.5) (layers
> "F.Cu" "F.Paste" "F.Mask") (roundrect_rratio 0.25)
>   (net 59 "id_r"))
> (pad "5" smd roundrect (at 1.3 -2.66 90) (size 0.4 1.5) (layers "F.Cu"
> "F.Paste" "F.Mask") (roundrect_rratio 0.25)
>   (net 2 "GND") (clearance 0.19))
> (model
> "${KISYS3DMOD}/Connector_USB.3dshapes/USB_Micro-B_Molex_47346-0001.wrl"
>   (offset (xyz 0 1.2 0))
>   (scale (xyz 1 1 1))
>   (rotate (xyz 0 0 0))
> )
>   )
>
>
> __
> BTW, highlighting items in pcbnew seems to be broken, maybe because of the
> new "real-time highlighting" for delete tool. The delete tool highlight
> doesn't highlight tracks. The older selection clarification and DCR dialog
> item highlighting don't work well, only some things are highlighted
> sometimes. This happens with
>
> Application: Pcbnew
> Version: (5.1.0-1126-g107d206db), release build
> Libraries:
> wxWidgets 3.0.4
> Platform: Linux 4.15.0-51-generic x86_64, 64 bit, Little endian, wxGTK
> Build Info:
> wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 

Re: [Kicad-developers] 6.0 Zone filling differences

[Jeff Young]

Great test-case: an offset and rotated pad.

So the old algorithm centred the spokes on the pad; the new one centres them on 
the hole.  I assume old is preferred?

Cheers,
Jeff.


> On 25 Jun 2019, at 22:44, Eeli Kaikkonen  wrote:
> 
> There's something wrong in creating the thermal for the oblong pad in the 
> attached picture. Left side: 5.0.2. Right: includes your commit. Tested on 
> Linux.
> 
> Here's also the footprint, taken from the board file:
> 
> (module "XX-X-USB:Microusb_female_thrhole_horn" (layer "F.Cu") (tedit 
> 5C1B9BE7) (tstamp 5D08B5B8)
> (at 119.25 105.8 90)
> (descr "MICRO USB R/A-473460001")
> (path "/5CDA4205")
> (attr smd)
> (fp_text reference "X2" (at 0.15 -6.15 90) (layer "F.SilkS")
>   (effects (font (size 1 1) (thickness 0.15)))
> )
> (fp_text value "USB_B_Micro" (at -0.2 4.2 90) (layer "F.SilkS")
>   (effects (font (size 1 1) (thickness 0.15)))
> )
> (fp_line (start -3.75 2.75) (end -3.75 -2.75) (layer "F.Fab") (width 
> 0.127))
> (fp_line (start 3.75 2.75) (end -3.75 2.75) (layer "F.Fab") (width 0.127))
> (fp_line (start 3.75 -2.75) (end 3.75 2.75) (layer "F.Fab") (width 0.127))
> (fp_line (start -3.75 -2.75) (end 3.75 -2.75) (layer "F.Fab") (width 
> 0.127))
> (fp_circle (center -1.7 -3.8) (end -1.6 -3.8) (layer "F.SilkS") (width 
> 0.15))
> (fp_line (start 4.25 2.65) (end -4.25 2.65) (layer "F.CrtYd") (width 
> 0.05))
> (fp_line (start 4.25 -3.75) (end 4.25 2.65) (layer "F.CrtYd") (width 
> 0.05))
> (fp_line (start -4.25 -3.75) (end 4.25 -3.75) (layer "F.CrtYd") (width 
> 0.05))
> (fp_line (start -4.25 2.65) (end -4.25 -3.75) (layer "F.CrtYd") (width 
> 0.05))
> (fp_line (start 3.9 -2.95) (end 3.65 -2.95) (layer "F.SilkS") (width 
> 0.127))
> (fp_line (start -3.9 -2.95) (end -3.65 -2.95) (layer "F.SilkS") (width 
> 0.127))
> (fp_line (start 3.9 -2.95) (end 3.9 -1.35) (layer "F.SilkS") (width 
> 0.127))
> (fp_line (start -3.9 -2.95) (end -3.9 -1.35) (layer "F.SilkS") (width 
> 0.127))
> (fp_line (start -5.45 1.35) (end 5.5 1.35) (layer "F.Fab") (width 0.127))
> (fp_text user "%V" (at -0.15 4.15 90) (layer "F.Fab")
>   (effects (font (size 1 1) (thickness 0.15)))
> )
> (pad "6" thru_hole oval (at -3.575 0 90) (size 1 2) (drill oval 0.6 1.2 
> (offset 0 -0.15)) (layers *.Cu *.Mask "F.Paste")
>   (net 2 "GND") (solder_paste_margin -0.01) (solder_paste_margin_ratio 
> -0.0001))
> (pad "6" thru_hole oval (at 3.575 0 90) (size 1 2) (drill oval 0.6 1.2 
> (offset 0 -0.15)) (layers *.Cu *.Mask "F.Paste")
>   (net 2 "GND") (solder_paste_margin -0.01) (solder_paste_margin_ratio 
> -0.0001))
> (pad "6" thru_hole circle (at -2.425 -2.73 90) (size 1 1) (drill 0.6) 
> (layers *.Cu *.Mask "F.Paste")
>   (net 2 "GND") (solder_paste_margin -0.01) (solder_paste_margin_ratio 
> -0.0001))
> (pad "6" thru_hole circle (at 2.425 -2.73 90) (size 1 1) (drill 0.6) 
> (layers *.Cu *.Mask "F.Paste")
>   (net 2 "GND") (solder_paste_margin -0.01) (solder_paste_margin_ratio 
> -0.0001))
> (pad "1" smd roundrect (at -1.3 -2.66 90) (size 0.4 1.5) (layers "F.Cu" 
> "F.Paste" "F.Mask") (roundrect_rratio 0.25)
>   (net 34 "VBUS") (clearance 0.19))
> (pad "2" smd roundrect (at -0.65 -2.66 90) (size 0.4 1.5) (layers "F.Cu" 
> "F.Paste" "F.Mask") (roundrect_rratio 0.25)
>   (net 62 "D-"))
> (pad "3" smd roundrect (at 0 -2.66 90) (size 0.4 1.5) (layers "F.Cu" 
> "F.Paste" "F.Mask") (roundrect_rratio 0.25)
>   (net 63 "D+"))
> (pad "4" smd roundrect (at 0.65 -2.66 90) (size 0.4 1.5) (layers "F.Cu" 
> "F.Paste" "F.Mask") (roundrect_rratio 0.25)
>   (net 59 "id_r"))
> (pad "5" smd roundrect (at 1.3 -2.66 90) (size 0.4 1.5) (layers "F.Cu" 
> "F.Paste" "F.Mask") (roundrect_rratio 0.25)
>   (net 2 "GND") (clearance 0.19))
> (model 
> "${KISYS3DMOD}/Connector_USB.3dshapes/USB_Micro-B_Molex_47346-0001.wrl"
>   (offset (xyz 0 1.2 0))
>   (scale (xyz 1 1 1))
>   (rotate (xyz 0 0 0))
> )
>   )
> 
> 
> __
> BTW, highlighting items in pcbnew seems to be broken, maybe because of the 
> new "real-time highlighting" for delete tool. The delete tool highlight 
> doesn't highlight tracks. The older selection clarification and DCR dialog 
> item highlighting don't work well, only some things are highlighted 
> sometimes. This happens with
> 
> Application: Pcbnew
> Version: (5.1.0-1126-g107d206db), release build
> Libraries:
> wxWidgets 3.0.4
> Platform: Linux 4.15.0-51-generic x86_64, 64 bit, Little endian, wxGTK
> Build Info:
> wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.22
> Boost: 1.65.1
> OpenCASCADE Community Edition: 6.9.1
> Compiler: GCC 7.4.0 with C++ ABI 1011
> 
> Build settings:
> KICAD_SCRIPTING=ON
> KICAD_SCRIPTING_MODULES=ON
> KICAD_SCRIPTING_PYTHON3=ON
> KICAD_SCRIPTING_WXPYTHON=ON
> KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
> 

Re: [Kicad-developers] 6.0 Zone filling differences

[Eeli Kaikkonen]

There's something wrong in creating the thermal for the oblong pad in the
attached picture. Left side: 5.0.2. Right: includes your commit. Tested on
Linux.

Here's also the footprint, taken from the board file:

(module "XX-X-USB:Microusb_female_thrhole_horn" (layer "F.Cu") (tedit
5C1B9BE7) (tstamp 5D08B5B8)
(at 119.25 105.8 90)
(descr "MICRO USB R/A-473460001")
(path "/5CDA4205")
(attr smd)
(fp_text reference "X2" (at 0.15 -6.15 90) (layer "F.SilkS")
  (effects (font (size 1 1) (thickness 0.15)))
)
(fp_text value "USB_B_Micro" (at -0.2 4.2 90) (layer "F.SilkS")
  (effects (font (size 1 1) (thickness 0.15)))
)
(fp_line (start -3.75 2.75) (end -3.75 -2.75) (layer "F.Fab") (width
0.127))
(fp_line (start 3.75 2.75) (end -3.75 2.75) (layer "F.Fab") (width
0.127))
(fp_line (start 3.75 -2.75) (end 3.75 2.75) (layer "F.Fab") (width
0.127))
(fp_line (start -3.75 -2.75) (end 3.75 -2.75) (layer "F.Fab") (width
0.127))
(fp_circle (center -1.7 -3.8) (end -1.6 -3.8) (layer "F.SilkS") (width
0.15))
(fp_line (start 4.25 2.65) (end -4.25 2.65) (layer "F.CrtYd") (width
0.05))
(fp_line (start 4.25 -3.75) (end 4.25 2.65) (layer "F.CrtYd") (width
0.05))
(fp_line (start -4.25 -3.75) (end 4.25 -3.75) (layer "F.CrtYd") (width
0.05))
(fp_line (start -4.25 2.65) (end -4.25 -3.75) (layer "F.CrtYd") (width
0.05))
(fp_line (start 3.9 -2.95) (end 3.65 -2.95) (layer "F.SilkS") (width
0.127))
(fp_line (start -3.9 -2.95) (end -3.65 -2.95) (layer "F.SilkS") (width
0.127))
(fp_line (start 3.9 -2.95) (end 3.9 -1.35) (layer "F.SilkS") (width
0.127))
(fp_line (start -3.9 -2.95) (end -3.9 -1.35) (layer "F.SilkS") (width
0.127))
(fp_line (start -5.45 1.35) (end 5.5 1.35) (layer "F.Fab") (width
0.127))
(fp_text user "%V" (at -0.15 4.15 90) (layer "F.Fab")
  (effects (font (size 1 1) (thickness 0.15)))
)
(pad "6" thru_hole oval (at -3.575 0 90) (size 1 2) (drill oval 0.6 1.2
(offset 0 -0.15)) (layers *.Cu *.Mask "F.Paste")
  (net 2 "GND") (solder_paste_margin -0.01) (solder_paste_margin_ratio
-0.0001))
(pad "6" thru_hole oval (at 3.575 0 90) (size 1 2) (drill oval 0.6 1.2
(offset 0 -0.15)) (layers *.Cu *.Mask "F.Paste")
  (net 2 "GND") (solder_paste_margin -0.01) (solder_paste_margin_ratio
-0.0001))
(pad "6" thru_hole circle (at -2.425 -2.73 90) (size 1 1) (drill 0.6)
(layers *.Cu *.Mask "F.Paste")
  (net 2 "GND") (solder_paste_margin -0.01) (solder_paste_margin_ratio
-0.0001))
(pad "6" thru_hole circle (at 2.425 -2.73 90) (size 1 1) (drill 0.6)
(layers *.Cu *.Mask "F.Paste")
  (net 2 "GND") (solder_paste_margin -0.01) (solder_paste_margin_ratio
-0.0001))
(pad "1" smd roundrect (at -1.3 -2.66 90) (size 0.4 1.5) (layers "F.Cu"
"F.Paste" "F.Mask") (roundrect_rratio 0.25)
  (net 34 "VBUS") (clearance 0.19))
(pad "2" smd roundrect (at -0.65 -2.66 90) (size 0.4 1.5) (layers
"F.Cu" "F.Paste" "F.Mask") (roundrect_rratio 0.25)
  (net 62 "D-"))
(pad "3" smd roundrect (at 0 -2.66 90) (size 0.4 1.5) (layers "F.Cu"
"F.Paste" "F.Mask") (roundrect_rratio 0.25)
  (net 63 "D+"))
(pad "4" smd roundrect (at 0.65 -2.66 90) (size 0.4 1.5) (layers "F.Cu"
"F.Paste" "F.Mask") (roundrect_rratio 0.25)
  (net 59 "id_r"))
(pad "5" smd roundrect (at 1.3 -2.66 90) (size 0.4 1.5) (layers "F.Cu"
"F.Paste" "F.Mask") (roundrect_rratio 0.25)
  (net 2 "GND") (clearance 0.19))
(model
"${KISYS3DMOD}/Connector_USB.3dshapes/USB_Micro-B_Molex_47346-0001.wrl"
  (offset (xyz 0 1.2 0))
  (scale (xyz 1 1 1))
  (rotate (xyz 0 0 0))
)
  )


__
BTW, highlighting items in pcbnew seems to be broken, maybe because of the
new "real-time highlighting" for delete tool. The delete tool highlight
doesn't highlight tracks. The older selection clarification and DCR dialog
item highlighting don't work well, only some things are highlighted
sometimes. This happens with

Application: Pcbnew
Version: (5.1.0-1126-g107d206db), release build
Libraries:
wxWidgets 3.0.4
Platform: Linux 4.15.0-51-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.22
Boost: 1.65.1
OpenCASCADE Community Edition: 6.9.1
Compiler: GCC 7.4.0 with C++ ABI 1011

Build settings:
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_PYTHON3=ON
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=OFF
KICAD_USE_OCE=ON
KICAD_USE_OCC=OFF
KICAD_SPICE=OFF

__

ti 25. kesäk. 2019 klo 23.12 Jeff Young (j...@rokeby.ie) kirjoitti:

> Whoo hooo!
>
> An algorithm that doesn’t cut any conceptual corners (and so should be
> correct), and is fast as well.
>
> As always, please send in any exceptions.
>
> Cheers,
> Jeff.
>
___
Mailing list: https://launchpad.net/~kicad-developers

Re: [Kicad-developers] 6.0 Zone filling differences

[Jeff Young]

Whoo hooo!

An algorithm that doesn’t cut any conceptual corners (and so should be 
correct), and is fast as well.

As always, please send in any exceptions.

Cheers,
Jeff.


> On 25 Jun 2019, at 15:32, Jeff Young  wrote:
> 
> Well, rats.  While that’s actually a board error (spoke width larger than 
> distance between pads is never going to turn out well), it’s one that our DRC 
> doesn’t catch.
> 
> And that makes it a show-stopper.
> 
> The only way to fix this is to go back to the slow algorithm.  Hopefully I’ve 
> learned enough about optimising this to make to keep it from spiralling out 
> of control….
> 
>> On 25 Jun 2019, at 14:41, Seth Hillbrand  wrote:
>> 
>> On 2019-06-24 21:41, Jeff Young wrote:
>>> This is another excellent test because it does some pretty weird stuff
>>> (such as rounded rectangle pads mimicking circular ones so that the
>>> thermal spokes are at 90º instead of 45º).
>>> Anyway, I’ve pushed bits that make it mostly good now.  There are
>>> still 4 unconnected thermal sinks where it was taking advantage of a
>>> bug which no longer exists (thermal spokes connecting to each other
>>> rather than to the zone).
>> 
>> Hi Jeff-
>> 
>> I have another case for you.  Take a look at OLIMEX's A64-OlinuXino[1].  
>> Specifically, the HDMI connector in the top left.
>> 
>> On the thermal spokes issue, I'm not sure that we should consider that 
>> pad-pad connection to be a bug.  Do you have a sense of the level of 
>> difficulty it would be to implement the previous behavior?  I checked with a 
>> couple other packages (Altium, PADS) and this appears to be standard 
>> behavior to connect with zone fills between pads of the same net.
>> 
>> Best-
>> Seth
>> 
>> [1] https://github.com/OLIMEX/OLINUXINO/tree/master/HARDWARE/A64-OLinuXino
> 
> 
> ___
> 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


___
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

Re: [Kicad-developers] VECTOR2I and VECTOR2D

[Tomasz Wlostowski]

On 25/06/2019 21:16, Simon Richter wrote:
> Hi Wayne,
> 
> On Tue, Jun 25, 2019 at 12:36:36PM -0400, Wayne Stambaugh wrote:
> 
>> I guess I should comment on this seeing that I am the project leader.  I
>> am fine with refactoring as long as it's an improvement over existing
>> code.
> 
> The main improvement is going to be that we can dump the preprocessor magic
> for the internal units, which then allows us to share binary code between
> different kifaces, so we can turn common into a shared library.
> 

Hi Simon,

I guess you're going to add custom vector/point/dimension types that
contain units information? I would like to leave basic data structures
(e.g. VECTOR2I) unit-less.

Tom

___
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

Re: [Kicad-developers] VECTOR2I and VECTOR2D

[Simon Richter]

Hi Wayne,

On Tue, Jun 25, 2019 at 12:36:36PM -0400, Wayne Stambaugh wrote:

> I guess I should comment on this seeing that I am the project leader.  I
> am fine with refactoring as long as it's an improvement over existing
> code.

The main improvement is going to be that we can dump the preprocessor magic
for the internal units, which then allows us to share binary code between
different kifaces, so we can turn common into a shared library.

With that:

 - binary size is halved
 - qa_common tests can be merged
 - tests can be linked against a shared library (way faster)
 - the python module can be linked against a shared library
 - we no longer have different functions with the same name (great for
   debugging)

So yes, I think that'd be worth it. Getting nice unit names and some type
safety is just the icing on the cake (but necessary for refactoring, so the
compiler can tell us where the next change needs to be made).

> What changes are you planning for units and when do you expect to have
> this done?  I just branched myself to port the schematic internal units
> to 100nm in preparation for the new file formats so I'm sure there is
> going to be conflicts.  If you are almost ready to merge, I can wait but
> I'm ready to get started on this so I would rather not wait too long.

My approach for the length units can be merged incrementally, so there is
an intermediate stage where it will convert between "old" and "new"
internal units at the boundaries (by multiplying or dividing with the
appropriate factor according to the -D flag from the command line) and
issue a warning "refactor here".

So I can effectively rebase my branch on top of whatever changes you have,
the compatibility code will keep it working. Merging would happen in
multiple stages anyway, with the compatibility code remaining in place
until everyone's development branches are merged or rebased.

That's why I listed

> > Replacing points will be too big to do in a single commit, so:
> > 
> >  - create strong types for lengths and points [needs rework]
> >  - literal handling with unit suffix [mostly done]
> >  - compatibility code for automatic conversion to existing formats [mostly
> >done]
> >  - piecewise replacement of existing coordinate code
> >  - remove compatibility code
> >  - remove old code
> >  - remove -DEESCHEMA, -DPCBNEW etc.
> >  - merge pcbcommon into common

Each of these steps live in separate commits, and every commit takes us
from a working state to another working state.

   Simon

___
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

Re: [Kicad-developers] VECTOR2I and VECTOR2D

[Wayne Stambaugh]

I guess I should comment on this seeing that I am the project leader.  I
am fine with refactoring as long as it's an improvement over existing
code.  In this case, I would say that some refactoring is in order
although I would proceed cautiously with the code in question.  OOP does
not necessary translate to more maintainable and/or understandable code.
 Please don't confuse programming paradigms for religion.  I have been
at this for 30 years and have heard the promises (sales pitches?) of how
every new programming paradigm was going to save us from ourselves.  I'm
still waiting ;)

On 6/23/19 11:03 AM, Simon Richter wrote:
> Hi,
> 
> On Fri, Jun 21, 2019 at 10:54:04PM -0400, Reece R. Pollack wrote:
> 
>> Just for discussion, let's assume the replacement for wxPoint is
>> named KiPoint. The result of subtracting two KiPoint objects would
>> be another object called KiDelta. Adding two KiPoint objects should
>> be undefined, and result in a compile-time error, as this is a
>> nonsense operation.
> 
> I have something like that cooking in my "units" branch, but I'm cleaning
> up angles first.

Simon,

What changes are you planning for units and when do you expect to have
this done?  I just branched myself to port the schematic internal units
to 100nm in preparation for the new file formats so I'm sure there is
going to be conflicts.  If you are almost ready to merge, I can wait but
I'm ready to get started on this so I would rather not wait too long.

Cheers,

Wayne

> 
> Plan:
> 
>  - create strong types for angles and orientations [done]
>  - literal handling with unit suffix [done]
>  - replace all instances of angles in the codebase [under way]
>  - drop code to support angles expressed as doubles, ints, ...
> 
> Replacing points will be too big to do in a single commit, so:
> 
>  - create strong types for lengths and points [needs rework]
>  - literal handling with unit suffix [mostly done]
>  - compatibility code for automatic conversion to existing formats [mostly
>done]
>  - piecewise replacement of existing coordinate code
>  - remove compatibility code
>  - remove old code
>  - remove -DEESCHEMA, -DPCBNEW etc.
>  - merge pcbcommon into common
> 
> The way I went with my approach was that there is a length class that
> expresses a 1D length in either nanometers. A separate class does the same
> for pixels.
> 
> 2D coordinates have a template parameter for the underlying 1D type, and
> for the origin point they are relative to:
> 
>  - no origin
>  - (0, 0)
>  - current reference (set with the space bar)
>  - auxiliary axis (set with the aux axis tool)
> 
> Adding and subtracting then makes sure origin points are consistent, and
> multiplying with the current zoom level converts between world and screen
> coordinates.
> 
> The initial implementation went a bit wrong because the angle handling
> needs to be done first -- the transition requires adding a new coordinate
> type parallel to the existing ones, which also requires a full set of
> Rotate* functions (degrees as double, tenth-degrees as double,
> tenth-degrees as signed int, radians as double), so reducing all of these
> to one makes this manageable.
> 
>Simon
> 
> ___
> 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
> 

___
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

Re: [Kicad-developers] 6.0 Zone filling differences

[Jeff Young]

Well, rats.  While that’s actually a board error (spoke width larger than 
distance between pads is never going to turn out well), it’s one that our DRC 
doesn’t catch.

And that makes it a show-stopper.

The only way to fix this is to go back to the slow algorithm.  Hopefully I’ve 
learned enough about optimising this to make to keep it from spiralling out of 
control….

> On 25 Jun 2019, at 14:41, Seth Hillbrand  wrote:
> 
> On 2019-06-24 21:41, Jeff Young wrote:
>> This is another excellent test because it does some pretty weird stuff
>> (such as rounded rectangle pads mimicking circular ones so that the
>> thermal spokes are at 90º instead of 45º).
>> Anyway, I’ve pushed bits that make it mostly good now.  There are
>> still 4 unconnected thermal sinks where it was taking advantage of a
>> bug which no longer exists (thermal spokes connecting to each other
>> rather than to the zone).
> 
> Hi Jeff-
> 
> I have another case for you.  Take a look at OLIMEX's A64-OlinuXino[1].  
> Specifically, the HDMI connector in the top left.
> 
> On the thermal spokes issue, I'm not sure that we should consider that 
> pad-pad connection to be a bug.  Do you have a sense of the level of 
> difficulty it would be to implement the previous behavior?  I checked with a 
> couple other packages (Altium, PADS) and this appears to be standard behavior 
> to connect with zone fills between pads of the same net.
> 
> Best-
> Seth
> 
> [1] https://github.com/OLIMEX/OLINUXINO/tree/master/HARDWARE/A64-OLinuXino


___
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

Re: [Kicad-developers] 6.0 Zone filling differences

[Seth Hillbrand]

On 2019-06-24 21:41, Jeff Young wrote:

This is another excellent test because it does some pretty weird stuff
(such as rounded rectangle pads mimicking circular ones so that the
thermal spokes are at 90º instead of 45º).

Anyway, I’ve pushed bits that make it mostly good now.  There are
still 4 unconnected thermal sinks where it was taking advantage of a
bug which no longer exists (thermal spokes connecting to each other
rather than to the zone).


Hi Jeff-

I have another case for you.  Take a look at OLIMEX's A64-OlinuXino[1].  
Specifically, the HDMI connector in the top left.


On the thermal spokes issue, I'm not sure that we should consider that 
pad-pad connection to be a bug.  Do you have a sense of the level of 
difficulty it would be to implement the previous behavior?  I checked 
with a couple other packages (Altium, PADS) and this appears to be 
standard behavior to connect with zone fills between pads of the same 
net.


Best-
Seth

[1] 
https://github.com/OLIMEX/OLINUXINO/tree/master/HARDWARE/A64-OLinuXino


___
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

Re: [Kicad-developers] Do we own our samples?

[Wayne Stambaugh]

AFAIK we do.  They do tend to fall behind the KiCad capabilities and the
library changes.  I'm fine with updating them unless someone has a
reason not to.

Cheers,

Wayne

On 6/25/19 6:34 AM, Jeff Young wrote:
> Should we fix bugs in them?
> 
> Couple of examples:
> 
> - unnecessary ground traces in video (looks like they were used before a 
> ground plane was added?)
> 
> - "+8/12V" copper text clearance issue on pic_programmer
> 
> Thanks,
> Jeff
> ___
> 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
> 

___
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

[Kicad-developers] Do we own our samples?

[Jeff Young]

Should we fix bugs in them?

Couple of examples:

- unnecessary ground traces in video (looks like they were used before a ground 
plane was added?)

- "+8/12V" copper text clearance issue on pic_programmer

Thanks,
Jeff
___
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