Re: [Kicad-developers] BOARD_ITEMs removal

[Maciej Sumiński]

On 12/18/2013 09:00 PM, Wayne Stambaugh wrote:

On 12/4/2013 2:06 PM, Maciej Sumiński wrote:

I am digging through the code responsible for BOARD_ITEMs removal and I
have a few questions that are probably easy to answer for people, who
know the source code better than I do.

I have found two places where removal happens:
- void PCB_EDIT_FRAME::RemoveStruct( BOARD_ITEM* Item, wxDC* DC )
called when there is only one item to remove (user pressed the Delete
key when an item was under the cursor)

- void PCB_EDIT_FRAME::Block_Delete()
used for removal of block of items (user selected a block of items,
right-clicked and chose "Delete block")

Why are they handled in a different way? Is it only to avoid multiple
ratsnest compilations or refreshing the whole canvas vs xoring single
items to erase?

There are also various way to remove items:
- void BOARD_ITEM::UnLink() & void BOARD_ITEM::DeleteStructure()
- BOARD_ITEM* BOARD::Remove( BOARD_ITEM* aBoardItem ) & void
BOARD::Delete( BOARD_ITEM* aBoardItem )

I can easily say the difference between BOARD_ITEM::Unlink &
DeleteStructure or BOARD::Remove & BOARD::Delete, but I am not able to
say why BOARD_ITEM::Unlink() and BOARD::Remove() coexist. Do not they
simply remove items from DLISTs stored in the BOARD class?

Thanks in advance,
Orson



Orson,

The only reason I see that BOARD::Remove() has to stay is that
MARKER_PCB and ZONE_CONTAINER objects are not stored DLISTs.  They are
std::vectors so BOARD_ITEM::Unlink() would not remove them from a
vector.  I'm not sure why this was done this way.  If they were changed
to DLISTs, BOARD::Remove() could be eliminated.

Wayne


Thank you for the explanation, it is quite clear now. I am going to 
investigate if it can be changed without creating new problems, in order 
to unify this and avoid confusion.


Regards,
Orson

___
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] patch to fix bug in DXF plot

[Cirilo Bernardo]

- Original Message -

> From: Wayne Stambaugh 
> To: kicad-developers@lists.launchpad.net
> Cc: 
> Sent: Thursday, December 19, 2013 8:52 AM
> Subject: Re: [Kicad-developers] patch to fix bug in DXF plot
> 
> On 12/17/2013 5:03 AM, Cirilo Bernardo wrote:
> 
>>  Hi folks,
>> 
>>   There is a bug in DXF plot which changes the included angle of arcs. To 
> demonstrate the bug:
>> 
>>  1. in the edge cutout layer, create a rectangle with rounded corners and 
> plot the layer to DXF. Since KiCad will write a PCB file with all angles = 
> +90, 
> everything is OK.
>> 
>>  2. Delete the cutout layer and import the DXF. At this point everything 
> should look OK.
>> 
>>  3. Plot the dxf again; this time things go bad because the DXF importer 
> marked some angles as -90 in Step 2.
>> 
>>  4. Import the bad DXF (or view it with MCAD software).
>> 
>>  I have only fixed the bug in BRDITEMS_PLOTTER::PlotDrawSegment and only for 
> DXF plotting. I did not create tests to check if the problem exists with 
> other 
> types of plotting routines (it is possible others are affected, but not 
> necessarily so) and I did not investigate problems with exporting an Arc in 
> BRDITEMS_PLOTTER::Plot_1_EdgeModule.
>> 
>>  Cheers,
>>  Cirilo
> 
> Your patch does not work for the attached board edge cuts layer so I am
> reluctant to commit it.  It may work for your case but it may have
> broken another corner case.  Don't feel bad, the current DXF plot does
> not plot this board correctly either.  I've known about this problem for
> a while but have been too lazy to fix it.  There is some oddness in the
> way the DXF defines arcs that I am not completely familiar with.  If you
> can get the attached board to plot correctly without breaking all of the
> other DXF arc plotting, you'll get a hardy pat on back and your patch
> committed. :)  Also, your editor is leaving trailing white space which
> is a violation of the coding policy.
> 
> What I really would like to see is converting our DXF plotting over to
> use the dxflib that JP recently added to the project.  It seems like a
> much more complete solution which could give us better results in terms
> of layer and color support.  Arcs with width would be nice too.  Maybe
> you could become the guru of DXF plotting.
> 
> Thanks,
> 
> Wayne
> 
> 


