X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Message-ID: <1402447018.3185.67.camel@pcjc2lap> Subject: Re: [geda-user] Prerequisites for a STEP exporter - call for assistance. From: Peter Clifton To: geda-user AT delorie DOT com Date: Wed, 11 Jun 2014 01:36:58 +0100 In-Reply-To: <1402359112.6669.YahooMailNeo@web120505.mail.ne1.yahoo.com> 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> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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 Precedence: bulk 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 Clifton Electronics