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:	367631 DOT 86294 DOT bm AT omp1081 DOT mail DOT ne1 DOT yahoo DOT com
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402359112; bh=KMVaxq+y+yi7Kagv2S1JqenwnnK03JMrglbmwz7KVbw=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=iT2E4NjZAygAwgdy5YznpsfuR39dTkN245y7mPBnXXX0tZgrGigDOzUDt8ypBCPqb7cLUSw8YwaxqL13G/vb2omsXipR3tJM6nWKlUAytnGJk5BXv9H1c1M15oVeEjTCWZ+7fmV6JcxnA4noBc869L/VLitYPJNXuOyY/MqER28=
X-YMail-OSG:	xPtYRvgVM1n9K2EGRDeJVNHJdxWxMu2vW3s0DU6SGaOGpMs
	T8f7.FzlwLwByx_T2gh32x1t49zzFvXpn4H3bZnSicHk3rYhQLYs1y0HhJZ_
	z_nPQhd96dYAsylD9_PaS67X1Wb8sZ3jOTEPIGDspwjmlBlWjNQhn7HViMmm
	HAwGNFOO5_Ph2D9nKQorPz5WlwWJYN9c5Qtb6Ij2GNXucjHAK.LEZ8CuNJJA
	iCUTZ1i850IWYdkZhx2AKI4tEhFd.p40kDm0nf46yLCghBUoikJ3znJ7RffF
	vz6QmbJIhA4sp06ibEctznrBWKZ.ltXu44NIJXilU_ZvLe.8ex277dQrqLyn
	4tqrgsDX4jDHmJuxc0r7m1FshexCNZ.wXhGII5CI8_yhgNe.w92HJXRZTXS1
	8m7AnbMYUDo_xw7lk3S.PWGtal0Aki4JAyZUPXEnWNm1wrEKCl0TEFZ4Zqej
	z1f8XQnOucxsIxhs5u3LvqpIp4Yd2c3pC0MLsGLIX.g6MArZy6HW5nYe0JuG
	UWha37Xkl.oaTofmNJD5R2t7IcI9HRhaHPjuOoWwgE3a.j1uhUHmyQfUBl5x
	DAA--
X-Rocket-MIMEInfo:	002.001,LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQoKPiBGcm9tOiBQZXRlciBDbGlmdG9uIDxwY2pjMkBjYW0uYWMudWs.Cj4gVG86IGdlZGEtdXNlckBkZWxvcmllLmNvbQo.IENjOiAKPiBTZW50OiBUdWVzZGF5LCBKdW5lIDEwLCAyMDE0IDk6MTIgQU0KPiBTdWJqZWN0OiBbZ2VkYS11c2VyXSBQcmVyZXF1aXNpdGVzIGZvciBhIFNURVAgZXhwb3J0ZXIgLSBjYWxsIGZvciBhc3Npc3RhbmNlLgo.IAo.IEhpIEFsbCwKPiAKPiBTb21lIG1pZ2h0IHJlY2FsbCB0aGF0IEkgd2FzIGxvb2tpbmcgaW50byAzRCBleHABMAEBAQE-
X-Mailer:	YahooMailWebService/0.8.190.668
References:	<1402355532 DOT 14291 DOT 63 DOT camel AT pcjc2lap>
Message-ID:	<1402359112.6669.YahooMailNeo@web120505.mail.ne1.yahoo.com>
Date:	Mon, 9 Jun 2014 17:11:52 -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:	<1402355532.14291.63.camel@pcjc2lap>
MIME-Version:	1.0
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id s5A0BvXK018517
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: Tuesday, June 10, 2014 9:12 AM
> Subject: [geda-user] Prerequisites for a STEP exporter - call for assistance.
> 
> Hi All,
> 
> Some might recall that I was looking into 3D export for PCB. (Of the
> board shape).
> 

If all you wanted was the board shape, IDFv3 is sufficient and supported
by most MCAD software. Recently an IDF library has been added to KiCad to
enable IDF read/write; since the library stands on its own, you can simply
fork it; it's GPLv2 but retains the clause 'or (at your option) any later version'

> My thanks go out to the people who funded purchase of the ISO STEP
> standard collection - this work would not have been possible without the
> reference material. Whilst progress on the exporter has been very slow
> going, it is a lot closer to being useful now.
> 


STEP assemblies can also be created with the OpenCascade library.

> 
> I've re-written my export code over the last week or so, and can now
> emit useful AP214 .STEP files containing a representation of the PCB
> board, complete with via holes. (And colour!) As of tonight, there is
> support for emitting multiple solid bodies, when the board outline has
> more than one piece.
> 


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.
Generally the MCAD users don't want vias as they complicate the model an
mechanical people really couldn't care less about them.

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.

> 
> There are, however, some things we ought to get straight in PCB before
> the exporter can sensibly be finished off and merged.
> 
> 
> 1. We need a semantically defined, machine parse-able board outline
> definition adding to our file format.
> 
> I propose that we allow users to draw this contour in a similar way to a
> polygon, and use this as a machine-readable "outline" embedded in the
> PCB file.
> 


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

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

Keep it a simple solid outline as IDF does. If a model isn't good enough
for MCAD then it is the MCAD operator's responsibility to swap the model
for an accurate one. The way this typically works when exchanging data via
IDF is that the mechanical people identify, based on the existing component
extrusions, the parts which will require an accurate model to ensure that
things fit together.

> 
> In order to do this properly we need to develop an extended poly-curve
> syntax which allows line AND arc segments to form a connected, closed
> loop. With this, the user can be completely explicit about the design
> intent. I DO NOT want us to extract this from the magic "outline" 
> layer,
> using some magic heuristics to interpret what various objects the user
> drew there.
> 


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.

> 
> We should use this extended poly-curve definition to replace the
> poly-line outline definition used of PCB's (file format) polygons.
> 
> The underlying polygon algebra code will internally use line-segment
> approximations to implement the arc segments, but we need to be able to
> express the design intent to use arcs as part of the board outline. (The
> STEP exporter will certainly be able to use them).
> 
> 
> With a common poly-curve format, we can, of course use the (extended)
> polygon editing code to define an explicit board outline. Exporters and
> renders which care (gerber, STEP, PCB+GL), can use this definition to
> emit definitive outline data.
> 
> 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 am, however, COMPLETELY DEAD AGAINST using an automatic extraction
> routine to add (yet more) magic and rules to the existing concept of an
> "outline" layer.
> 
> Until we have "PROPER" outline information in the PCB file, there is 
> no
> point in merging my STEP exporter, or the PCB+GL features which use the
> board outlines.  I really don't want to lock in rules to guestimate the
> user's intent by looking at a drawing layer, when an exact outline could
> so readily be defined explicitly.
> 


Guessing the user's intent is impossible. As I said, forget about legacy
outlines.

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

> 
> 3. If we start defining "courtyard" and Z-height as part of our
> footprints, then I can start extruding those outlines as well... to
> augment the board model.
> 
> This is a more trivial file format extension once we have a poly-curve
> loop primitive.
> 
> 
> 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.
  
- Cirilo

- Raw text -