Thanks Wayne,  I'll look into it. My suspicion is that in the short term I can 
come up with something that fixes DXF_plot. Actually writing something with 
dxflib will take a bit more time; I've got to (re)read the DXF documentation.

- Cirilo

___
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] patch to fix bug in DXF plot

[Wayne Stambaugh]

On 12/17/2013 5:03 AM, Cirilo Bernardo wrote:
> Hi folks,
> 
>  There is a bug in DXF plot which changes the included angle of arcs. To 
> demonstrate the bug:
> 
> 1. in the edge cutout layer, create a rectangle with rounded corners and plot 
> the layer to DXF. Since KiCad will write a PCB file with all angles = +90, 
> everything is OK.
> 
> 2. Delete the cutout layer and import the DXF. At this point everything 
> should look OK.
> 
> 3. Plot the dxf again; this time things go bad because the DXF importer 
> marked some angles as -90 in Step 2.
> 
> 4. Import the bad DXF (or view it with MCAD software).
> 
> I have only fixed the bug in BRDITEMS_PLOTTER::PlotDrawSegment and only for 
> DXF plotting. I did not create tests to check if the problem exists with 
> other types of plotting routines (it is possible others are affected, but not 
> necessarily so) and I did not investigate problems with exporting an Arc in 
> BRDITEMS_PLOTTER::Plot_1_EdgeModule.
> 
> Cheers,
> Cirilo

Your patch does not work for the attached board edge cuts layer so I am
reluctant to commit it.  It may work for your case but it may have
broken another corner case.  Don't feel bad, the current DXF plot does
not plot this board correctly either.  I've known about this problem for
a while but have been too lazy to fix it.  There is some oddness in the
way the DXF defines arcs that I am not completely familiar with.  If you
can get the attached board to plot correctly without breaking all of the
other DXF arc plotting, you'll get a hardy pat on back and your patch
committed. :)  Also, your editor is leaving trailing white space which
is a violation of the coding policy.

What I really would like to see is converting our DXF plotting over to
use the dxflib that JP recently added to the project.  It seems like a
much more complete solution which could give us better results in terms
of layer and color support.  Arcs with width would be nice too.  Maybe
you could become the guru of DXF plotting.

Thanks,

