X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Yahoo-Newman-Property:	ymail-3
X-Yahoo-Newman-Id:	610556 DOT 16161 DOT bm AT omp1005 DOT mail DOT ne1 DOT yahoo DOT com
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402474486; bh=EQcyDotL3vAqZwJO+irhn+V010iSw1TWGUYKyk8xUQg=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=PKT+gb/h5fOPzvQvVY0N8JIGalVa/zyC0Sko5teGze+6YJlPXU5YHKyhKxiN3mCAWTZrssMjNBCgHdOwiWFzU1Of0DWsOyX4JIortzcVymTo1S74zZiWigR51vFyoTxprIUXe5Yp38dPcCY/k9uVv2SZSeEGSohW5CWTrJKGETg=
X-YMail-OSG:	stKeYwEVM1nDEyiy_TxZVk.9BDUS8LJXIjK0xyag4TSz5G6
	7KJGRg_vkzluPxzqRIzClXAOuLANMsdrG5mCCKrnNMnBFHVh4Ub76zjhDU4K
	tA0ZAKF5WDmbWof2GWCequ9BN1xISTcvpOMDJadi_D.jrsJ_W3bwZHB_hIiC
	DSyjvh6JAdoL1sItSEkppgoOVd20Ji0gje_3n1d8SIDA04mpjcTehhwQsvRI
	uSPv2WdyN7r2g6n9GaewIY2BW23U7X34N7KkE3.EHtw5Ir3e3oqYOZENvMJ1
	L0bBD.xPbXlUFh4nmqiE0qrrB5M92x_NvU9Ni8fkG.qFmrR2AORfTdGhbuF2
	TB0AcnJktA_8B9D3sO4U2qkFwD7rDFe1mcTClvRp4ICKOR_SUaC1O7ABiGCn
	AusbUYvh.tMqUxUrOLqJ4DnPOvbQCTok_EEgu_jDxU7zNGHK8pj6g0qRQmen
	XOCYBAqEMNh4Zs07Vzjq9dRdeoDDUlzBI.EjEO6k5MwHUSBqAsUq5UYKdi1i
	mMEeTK3XPoUjn7LcK3XI45iOMHQxk.SkDvTkOuEQOAVAMTLV0.W.Ow04cYUf
	Gnwg-
X-Rocket-MIMEInfo:	002.001,LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQoKPiBGcm9tOiBQZXRlciBDbGlmdG9uIDxwY2pjMkBjYW0uYWMudWs.Cj4gVG86IGdlZGEtdXNlckBkZWxvcmllLmNvbQo.IENjOiAKPiBTZW50OiBXZWRuZXNkYXksIEp1bmUgMTEsIDIwMTQgMTA6MzYgQU0KPiBTdWJqZWN0OiBSZTogW2dlZGEtdXNlcl0gUHJlcmVxdWlzaXRlcyBmb3IgYSBTVEVQIGV4cG9ydGVyIC0gY2FsbCBmb3IgYXNzaXN0YW5jZS4KPiAKPiBIaSBDaXJpbG8sCj4gCj4gVGhhbmtzIGZvciB0aGUgdGhvdWdodHMuLgo.IAo.IEluIHBhcnQBMAEBAQE-
X-Mailer:	YahooMailWebService/0.8.190.668
References:	<1402355532 DOT 14291 DOT 63 DOT camel AT pcjc2lap> <1402359112 DOT 6669 DOT YahooMailNeo AT web120505 DOT mail DOT ne1 DOT yahoo DOT com> <1402447018 DOT 3185 DOT 67 DOT camel AT pcjc2lap>
Message-ID:	<1402474486.74543.YahooMailNeo@web120505.mail.ne1.yahoo.com>
Date:	Wed, 11 Jun 2014 01:14:46 -0700 (PDT)
From:	Cirilo Bernardo <cirilo_bernardo AT yahoo DOT com>
Subject:	Re: [geda-user] Prerequisites for a STEP exporter - call for assistance.
To:	"geda-user AT delorie DOT com" <geda-user AT delorie DOT com>
In-Reply-To:	<1402447018.3185.67.camel@pcjc2lap>
MIME-Version:	1.0
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id s5B8EqH5007386
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

----- Original Message -----

