X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Message-ID: <54E0733E.4030206@xs4all.nl>
Date: Sun, 15 Feb 2015 11:21:50 +0100
From: Bert Timmerman <bert DOT timmerman AT xs4all DOT nl>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.19) Gecko/20110429 Fedora/2.0.14-1.fc13 SeaMonkey/2.0.14
MIME-Version: 1.0
To: geda-user AT delorie DOT com
Subject: Re: 3D data and support [WAS: Re: [geda-user] FOSDEM]
References: <1420499386 DOT 3521 DOT 3 DOT camel AT cam DOT ac DOT uk>	 <20150203112631 DOT 3507a0c1 AT Parasomnia DOT thuis DOT lan>	 <20150204054256 DOT Horde DOT Pm1JV8RJbICk9SHvIGwZ7A3 AT webmail DOT in-berlin DOT de>	 <CAOP4iL2stWVCy3WK0=SNu2zAbs8t6B0uyAgFuOnzG8v_MrYNfw AT mail DOT gmail DOT com>	 <CAGde_xN5gs5r_on=HP2RN7cy6E=2EL9eK3cp+sd9BfBaWNLVew AT mail DOT gmail DOT com>	 <20150204193720 DOT Horde DOT 42xUN-NzhCJRWZne-M5eCQ1 AT webmail DOT in-berlin DOT de>	 <90236728-E79D-47C7-BFB1-34140DB85ACB AT sbcglobal DOT net>	 <CAOFvGD4M48Ap=UQzL_T3yzas2rJrNFfxXRUOkOe8gA8J3bQCHg AT mail DOT gmail DOT com>	 <1423323918 DOT 1592 DOT 10 DOT camel AT cam DOT ac DOT uk>	 <CAOFvGD6rwqf79obnSRQ4gyM0h8_5PQ-C0G2guRp8YU80oOAkig AT mail DOT gmail DOT com>	 <1423329222 DOT 1592 DOT 12 DOT camel AT cam DOT ac DOT uk>	 <CAOFvGD6mP0GH0-KNsYffThqM8aiyxnHJfpMg7sLj1sXdhGou9g AT mail DOT gmail DOT com>	 <54D67DAE DOT 5000805 AT neurotica DOT com> <20150214111652 DOT 1e9765c8 AT jive>	 <mbobai$74i$1 AT ger DOT gmane DOT org> <1423956972 DOT 16089 DOT 2 DOT camel AT cam DOT ac DOT uk>	 <CAM2RGhT1tjdghX5EU0WL94CbjTHN_D3r9jrUVnSsn7pYW4bNrw AT mail DOT gmail DOT com> <1423966586 DOT 16089 DOT 8 DOT camel AT cam DOT ac DOT uk>
In-Reply-To: <1423966586.16089.8.camel@cam.ac.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: geda-user AT delorie DOT com