Wayne
(kicad_pcb (version 3) (host pcbnew "(2013-12-14 BZR 4555)-product")

  (general
(links 18)
(no_connects 0)
(area 133.390641 88.811099 150.811654 105.5243)
(thickness 1.6002)
(drawings 5)
(tracks 35)
(zones 0)
(modules 10)
(nets 7)
  )

  (page A)
  (title_block
(title "PCA168 BAE DUAL HALL EFFECT BOARD")
(rev -)
(company "Motion Sensors, Inc.")
  )

  (layers
(15 Front signal)
(0 Back signal)
(16 B.Adhes user)
(17 F.Adhes user)
(18 B.Paste user)
(19 F.Paste user)
(20 B.SilkS user)
(21 F.SilkS user)
(22 B.Mask user)
(23 F.Mask user)
(24 Dwgs.User user)
(25 Cmts.User user)
(26 Eco1.User user)
(27 Eco2.User user)
(28 Edge.Cuts user)
  )

  (setup
(last_trace_width 0.254)
(trace_clearance 0.254)
(zone_clearance 0.254)
(zone_45_only no)
(trace_min 0.1778)
(segment_width 0.381)
(edge_width 0.381)
(via_size 0.889)
(via_drill 0.635)
(via_min_size 0.635)
(via_min_drill 0.381)
(uvia_size 0.508)
(uvia_drill 0.127)
(uvias_allowed no)
(uvia_min_size 0.381)
(uvia_min_drill 0.127)
(pcb_text_width 0.3048)
(pcb_text_size 1.524 2.032)
(mod_edge_width 0.127)
(mod_text_size 0.7112 0.762)
(mod_text_width 0.127)
(pad_size 3.2104 2.8077)
(pad_drill 0)
(pad_to_mask_clearance 0.0762)
(solder_mask_min_width 0.1016)
(aux_axis_origin 0 0)
(visible_elements 7F7F)
(pcbplotparams
  (layerselection 271613953)
  (usegerberextensions false)
  (excludeedgelayer false)
  (linewidth 0.15)
  (plotframeref false)
  (viasonmask false)
  (mode 1)
  (useauxorigin false)
  (hpglpennumber 1)
  (hpglpenspeed 20)
  (hpglpendiameter 15)
  (hpglpenoverlay 2)
  (psnegative false)
  (psa4output false)
  (plotreference true)
  (plotvalue false)
  (plotothertext false)
  (plotinvisibletext false)
  (padsonsilk false)
  (subtractmaskfromsilk false)
  (outputformat 3)
  (mirror false)
  (drillshape 2)
  (scaleselection 1)
  (outputdirectory drawings/))
  )

  (net 0 "")
  (net 1 /CH1_COM)
  (net 2 /CH1_DOUT)
  (net 3 /CH1_VIN)
  (net 4 /CH2_DOUT)
  (net 5 /~CH1_DOUT)
  (net 6 /~CH2_DOUT)

  (net_class Default "This is the default net class."
(clearance 0.254)
(trace_width 0.254)
(via_dia 0.889)
(via_drill 0.635)
(uvia_dia 0.508)
(uvia_drill 0.127)
(add_net "")
  )

  (net_class Signal ""
(clearance 0.1778)
(trace_width 0.1778)
(via_dia 0.635)
(via_drill 0.381)
(uvia_dia 0.508)
(uvia_drill 0.127)
(add_net /CH1_COM)
(add_net /CH1_DOUT)
(add_net /CH1_VIN)
(add_net /CH2_DOUT)
(add_net /~CH1_DOUT)
(add_net /~CH2_DOUT)
  )

  (gr_line (start 148.9583 92.71) (end 148.9583 100.584) (angle 90) (layer 
Edge.Cuts) (width 0.381))
  (gr_arc (start 142.1384 96.647) (end 148.9583 92.71) (angle -30

[Kicad-developers] proposed patch, bugs 1261583 and 1236583

[Cirilo Bernardo]

Following discussions on the bugs 1261583 and 1236583 I have attached a 
possible solution.

1. An optional argument has been added to fillBOUNDARY() to allow the user to 
specify an acceptable error in the boundary segment points. The default value 
is '0' and specctra export routines which call fillBOUNDARY() will operate as 
before and without modification.

2. GetBoardPolygonOutlines() invokes fillBOUNDARY() with the optional argument 
equal to 1 mil. This closes bugs 1261583 and 1236583.

The patch was tested by importing the DXF provided in bug report 1261583 and 
the 3D viewer now displays the correct outline while a specctra export throws 
an exception as it previously did. This should also close bug 1236583 since the 
error in that case was about .02 mil.

The only remaining question is whether the old specctra behavior should be 
maintained or if it is sensible to remove the optional argument and agree on a 
non-zero value for use in the proximity test on the outline. The value need not 
be specified in mils either; we can use the internal units to specify a smaller 
allowable error.

- Cirilo
=== modified file 'pcbnew/specctra.h'
--- pcbnew/specctra.h	2013-10-04 08:42:09 +
+++ pcbnew/specctra.h	2013-12-18 21:26:24 +
@@ -3752,8 +3752,9 @@
  * in the specctra element tree.
  * @param aBoard The BOARD to get information from in order to make the BOUNDARY.
  * @param aBoundary The empty BOUNDARY to fill in.
+ * @param aRadius Radius, in mils, for the outline's point closeness test
  */
-void fillBOUNDARY( BOARD* aBoard, BOUNDARY* aBoundary ) throw( IO_ERROR );
+void fillBOUNDARY( BOARD* aBoard, BOUNDARY* aBoundary, int aRadius = 0 ) throw( IO_ERROR );
 
 /**
  * Function makeIMAGE

=== modified file 'pcbnew/specctra_export.cpp'
--- pcbnew/specctra_export.cpp	2013-10-28 20:34:06 +
+++ pcbnew/specctra_export.cpp	2013-12-18 21:29:08 +
@@ -876,7 +876,7 @@
 }
 
 
-void SPECCTRA_DB::fillBOUNDARY( BOARD* aBoard, BOUNDARY* boundary ) throw( IO_ERROR )
+void SPECCTRA_DB::fillBOUNDARY( BOARD* aBoard, BOUNDARY* boundary, int aRadius ) throw( IO_ERROR )
 {
 TYPE_COLLECTOR  items;
 unsignedprox;   // a proximity BIU metric, not an accurate distance
@@ -1008,7 +1008,9 @@
 
 // Set maximum proximity threshold for point to point nearness metric for
 // board perimeter only, not interior keepouts yet.
-prox = Mils2iu( 0 );
+if( aRadius < 0 )
+aRadius = 0;
+prox = Mils2iu( aRadius );
 
 // Output the Edge.Cuts perimeter as circle or polygon.
 if( graphic->GetShape() == S_CIRCLE )
@@ -1098,8 +1100,16 @@
 break;
 }
 
-if( close_enough( startPt, prevPt, prox ) ) // the polygon is closed.
+if( close_enough( startPt, prevPt, prox ) )
+{
+// the polygon is closed.
+if( aRadius && path->GetPoints().size() > 1 )
+{
+path->GetPoints().pop_back();
+path->AppendPoint( mapPt( startPt ) );
+}
 break;
+}
 
 graphic = findPoint( prevPt, &items, prox );
 
@@ -1283,7 +1293,7 @@
 
 try
 {
-fillBOUNDARY( aBoard, boundary );
+fillBOUNDARY( aBoard, boundary, 1 );
 std::vector buffer;
 boundary->GetCorners( buffer );
 

___
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] bugs 1261583 and 1236583

[Cirilo Bernardo]

- Original Message -
> From: Wayne Stambaugh 
> To: kicad-developers@lists.launchpad.net
> 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 
>>>  To: kicad-developers@lists.launchpad.net
>>>  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, n

Re: [Kicad-developers] bugs 1261583 and 1236583

[Wayne Stambaugh]

On 12/18/2013 2:51 PM, Cirilo Bernardo wrote:
> - Original Message -
> 
>> From: jp charras 
>> To: kicad-developers@lists.launchpad.net
>> 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.



___
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] BOARD_ITEMs removal

[Wayne Stambaugh]

On 12/4/2013 2:06 PM, Maciej Sumiński wrote:
> I am digging through the code responsible for BOARD_ITEMs removal and I
> have a few questions that are probably easy to answer for people, who
> know the source code better than I do.
> 
> I have found two places where removal happens:
> - void PCB_EDIT_FRAME::RemoveStruct( BOARD_ITEM* Item, wxDC* DC )
> called when there is only one item to remove (user pressed the Delete
> key when an item was under the cursor)
> 
> - void PCB_EDIT_FRAME::Block_Delete()
> used for removal of block of items (user selected a block of items,
> right-clicked and chose "Delete block")
> 
> Why are they handled in a different way? Is it only to avoid multiple
> ratsnest compilations or refreshing the whole canvas vs xoring single
> items to erase?
> 
> There are also various way to remove items:
> - void BOARD_ITEM::UnLink() & void BOARD_ITEM::DeleteStructure()
> - BOARD_ITEM* BOARD::Remove( BOARD_ITEM* aBoardItem ) & void
> BOARD::Delete( BOARD_ITEM* aBoardItem )
> 
> I can easily say the difference between BOARD_ITEM::Unlink &
> DeleteStructure or BOARD::Remove & BOARD::Delete, but I am not able to
> say why BOARD_ITEM::Unlink() and BOARD::Remove() coexist. Do not they
> simply remove items from DLISTs stored in the BOARD class?
> 
> Thanks in advance,
> Orson
> 

Orson,

The only reason I see that BOARD::Remove() has to stay is that
MARKER_PCB and ZONE_CONTAINER objects are not stored DLISTs.  They are
std::vectors so BOARD_ITEM::Unlink() would not remove them from a
vector.  I'm not sure why this was done this way.  If they were changed
to DLISTs, BOARD::Remove() could be eliminated.

Wayne



___
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] bugs 1261583 and 1236583

[Cirilo Bernardo]

- Original Message -

> From: jp charras 
> To: kicad-developers@lists.launchpad.net
> 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


___
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] bugs 1261583 and 1236583

[jp charras]

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

___
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] bugs 1261583 and 1236583

[Wayne Stambaugh]

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.


___
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] bugs 1261583 and 1236583

[jp charras]

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.

-- 
Jean-Pierre CHARRAS

___
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