X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=PJYvFS6EFE3LgIXCJNFfB4mOK+qX3Hw6VmLh93HyidI=; b=dkXadoPgrdTEUy2yeSSm+rpHOABbw+q2qmaEFAECq1KVQxcYClZtMUKTcOUBWH/tQc KZdqMqZWvOwctUtpNrQxJ0IT08gKAcml4x6k3HOUhqWk5KlH9DkoxskoZt0ogxiOss6B /8NmlY/FqP9o1bs7qJOQ0JnC47eM4K450yPBokIfF4XPuL63cjd5pWL1ed6R+e6v7U9B ZcVZcTvyW6EssNfWjHSHo3dDNZ3OU73+APeC5Ru46YAeH1gUI9GxJumYoFxzI6GPFC1M 1cnaFmrtJutgx/qurKBiQOiPsVQgU00E676ZcLoT52IlMv2Ql3RWpmnZOr0Sy4Vg+G3f zaTQ== MIME-Version: 1.0 X-Received: by 10.60.94.82 with SMTP id da18mr28414330oeb.40.1452510329953; Mon, 11 Jan 2016 03:05:29 -0800 (PST) In-Reply-To: <5693884C.7080003@iee.org> References: <56928D6F DOT 6080807 AT ecosensory DOT com> <5692AFEC DOT 9060807 AT ecosensory DOT com> <20160110213849 DOT 460c7bb14e8f6645138bebd8 AT gmail DOT com> <20160111080228 DOT GA32662 AT visitor2 DOT iram DOT es> <20160111094144 DOT bee82694c414c1cc36b98cf8 AT gmail DOT com> <5693884C DOT 7080003 AT iee DOT org> Date: Mon, 11 Jan 2016 11:05:29 +0000 Message-ID: Subject: Re: [geda-user] Primitive electrical types --> layers From: "Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com]" To: gEDA User Mailing List Content-Type: multipart/alternative; boundary=089e011603f63fe5f505290ceae1 Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk --089e011603f63fe5f505290ceae1 Content-Type: text/plain; charset=UTF-8 On 11 January 2016 at 10:47, M. J. Everitt (m DOT j DOT everitt AT iee DOT org) [via geda-user AT delorie DOT com] wrote: > On 11/01/16 08:41, Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via > geda-user AT delorie DOT com] wrote:Surely its sufficient to draw in the outline > your intended > cut-out/slit/etc .. now possibly making this "Keep-out" in other layers > may be desirable, but since you're using a milling cutter to do the > outline, you need a path for it to follow. Perhaps you can 'shade' this > in the GUI - I see no need for additional complexities making polygons, > figuring out perimeters, etc, when you can line-draw and need to anyway. > Perhaps having an outline 'layer' might help you achieve what you're > hoping for? We've even milled curved board outlines, using the curve > tool, and our fab. have managed this perfectly without problems. > The convention is usually, that you model what you want as the physically produced, post-manufacturing shape. (This is the same with mechanical CAD too).. Tool-paths, drill size corrections (allowance for plating, or approximation of nearest available drill size), are the scope of the CAM post-processor. The reason board outlines as primitive lines on a drawing layer is not a great idea, is that those lines are drawn with finite-thickness, leaving the requirement of some convention for interpretation. Usually fabs follow the center-line I believe, but possible ambiguity here is why they often insist on the line being drawn in a small width. Due to coordinate rounding etc.., when curves get involved, you will often find miniscule gaps between outline segments, that the CAM system must jump over. (Not necessarily a "problem", but an additional heuristic, and potential for error with this approach). This is why all the more advanced board representation formats model an explicit outline, with poly(curve) type primitives, so an explicit design intent of the finished shape can be modelled. This is effectively a "polygon" shape in PCB, especially once the patches adding support for curved edges are merged. To avoid ambiguity in interpretation, this "polygon" needs (I believe) to be a first-class property of the stack-up model. (Something I'm working on designing and adding currently). Peter --089e011603f63fe5f505290ceae1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 11 January 2016 at 10:47, M. J. Everitt (m DOT j DOT everitt AT iee DOT org) [via geda-user AT delorie DOT com] <geda-user AT delorie DOT com= > wrote:
On 11/01/16 08:41, Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com<= /a>) [via
geda-user AT d= elorie.com] wrote:Surely its sufficient to draw in the outline your int= ended
cut-out/slit/etc .. now possibly making this "Keep-out" in other = layers
may be desirable, but since you're using a milling cutter to do the
outline, you need a path for it to follow. Perhaps you can 'shade' = this
in the GUI - I see no need for additional complexities making polygons,
figuring out perimeters, etc, when you can line-draw and need to anyway. Perhaps having an outline 'layer' might help you achieve what you&#= 39;re
hoping for? We've even milled curved board outlines, using the curve tool, and our fab. have managed this perfectly without problems.


The convention is usually, that you model wha= t you want as the physically produced, post-manufacturing shape. (This is t= he same with mechanical CAD too)..

Tool-paths, drill size= corrections (allowance for plating, or approximation of nearest available = drill size), are the scope of the CAM post-processor.

The reason board outlines as primitive lines on a drawing layer is = not a great idea, is that those lines are drawn with finite-thickness, leav= ing the requirement of some convention for interpretation. Usually fabs fol= low the center-line I believe, but possible ambiguity here is why they ofte= n insist on the line being drawn in a small width. Due to coordinate roundi= ng etc.., when curves get involved, you will often find miniscule gaps betw= een outline segments, that the CAM system must jump over. (Not necessarily = a "problem", but an additional heuristic, and potential for error= with this approach).

This is why all the more advanced board repres= entation formats model an explicit outline, with poly(curve) type primitive= s, so an explicit design intent of the finished shape can be modelled. This= is effectively a "polygon" shape in PCB, especially once the pat= ches adding support for curved edges are merged. To avoid ambiguity in inte= rpretation, this "polygon" needs (I believe) to be a first-class = property of the stack-up model. (Something I'm working on designing and= adding currently).

Peter
--089e011603f63fe5f505290ceae1--