← Back to team overview

kicad-developers team mailing list archive

Re: 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.




Follow ups

References