> From: Peter Clifton <pcjc2 AT cam DOT ac DOT uk>
> To: geda-user AT delorie DOT com
> Cc: 
> Sent: Wednesday, June 11, 2014 10:36 AM
> Subject: Re: [geda-user] Prerequisites for a STEP exporter - call for assistance.
> 
> 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.
> 


The 360 degree scenario was unclear in IDFv1,2 but many people interpreted
it as a stand-alone circle. In IDFv3 it is explicitly a circle. IDFv3 is
the most common one in use today although IDFv2 files still float about.
IDFv4 was never widely adopted, instead industries moved to PSI-5 which
makes extensive use of STEP AP214 and AP210. I think all free ECAD projects
struggle for developers at this point in time so I don't imagine the option
of ECAD-MCAD collaboration via PSI-5, but we can certainly do IDFv3 and
create STEP assemblies. :)

> 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.
> 


No, IDFv4 was never widely used. Among other things it reveals too much
of the electronic design intent to the MCAD users who either (a) don't
care or (b) shouldn't be shown such specific information. On top of that
it still failed to provide a collaboration framework which would fit in
well with users' collaboration and documentation requirements.

> 
> 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.
> 


IDF was never really thought out very well and in most implementations
it ends up a 1-way street, partly because it lacks the ability to
adequately represent even simple constructs such as slotted holes for
mechanical mounting. For most projects handing off a STEP assembly should
do fine. If you ever need to import a board outline from IDF though,
the (stand-alone) code to read in the IDF file can be taken from KiCad;
I wrote that code so no one can object.

> 
> 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.
> 


That's where good software design comes in. So long as things are
implemented so that they're flexible enough to include such features
in the future, everything will be fine.

> 
> 
>>  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.
> 


I've made similar design decisions with IDF. The user should at least be
able to disable via exports. Some people say it's OK to disable PTH holes
for pins as well, but I disagree. When replacing a simple extruded model
with a more accurate model, the through holes are one of the few reference
points you have for accurately locating that model. Fortunately small SMT
components are adequately described by an extrusion and large components
have some sort of mechanical mounting hole to act as a reference.

> 
>>  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).
> 


IDFv3 deals with that case with 'panel' files - but I have never seen any
software which supports the panel file. :) Even in KiCad I wonder if the
board solid outline should be on one layer and cutouts on another layer.
This could be useful when dealing with complex flex-rigid circuits. In
fact for flex-rigid there should probably be 1 layer for solid PCB
outlines and 1 layer for solid flex membrane.

> 
>>  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.
> 
> 


Ah, of course. STEP should be able to support non-uniform rational
B-splines. I doubt anyone would care to implement those as an option
for describing a board outline in ECAD; editing a curve would be a
nightmare.

> 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 thought about elliptical sections and threw the idea out. Stick to
circular arcs and if someone really needs elliptical sections, they
can do the hard work.

> 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).
> 


I'd leave that level of detail to manufacturer-supplied STEP files.
The reason is that MCAD users really don't care unless it's a component
with dimensions critical to the work, and in that case it takes a few
minutes to create a detailed model with MCAD software. 

> ...
> 
>>  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.)
> 


DXF->PCB is fairly straightforward now thanks to the qCad/LibreCAD
people. KiCad uses the LibreCAD libdxf to import board outlines
and to create IDF outlines. When gEda pcb's scheme for defining
outlines is sorted out, it should be fairly easy to write a DXF->PCB
tool. May as well throw in an IDF->PCB tool too. :)

> ...
> 
>>  > 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.
> 
>

That could be useful then. :) But stick to making it work for your
own needs rather than being distracted by possible general use.

>>  > 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.
> 


Gerber's trying to stay in the game with its latest version. :) It
will be a few years yet before we see how it's received by industry.

> 
>>  > 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.
> 


A sane origin is extremely important, but bottom of board, top of board,
middle of board stack, or corner of a rectangular board are all acceptable.
You might be surprised at the number of models out there in the wild with
a whacky origin though. There have been a few times where I was thinking
"I thought I just placed a component here - where is it" and I'd have to
zoom out until the mechanical assembly was a mere speck before I could
spot the tiny dot that represented the model I was hoping to use.

Let me know if you need any help testing your STEP output; I at least have
SolidWorks. FreeCAD might be usable for that as well.

- Cirilo

- Raw text -