kicad-developers team mailing list archive

[Maciej Sumiński <maciej.suminski@xxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/03/2014 08:54 AM, Lorenzo Marcantonio wrote:
> 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.

I have never tried to order a T-shaped cut. What is the exact issue
with that? I am wondering if it is still a real problem if the
protruding part was within the Edge.Cuts line thickness (let's say 0.1
mm).

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

Healing could be done another way. Instead of moving vertices, it
could be better to add the missing segments. If they are no longer
than a line thickness, then it is not noticeable to bare eye and
should fix the manufacturing problem. User should be notified of such
changes, so he could verify them.

Regards,
Orson

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJUBs+pAAoJEBRwGu1hpbJ1AoQH/jUimQmzimyB4bu6nov+hfdQ
zixdeulVsKnrlrJ21vXDOuv86MdrNIqniV8/15X3wTOxCQtLKEooDdSIX9u/WWvP
NxnJFZdt7Gz2GsQ6gOdhETCBNkiCPRNTJBgNTxMpDmrx2NjbNEDTTqaPatTRoS3R
KQZPzUL0Ygyg9mTkFAIvIeNEiilPeuq2JLiUrxiNTp2HpJLCdOcO4IV4ph0bd4I4
MBqFDi8KCvlFY0wYz6hJzuK2nHDdLa6T8GUZx7C18H9vsVuI18kRSlLdE5VLg+JM
GhjvL41BTxmSlRVlIJ4JLfcH8nDL+FOGbN/X9/b0htMqV5uXM/9h4O5OWrpEvkw=
=bdwu
-----END PGP SIGNATURE-----