kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo_bernardo@xxxxxxxxx>]

----- Original Message -----
> From: Wayne Stambaugh <stambaughw@xxxxxxxxxxx>
> To: kicad-developers@xxxxxxxxxxxxxxxxxxx
> Cc: 
> Sent: Thursday, December 19, 2013 7:09 AM
> Subject: Re: [Kicad-developers] bugs 1261583 and 1236583
> 
> On 12/18/2013 2:51 PM, Cirilo Bernardo wrote:
>>  ----- Original Message -----
>> 
>>>  From: jp charras <jp.charras@xxxxxxxxxx>
>>>  To: kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>  Cc: 
>>>  Sent: Thursday, December 19, 2013 6:27 AM
>>>  Subject: Re: [Kicad-developers] bugs 1261583 and 1236583
>>> 
>>>  Le 18/12/2013 19:36, Wayne Stambaugh a écrit :
>>>>   On 12/18/2013 1:29 PM, jp charras wrote:
>>>>>   Le 18/12/2013 06:02, Cirilo Bernardo a écrit :
>>>>>>   These bugs are identical and concern the 3D viewer 
> (rectangular
>>>>>>   outline used because adjacent segments fail the exact 
> endpoint
>>>>>>   test).
>>>>>> 
>>>>>>   The line causing this is in specctra_export.cpp, line 
> 1011:
>>>>>> 
>>>>>>   prox = Mils2iu( 0 );
>>>>>> 
>>>>>> 
>>>>>>   I did not submit a patch because I believe some discussion 
> is
>>>>>>   necessary about the limit imposed for the closeness of 
> points and 
>>>  the
>>>>>>   routine (fillBOUNDARY) is also used by the specctra 
> exporter.  In 
>>>  bug
>>>>>>   1236583 the user has points which differ by 500nm.  In bug 
> 1261583
>>>>>>   the difference in the DXF file is less than 10nm.
>>>>>> 
>>>>>>   Is it possible to change the limit without adversely 
> affecting the
>>>>>>   specctra export, and if so, what limit would people 
> consider
>>>>>>   reasonable? From my point of view, the worst case which 
> isn't 
>>>  in the
>>>>>>   domain of the plain ridiculous would be that someone uses 
> a 32-bit
>>>>>>   float representation of a board which is about 1000mm 
> across - that
>>>>>>   would give a worst case expectation of about 1 micron. I 
> would
>>>>>>   imagine even 10 microns should be acceptable given modern
>>>>>>   manufacturing techniques and limitations of reality.
>>>>>> 
>>>>>>   - Cirilo
>>>>> 
>>>>>   You can try:
>>>>>   prox = Mils2iu( 1 );
>>>>> 
>>>>>   One mil is certainly acceptable, and should be enough for 
> rounding
>>>>>   issues when arcs are converted from dxf files.
>>>>> 
>>>> 
>>>>   This may solve the 3D drawing issue but is it acceptable to export 
> to
>>>>   specctra with an unclosed board outline?  I seem to remember there 
> being
>>>>   some debate as to whether or not that is valid.  The other option 
> is
>>>>   attempt to close any gaps in the board outline only for 3D 
> rendering
>>>>   purposes and enforce a closed board outline for specctra export.
>>> 
>>>  You are right.
>>>  I'll make more tests soon with exported dsn files.
>>> 
>>>  However 3D drawing needs valid polygons to display the board outlines
>>>  and holes.
>>>  And specctra export uses prox = Mils2iu( 10 ); to find holes inside the
>>>  board.
>>>  This is the reasons I proposed prox = Mils2iu( 1 ); in main outlines
>>>  calculations.
>>> 
>>>  -- 
>>>  Jean-Pierre CHARRAS
>>> 
>>> 
>> 
>> 
>>  MCAD software can also be very strict with the IDF outline; what I did for 
> IDF was to force the end segments to be the same by writing only 1 point from 
> each segment except for the first point (2 points) and the last point (none). 
> fillBOUNDARY() also does this; if we patch line 1101 (test for closed polygon) 
> to replace the last point with the first point then there will be no problem for 
> specctra either.
>> 
>>  - Cirilo
>> 
> 
> Your assuming that closing the outline is what the user wants but this
> may not always be the case.  There is no harm in closing the board
> outline for 3D rendering purposes since there is no danger of this
> causing other problems.  I would be reluctant to automatically close a
> board outline when exporting to other formats or plotting to prevent
> unexpected surprises when the boards are manufactured.  If you do decide
> to automagically close board outlines, please make it an option.  I want
> to know when I've failed to create a fully enclosed board outline so I
> can fix it rather than ending up with a board outline that isn't what I
> expected.  Maybe I'm being paranoid but I would rather error on the side
> of caution.
> 
> 


The board outline will only be closed if the proximity condition is met (1 mil). I don't believe this will be a problem; if the condition is not met, a rectangular board will be created by default. This wouldn't be a problem in manufacturing either since no reasonable PCB manufacturing technique can leave a gap of 1 mil in a cutout. Going back to the bug reports, the differences we are talking about are on the order of 0.5microns and 10 nanometers; we can always specify something like 'prox = 600' (0.6micron) rather than using Mils2IU( 1 ) which gives us 25.4 microns.

Where I do see the scheme failing is when people put cutouts too close to the border and the routine accidentally captures the wrong segment; this would be a pathological case which the user should identify and fix, not something which the software should be responsible for.

Anyway, in the worst case we simply add an optional argument to fillBOUNDARY which defaults to 0 mil and we touch up GetBoardPolygonOutlines() to pass a value of 1 mil. No changes will be necessary to the calls made by the specctra export routines.

- Cirilo