Mail Archives: geda-user/2014/06/10/20:37:16
Hi Cirilo,
Thanks for the thoughts..
In particular, think the IDF hint is a valuable one... IDF's poly-curve
definition will fit really easily into our file format to replace/extend
our existing polygon outline definition.
I've been thinking about how best to define arcs in this context for a
long time now, and had wanted a definition which utilised the endpoints
of the arc (Primarily to avoid rounding errors in specifying an arc
centre and sweep angles from creating gaps in the poly-curve)
I had though about using the two endpoints of the arc segment, along
with a radius (or curvature), plus a direction flag, but never thought
of the included angle parametrisation used by IDF. This is VERY elegant,
and lends its self naturally to mixing with straight line segments
within the same data-structure.
Certain versions of IDF did screw up a little though, where they define
a wholly inconsistent meaning of the endpoint coordinates when the
included angle=360 degrees. IDFv4 now has a much cleaner definition,
where the included angle is not allowed to reach 360.
IDFv4 does otherwise go a bit nuts, evolving into much more of a CAD
like format in its own right. I don't think I've encountered many
applications which support IDFv4 yet.
For my own purposes, I'm actually not that interested in targeting IDF
interchange. The MCAD software I use doesn't have this capability (at
least not bidirectionally), and the kind of work-flow I use for most
projects doesn't require it.
Exporting STEP models of boards is useful for handing off to MCAD in a
1-way direction, and is a format most mechanical designers will find
more familiar to deal with than IDF.
In the future, some users (possibly including myself) may find trace
geometry export useful (as input to a 3D FEA simulator for RF / EM
fields / thermal dissipation etc..)
Doing so right now is not my main priority, but if I find time, I might
try it for fun. The challenge is slightly more interesting than just
extruding a planar outline contour. Solving for E-fields in HV PSU
designs would also be interesting.
> Color is nice - if the MCAD cares to support it. Still, it's good to have
> it there for the day when all MCADs actually import the part in color.
I think most do (for AP214 files anyway). The later editions of AP203
now support colour, but perhaps some packages are slow to adapt.
> Generally the MCAD users don't want vias as they complicate the model an
> mechanical people really couldn't care less about them.
As you mention, there is probably no need to export vias (perhaps other
than for a more realistic rendering). The code doesn't differentiate
vias from component pin holes, which we probably DO want to export.
Vias on/off could become an option of course. One of the use-cases I'm
aiming to support is a photo-realistic rendering workflow, so vias would
probably be wanted in this case.
> Do you mean your board outline can contain multiple separate parts? In that
> case, the IDFv3 which I mentioned above won't work; it presumes a single
> part with multiple cutouts.
PCB has always supported arbitrary outlines, and I know people use this
for panellisation (homogeneous, heterogeneous), multi-board designs
etc.. so we would ideally support that.
Perhaps an IDF export would just have to offer separate files for each
body (board).
> The scheme used in IDF may be useful here. Outlines are defined as connected
> lines and arcs. This is a much better scheme for the MCAD people since arcs
> will be correctly represented. It also makes life easier when importing
> outlines defined by DXF. Otherwise you have to create numerous segments
> to represent an arc. I can't remember if STEP can represent an arc or if it
> requires approximation by segments.
If you can imagine it, STEP supports it. (Almost). There are a lot of
surface types in the geometry part (ISO10303-42), which can be
represented exactly, more than we could expect to need.
STEP is a HUGE standard (family of standards), covering more design
disciplines than care to count. I expect we could store the entire
design information of a PCB, without loss, with AP210, including support
for MANY technologies we don't have in PCB's current file format.
For now, planar, and cylindrical face geometry (and trimmings thereof)
in a geometrical export should suffice our needs. I'm not intending that
we should go as far as supporting elliptical arcs for our new
poly-curves, although the surface types do exist in STEP if we need
them.
I personally don't think non-circular arcs are useful enough to warrant
the extra implementation complexity in a first cut. (IDF doesn't support
them, so we'd have to approximate with piecewise linear there anyway).
> If you can have multiple board outlines then any cutouts will have to be
> represented by another layer, otherwise you can't tell a board outline
> from a cutout.
The two can usually be denoted by the direction of the contour (CCW or
CW), but even without that - it is possible to work it out based on the
nesting of the contours. I have written code to do so before.
With an explicitly defined contour, we can store the holes poly-curve
loops with an association to the body / outline poly-curve loop they cut
inside.
> > For my testing, I have been extracting an outline polygon from the
> > objects on the "outline" layer. Unfortunately, this is not
> > particularly
> > robust, and with the current code, can lead to incorrect dimensioning.
> > (I trace the polygon produced by gluing "fat" versions of the
> > "outline"
> > layer objects in order to allow skipping over small gaps in their
> > centrelines).
>
> Turf that idea right away or you'll be wasting time. You need a guarantee
> that a component outline is a single closed loop. Once again you can use
> the IDF implementation for this, and even read IDF outlines to create
> 3D extrusions in STEP. If you don't want the information resident in an
> external file then you can introduce it as a 'component outline' layer or
> something like that.
I'd store as a (array of) poly-curves for each board outline, each
associated with an array of 0-n poly-curves for cutouts.
We might (in future) also consider how voids and partial thickness
cutouts could be modelled and stored, but this gets closer and closer to
the realm of defining an actual 3D format within our PCB file, more
along the lines of what IDFv4 seems capable of).
...
> You're on the right track there. :) The only weak point is the occasional
> board which has some strange cure defining some edges - the only portable
> scheme for representing such curves is through a series of short line
> segments.
Yes - have imported geometry into PCB for designing flexis this way
(even if the underlying data was probably based on arcs), PWL is enough
if the pieces are fine enough (and you don't need to edit the geometry
inside PCB).
It looses does some of its design intent, by the time you've had
Solidworks -> DXF -> PS -> PCB!
(It was probably the PS->PCB step which decimated the arcs into line
segments, but this was a while ago, and I can't recall exactly.)
...
> > We could possibly write an action routine to extract an outline from
> > lines and arcs on an existing, legacy "outline" layer. This could
> > perhaps be based on an extension of the outline extraction code I've
> > been using to test PCB+GL and the STEP exporter, although a slightly
> > different approach to constructing the outline polygon would be needed
> > to have it properly follow the centreline of the various lines and arcs.
>
> Forget about the legacy outline layer or you will waste vast amounts of
> time. Keep your mind on the future.
I'd probably use it to bring over my own legacy board outlines, so I've
no problem providing a function.. so long as its behaviour doesn't
become part of our file-format stability contract with the user.
I am dead against being stuck forever with one particular inbuilt
implementation of such a conversion, always required to generate the
exact same outline when run against a given board.
...
> Guessing the user's intent is impossible. As I said, forget about legacy
> outlines.
At least if it is a separate action, the user can choose to accept or
reject the resulting outline. For all my cautions, the function I'm
using for testing does appear to get a decent result on most boards I've
tested it against, even if there is a small offset.
> > 2. We need to define and store stack-up meta-data, at the very least -
> > board thickness. (In a defined, and machine parse-able way).
> >
> > Ideally, we could store full build-up information, as this would be
> > useful for the 3D view, and for any (FUTURE) more detailed 3D model
> > output, that could conceivably include tracking and layer build-up.
>
> Don't get too carried away with details of the board's mechanical
> construction unless you have parallel work on things like thermal
> analysis which require such detail. For packaging purposes the
> mechanical people only want to know where the mounting holes are
> and where/how to locate models of components which can interfere
> with putting the thing into a box.
I was thinking towards future applications where we might need it, but
for now, a "thickness" parameter should suffice. I might, however, take
a look at STEP AP210 (and perhaps some of the more semantic file formats
intended to replace Gerber) to see what definitions they use for
stack-up.
> > 4. We need a decision on coordinates. Currently, my export uses a
> > right-handed coordinate system with its origin at the bottom left of the
> > board, with Z+ being towards the top of the board, coming out of the
> > screen.
> >
> > This is in common with the gerber exported coordinates (in 2D at least),
> > and TBH - is a more sane coordinate system than PCB currently uses. For
> > now though, we will have to convert on the fly.
> >
> > We do, however, need to define the Z-planes. At the moment, perhaps not
> > quite right, I have the top of the board at Z=0, and the bottom at
> > Z=-1.6mm. More sensible alternatives would be to centre the board
> > stack-up about Z=0, place or the bottom of the board at Z=0.
> >
>
> MCAD software doesn't care at all. Do what is most convenient given the
> existing codebase. All MCAD software cares about is that your STEP model
> uses a right-hand coordinate system. What you call X, Y, Z doesn't matter
> at all. As long as the model doesn't have an enormous offset from the
> origin (for example a 2x2cm board located 1m from the origin) your model
> will be fine.
IDF seems to extrude the board upwards from Z=0, so that is good enough
for me. Granted, you can mate whatever to whatever in almost any MCAD
environment, but it never hurts to have a sane choice of origin.
Best wishes,
--
Peter Clifton <peter DOT clifton AT clifton-electronics DOT co DOT uk>
Clifton Electronics
- Raw text -