Peter Clifton wrote:
> On Sat, 2015-02-14 at 18:53 -0500, Evan Foss wrote:
>    
>> I would want full 3D data since you can always reject data but adding
>> it in later is hard. just look at how long this thread has gotten.
>>
>> A simple hight does not help me when I have parts like this
>> http://www.mouser.com/ProductDetail/Omron/2SMPP-02/?qs=3P%252bcriiv584EfFf%252bLos22A%3D%3D&kpid=492727993&gclid=CjwKEAiAgfymBRCEhpTR8NXpx1USJAAV0dQylSBgkXS3S-jSknPvwRo1CnbsiYWkc30-ns0GFfAO2xoC7Nbw_wcB
>>
>> (pressure sensor with vertical port for a hose)
>>      
> I'm working on 3D support, albeit slowly, and there are a lot of
> use-cases. I'm enumerating some below to further my clever "your wrong"
> argument to KMK regarding 3D support inside PCB.
>
>
>
> Break-down of 3D features one might care about:
>
>
> Modelling...
>
> I don't actually envisage building any 3D modelling tools into PCB
> (mechanical CAD, and component vendor models are better sources there),
> but I believe we do need to capture enough information to correctly
> model the board construction and stack-up.
>
> 2.5D regions (for keep-outs) might be feasible to model within PCB
> though, if use-cases below demand them.
>
>
>
> Board only 3D export....
>
> I already use STEP export of my general shape (incl. fixing holes) of my
> boards to feed into caseworks and overall product design.
>
>
>
> Shape + Z 2.5D keep-outs...
>
> Well - modelling any keep-outs would be a good start in PCB, but in the
> absence of full component models (or to augment with further clearance
> for whatever reason), modelling keep-outs with height enables more
> information to be transferred on to mechanical designers when exporting
> board information for caseworks design etc.
>
>
> Adding components...
>
> This can be useful for checking 3D clearances (with component models
> populated). I currently do this in a commercial 3D cad package, using
> the STEP export of my plain board model (complete with vias). I then
> manually construct an assembly with models of components either
> hand-created, or imported from vendor provided STEP models.
>
> This would be lots easier if I could pre-associate the correct 3D models
> with PCB footprints, and directly export an assembly containing the
> board AND the models.
>
> (Actually this is not so hard to achieve, given a little extra data with
> each footprint).
>
>
>
> 3D Components within PCB...
>
> One might like have 3D views with components inside PCB, which means
> having a source of that 3D component model, and ways to import that into
> PCB and align it with the relevant footprint.
>
> This would enable less formalised 3D clearance checks, done using
> eyeballs whilst designing the PCB. (Real numerical 3D clearance checks
> would probably require importing a 3D cad kernel, which could bring
> license issues).
>
> I primarily care about components modelled in mechanical CAD formats
> (not graphics rendering formats like VRML), so this is hard. STEP is the
> interchange format we need to handle, yet it is not feasible to import
> directly (it is too complex).
>
> To do this I think we need to fork an external process to convert to a
> simpler (faceted) model. I say external process due to potential
> licensing issues of OpenCascade (Now LGPL2, but _not_ LGPL2+). This is
> however, the most realistic for library which could handle processing
> the conversion.
>
>
>
> More complex export, including traces in 3D....
>
> Modelling board construction and stack-up to enable a more realistic
> view of the board construction in 3D, and give data to export to other
> CAD / CAE work-flows.
>
> People doing high layer-count boards care about visualising this
> (including at design time), and those doing RF, controlled impedance, or
> high-reliability may require exporting 3D data of the board construction
> and traces to conduct simulations and analysis.
>
> Imagine:
>
> PCB->Full 3D trace geometry export->FEA Field solverThere are also
> reasons o
>                                    ->PCB Warpage analysis / DRC
>                                    ->  ....
>
>
> Parts modelling....
>
> I'm currently investigating AP210, and expect to be running some trial
> conversions of KiCAD library parts and 3D models when I have some time,
> and a few further details from the guys who have been developing this
> standard.
>
> This format should allow us to model all information we could possibly
> desire about a part, in a way compatible with ECAD tools, and
> (crucially) MCAD as well.
>
> Having parts models in AP210 (and suitable code to handle them), I
> should be able to directly export a full 3D board + parts model for
> consumption by downstream tools. It will also be possible to embed
> faceted geometry representations that are simple enough for us to parse
> and render without heavy-weight CAD libraries. (Both faceted and BREP
> models can co-exist in STEP files).
>
>
> Kind regards,
>
> Peter
>
>    
Hi Peter and fellow list members,

These are all good things for "pcb-and-friends" to wish for, and to be 
on a wish list.

Though I'd like to take one step back, and ask myself: "in what things 
should pcb be very good ?" (if not the best).

If we keep within the gEDA-gaf/pcb philosophy we should deliver:
- tools that do *their* job very well,
- specialized tools that are only aware for a (possible) next tool in 
the chain, and do not do all actions themselves,
- or tools that do actions for other specialized tools, thus providing a 
"glue" function (gnetlist, gsch2pcb, <pcb2cad>, <pcb2fea> ... "make" is 
your friend here).

Afterall, the path followed by the engineer could deviate after gschem 
(not choosing for pcb is an option too ;-), and could deviate after pcb 
(not choosing g-code/gerbv, and doing some EMC/thermal analysis in a 
specialised FEA software)

So my wish list for pcb itself has items like:
- implementation of stack-up definitions
- implementation of buried vias/buried components
- implementation of keepout definitions (no parts to be placed within 
keepouts, if you want to override ... alter the keepout!)
- implementation of outlines defined as polylines (awareness of outlines 
in outlines)
- respected landpatterns (no parts to be placed within the real estate 
of another part)
- implementation of a "push/shove" router
- implementation differential pair routing
- implementation of multi trace routing (busses)
- implementation of fanout for BGAs
- stop fighting with the autorouter
- implementation of an impedance calculator/inspector
- fixing the topological router (or transform into a plug-in)
- implementation of pin swapping
- implementation of device swapping
- implementation of back annotation to gschem (probably by means of a 
gnetlist "glue" back end, oops, I'm sorry if I did say "Scheme" ?  ;-)

The above already contains some "hard nuts" to crack, maybe best 
implemented as plug-ins, or transformed into plug-ins.

And then there is the awareness for the previous/next (possible) tool in 
the chain, maybe best to "implement" them as plug-ins or stand-alone 
tools, more "hard nuts" to crack:
- import of outline data (as a plug-in reading DXF, SVG, ...)
- export of trace geometry for FEA solvers (ANSYS, Nastran, ...)
- export for MCAD systems (DXF, OpenDWG, IDF, STEP, ...)
- export for eye-candy (Blender, BRL-CAD, FreeCAD ...)

BTW, I think that most of the current "exporters" should be converted 
into "plug-ins" or stand-alone tools and give "make" a chance to do its 
magic.

Just my 0.02 EUR on the matter.

Kind regards,

Bert Timmerman.