Mail Archives: geda-user/2015/02/15/05:23:16
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.
- Raw text -