X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type;
	bh=EUh92ixjU1Aswu+25CTD+tqWycuOn1rEY3IhwtfGS/c=;
	b=Rol7a4WCgc8Au1JdNTnlzZ4QVvVmVxHWtJlTZlTgtbUqapUgVv7Dr/YwibURhoA20B
	nwOqdKdfG29ECNnZH52w/gl+ltt9w69MQpWypIZ62prBoVPaDB3ESJQ3ka9erIoi/LF+
	IItGE9ENxRNGlS2vMyhO6sn3NpB6U7WtRLg026Q4QLTEbZa3sMJjWCYhRNwVdm5i3dNG
	pegGGSE288iXPCfGpIVGYGB3ulmTlxQQleeTn4cp6H+k3sFUhLrqzixRS/I0rjkBPmRS
	wDahzZlBQu7pT1WgjOzNHaRrtV1Uj9Lq9h6l9xwu+EDDTq8Qhk47IQnxj3WWXs4/MG4/
	29Qg==
MIME-Version:	1.0
X-Received:	by 10.112.167.67 with SMTP id zm3mr38330882lbb.27.1406096339793;
	Tue, 22 Jul 2014 23:18:59 -0700 (PDT)
In-Reply-To:	<53C5DDD4.404@ecosensory.com>
References:	<jql5oeoex9l7r932tnwtp2i5 DOT 1404908642063 AT email DOT android DOT com>
	<53C5DDD4 DOT 404 AT ecosensory DOT com>
Date:	Wed, 23 Jul 2014 02:18:59 -0400
Message-ID:	<CAM2RGhTH+K91JkhakxYgW5UZVWqGZ18zRMwkjvxjJRoCUWCBzA@mail.gmail.com>
Subject:	Re: [geda-user] Re: Layers and footprints
From:	Evan Foss <evanfoss AT gmail DOT com>
To:	geda-user AT delorie DOT com
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

Sorry about bumping an some what aged thread. I understand the desire
to add 3D functionality, the idea of a utility to import outside
formats makes a lot of sense.

John thing that worries me is the alteration of gschem. Other than
adding another label for marking a 3D model along with the footprint
what alteration is really needed from gschem?

On Tue, Jul 15, 2014 at 10:05 PM, John Griessen <john AT ecosensory DOT com> wrote:
> On 07/09/2014 07:50 AM, Peter Clifton wrote:
>>
>> I'd be tempted to make pads layer objects going forward, (and let them
>> reside on any copper layer), but perhaps for now, keeping
>> them "special" and outside the normal layer data structure  may be cleaner
>> due to the  fact they place objects on multiple
>> "layers". (Copper, mask, paste etc...)
>
>
> There's not much limit in computing language or data structures today,
> so it will give the best return on time spent to model
> physical reality well, rather than use "special" layers,
> special cases, etc, that must logically combine to
> match reality.  In other words, have pads be defined per
> physical layer and affect things that are 3D physically near them
> and nothing else.  Making things self consistent like an e field
> is ultimately simpler than a giant text sort kinda giving the right answer.
> And you can use assertions on the local volume of material to keep errors in
> check.  Otherwise,
> you can have "action at a distance" spaghetti code effects.
>
> Of course a physical material and 3D space model means a lot of
> PCB and gschem redesign, but... why waste any life hours of any
> developers on dead ends?
>
> Incremental change is the only way we've seen work in FOSS, so any move
> towards such goals
> that can be incremental is what to "wrack your brain" for...
>
> On 07/09/2014 07:58 AM, Peter Clifton wrote:> I've personally never had a
> board vendor want changes in gerber data to accommodate manufacturing
> processes. This is generally
>> something they can do themselves using their CAM software if they need.
>
> But, that drops the responsibility of repeatable successful fabbings on the
> fabber, when
> one should keep it him/herself, or maybe have a lot of waste and loss.



-- 
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/

- Raw text -