MIME-Version: 1.0
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
Content-Type: text/plain; charset=UTF-8
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
Precedence: bulk

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/