Mail Archives: geda-user/2014/06/10/06:09:22
| X-Authentication-Warning: | delorie.com: mail set sender to geda-user-bounces using -f
|
| X-Recipient: | geda-user AT delorie DOT com
|
| DKIM-Signature: | v=1; a=rsa-sha256; c=relaxed/relaxed;
|
| d=gmail.com; s=20120113;
|
| h=mime-version:in-reply-to:references:date:message-id:subject:from:to
|
| :content-type;
|
| bh=6t+rgd08vD+r0Bhtk/ou0/Ph8KJXzobjNOB60t9sWM8=;
|
| b=k0Afq7aBiI/72QqL4tsKMmJbOOEagUiODXUuznlpDlhaNUpWR1jdnTkuos/nfdFYBo
|
| 7DD6JTyPgOH17QutT05xqq/E01Hn0xJeha19XZZYoxp+i0xIOD8Xc9zfYA5oTiuEAX9M
|
| QWZMgNH9DjsLDCIOhWGHzxD5kUTrhaQnAiHeDKgj8Q90zMX48b1vs/7AliWtgzTP9w7/
|
| 4ILT1ow6nfMtEDKOYQE+UDU8ZiTnzDypetEyGLUVE4onxHH1fsIZgqkEHuD+cbB7d+++
|
| ozf2Wfpjn8SUW1T/XJPmYTac8UnUuKpZmLBJVbimZpuIFAJlM1hO52JmOtWXhTjvO+30
|
| IPjg==
|
| MIME-Version: | 1.0
|
| X-Received: | by 10.194.91.228 with SMTP id ch4mr38637178wjb.59.1402394942140;
|
| Tue, 10 Jun 2014 03:09:02 -0700 (PDT)
|
| In-Reply-To: | <1402355532.14291.63.camel@pcjc2lap>
|
| References: | <1402355532 DOT 14291 DOT 63 DOT camel AT pcjc2lap>
|
| Date: | Tue, 10 Jun 2014 12:09:02 +0200
|
| Message-ID: | <CACwWb3A0e-0+Fgo7_GwKv0+2+bDD2koVY1vnQ6DAZLq31uBmBA@mail.gmail.com>
|
| Subject: | Re: [geda-user] Prerequisites for a STEP exporter - call for assistance.
|
| From: | Levente <leventelist AT gmail DOT com>
|
| To: | gEDA User Mailing List <geda-user AT delorie DOT com>
|
| 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
|
--047d7bd91d9e5c7d4e04fb7884b5
Content-Type: text/plain; charset=UTF-8
Peter,
Many thanks for the work done so far.
Yes, I think implementing a new file format would be nice for PCB. And it
would be nice if one could define a footprint at least with a height
parameter.
I think the current file format is the barrier for many nice features that
is on the doorstep.
Unfortunatelly, I am 100% loaded with my home automation project, and I
have 2000m2 of grass to cut.
Levente
73s de HA5OGL
On Tue, Jun 10, 2014 at 1:12 AM, Peter Clifton <pcjc2 AT cam DOT ac DOT uk> wrote:
> Hi All,
>
> Some might recall that I was looking into 3D export for PCB. (Of the
> board shape).
>
> 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.
>
>
> 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.
>
>
> 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.
>
> 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).
>
>
> 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.
>
>
> 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.
>
> 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.
>
>
>
> 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.
>
>
> 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.
>
>
>
> I, unfortunately, don't have the time or resources to address points 1,
> 2 (and 3) at the moment, so I'm calling for some assistance.
>
>
> Does anyone want to look at these problems, work on the file-format
> extensions, and editing tools to allow such definitions???
>
>
> In my opinion, the 3D stuff is easy (once you've got your head around
> some of the STEP standard). It is also not too not critical in terms of
> risk leaving a legacy to maintain compatibility with, should incorrect
> design choices be made). The hard problem is getting good data to work
> with.
>
> Getting the data-model and file format right is the difficult task.. we
> don't want to be stuck maintaining backwards compatibility with bad
> design decisions here.
>
> That is the primary reason why I don't want to introduce code to extract
> an outline curve from the "outline" layer, and why merging the 3D stuff
> is not going to be a quick job.
>
>
> Does anyone feel like a challenge?
>
>
>
> Best regards,
>
> --
> Peter Clifton <peter DOT clifton AT clifton-electronics DOT co DOT uk>
>
> Clifton Electronics
>
>
--047d7bd91d9e5c7d4e04fb7884b5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div>Peter,<br><br><br></div>Many thanks fo=
r the work done so far.<br><br></div>Yes, I think implementing a new file f=
ormat would be nice for PCB. And it would be nice if one could define a foo=
tprint at least with a height parameter.<br>
<br></div>I think the current file format is the barrier for many nice feat=
ures that is on the doorstep.<br></div><div><div><br></div>Unfortunatelly, =
I am 100% loaded with my home automation project, and I have 2000m2 of gras=
s to cut.<br>
<br><br></div>Levente<br><div><br></div><div>73s de HA5OGL<br></div></div><=
div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue, Jun 10=
, 2014 at 1:12 AM, Peter Clifton <span dir=3D"ltr"><<a href=3D"mailto:pc=
jc2 AT cam DOT ac DOT uk" target=3D"_blank">pcjc2 AT cam DOT ac DOT uk</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hi All,<br>
<br>
Some might recall that I was looking into 3D export for PCB. (Of the<br>
board shape).<br>
<br>
My thanks go out to the people who funded purchase of the ISO STEP<br>
standard collection - this work would not have been possible without the<br=
>
reference material. Whilst progress on the exporter has been very slow<br>
going, it is a lot closer to being useful now.<br>
<br>
<br>
I've re-written my export code over the last week or so, and can now<br=
>
emit useful AP214 .STEP files containing a representation of the PCB<br>
board, complete with via holes. (And colour!) As of tonight, there is<br>
support for emitting multiple solid bodies, when the board outline has<br>
more than one piece.<br>
<br>
<br>
There are, however, some things we ought to get straight in PCB before<br>
the exporter can sensibly be finished off and merged.<br>
<br>
<br>
1. We need a semantically defined, machine parse-able board outline<br>
definition adding to our file format.<br>
<br>
I propose that we allow users to draw this contour in a similar way to a<br=
>
polygon, and use this as a machine-readable "outline" embedded in=
the<br>
PCB file.<br>
<br>
For my testing, I have been extracting an outline polygon from the<br>
objects on the "outline" layer. Unfortunately, this is not partic=
ularly<br>
robust, and with the current code, can lead to incorrect dimensioning.<br>
(I trace the polygon produced by gluing "fat" versions of the &qu=
ot;outline"<br>
layer objects in order to allow skipping over small gaps in their<br>
centrelines).<br>
<br>
<br>
In order to do this properly we need to develop an extended poly-curve<br>
syntax which allows line AND arc segments to form a connected, closed<br>
loop. With this, the user can be completely explicit about the design<br>
intent. I DO NOT want us to extract this from the magic "outline"=
layer,<br>
using some magic heuristics to interpret what various objects the user<br>
drew there.<br>
<br>
<br>
We should use this extended poly-curve definition to replace the<br>
poly-line outline definition used of PCB's (file format) polygons.<br>
<br>
The underlying polygon algebra code will internally use line-segment<br>
approximations to implement the arc segments, but we need to be able to<br>
express the design intent to use arcs as part of the board outline. (The<br=
>
STEP exporter will certainly be able to use them).<br>
<br>
<br>
With a common poly-curve format, we can, of course use the (extended)<br>
polygon editing code to define an explicit board outline. Exporters and<br>
renders which care (gerber, STEP, PCB+GL), can use this definition to<br>
emit definitive outline data.<br>
<br>
We could possibly write an action routine to extract an outline from<br>
lines and arcs on an existing, legacy "outline" layer. This could=
<br>
perhaps be based on an extension of the outline extraction code I've<br=
>
been using to test PCB+GL and the STEP exporter, although a slightly<br>
different approach to constructing the outline polygon would be needed<br>
to have it properly follow the centreline of the various lines and arcs.<br=
>
<br>
I am, however, COMPLETELY DEAD AGAINST using an automatic extraction<br>
routine to add (yet more) magic and rules to the existing concept of an<br>
"outline" layer.<br>
<br>
Until we have "PROPER" outline information in the PCB file, there=
is no<br>
point in merging my STEP exporter, or the PCB+GL features which use the<br>
board outlines. =C2=A0I really don't want to lock in rules to guestimat=
e the<br>
user's intent by looking at a drawing layer, when an exact outline coul=
d<br>
so readily be defined explicitly.<br>
<br>
<br>
<br>
2. We need to define and store stack-up meta-data, at the very least -<br>
board thickness. (In a defined, and machine parse-able way).<br>
<br>
Ideally, we could store full build-up information, as this would be<br>
useful for the 3D view, and for any (FUTURE) more detailed 3D model<br>
output, that could conceivably include tracking and layer build-up.<br>
<br>
<br>
3. If we start defining "courtyard" and Z-height as part of our<b=
r>
footprints, then I can start extruding those outlines as well... to<br>
augment the board model.<br>
<br>
This is a more trivial file format extension once we have a poly-curve<br>
loop primitive.<br>
<br>
<br>
4. We need a decision on coordinates. Currently, my export uses a<br>
right-handed coordinate system with its origin at the bottom left of the<br=
>
board, with Z+ being towards the top of the board, coming out of the<br>
screen.<br>
<br>
This is in common with the gerber exported coordinates (in 2D at least),<br=
>
and TBH - is a more sane coordinate system than PCB currently uses. For<br>
now though, we will have to convert on the fly.<br>
<br>
We do, however, need to define the Z-planes. At the moment, perhaps not<br>
quite right, I have the top of the board at Z=3D0, and the bottom at<br>
Z=3D-1.6mm. More sensible alternatives would be to centre the board<br>
stack-up about Z=3D0, place or the bottom of the board at Z=3D0.<br>
<br>
<br>
<br>
I, unfortunately, don't have the time or resources to address points 1,=
<br>
2 (and 3) at the moment, so I'm calling for some assistance.<br>
<br>
<br>
Does anyone want to look at these problems, work on the file-format<br>
extensions, and editing tools to allow such definitions???<br>
<br>
<br>
In my opinion, the 3D stuff is easy (once you've got your head around<b=
r>
some of the STEP standard). It is also not too not critical in terms of<br>
risk leaving a legacy to maintain compatibility with, should incorrect<br>
design choices be made). The hard problem is getting good data to work<br>
with.<br>
<br>
Getting the data-model and file format right is the difficult task.. we<br>
don't want to be stuck maintaining backwards compatibility with bad<br>
design decisions here.<br>
<br>
That is the primary reason why I don't want to introduce code to extrac=
t<br>
an outline curve from the "outline" layer, and why merging the 3D=
stuff<br>
is not going to be a quick job.<br>
<br>
<br>
Does anyone feel like a challenge?<br>
<br>
<br>
<br>
Best regards,<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Peter Clifton <<a href=3D"mailto:peter DOT clifton AT clifton-electronics DOT co DOT uk=
">peter DOT clifton AT clifton-electronics DOT co DOT uk</a>><br>
<br>
Clifton Electronics<br>
<br>
</font></span></blockquote></div><br></div>
--047d7bd91d9e5c7d4e04fb7884b5--
- Raw text -