kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

Pondered some more about the issue.

Accepting the edges within a tolerance doesn't seem to be a good
solution... explanation:

When generating gerbers/specctra/IDF whatever they want the 'true
vertices' to make, essentially a toolpath. And that must be valid and
manufacturable; for example given a corner you could have two
situations:
  O---  O----
          
O          O
|  A     B | 
|          |
|          |

Case A would be acceptable (giving a chamfered corner), case B would
not probably pass manufacturing DRC.

So vertices should match for at least the output file resolution (which
in some case is substantially a double) i.e. they must be the same.

However given that a sane designer work on a grid (0.05mm in my case),
when modules are sane they are pretty easy to match exactly by hand: if
the edge is on the grid in the module, it will be too in the board (if
module is placed on a grid). If module is rotated to some arbitrary
angle (i.e. not PI/4 multiples), well, trascendent functions take no
prisoners :D

I can see at least two ways to solve the issue at hand: either a)
implement some kind of endpoint snap when drawing edges (that would be
generally useful) or b) add a "fix board outline" step in the board
cleanup that would align mismatching vertices (using a tolerance, as
proposed); something like mesh healing in 3D.

I think that function would need only to treat board-to-module
connections: edges in module are supposed to be drawn correctly by the
module designer, and the same would be for edges on the board. When
a board edge attaches to a module edge (and the ends don't match)
I think the best thing to do is to move the board end to match the
module end (edge in modules are probably more tolerance sensitive than
board ones). Line-to-arc connections (every one of these, and probably
transparently) would be
probably best solved moving the line endpoint, while arc-to-arc are IMHO
quite difficult to handle in the general case, at least with out arc
representation (center, radius, angles IIRC). Autodesk polyline
representation (start, end, bulge) or the G-code one would be quite easier to handle (and
the math in not too much obscene).

Other 'holes' in the board contour are better left flagged by the DRC
for user attention.

-- 
Lorenzo Marcantonio
Logos Srl