delorie.com/archives/browse.cgi | search |
X-Authentication-Warning: | delorie.com: mail set sender to geda-user-bounces using -f |
X-Recipient: | geda-user AT delorie DOT com |
X-Original-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=ugGz1aZx+f9tisUPos48YayZ1TRGzS9bJxCKndTf86Q=; | |
b=VazI48fnKyH7YXo550//tVX9lWhOaLFEPf5es0xZJ6ZDZ+idmh8un2WocYyzT4YKuB | |
k0SIQV3E6P6bLkcplK+oSP2F8soKZz9gg4EeT26KKAGMLmZ8sNg9gVMdiC/guZIfju7I | |
6AOShrRkX/Tb03j8qvujCEaUO8KT5bULvtqn8tJrxfgShuVI6SlYDnoH9TFvDO7kOHVS | |
Nqp+KjYLUNdkZiFKqRAjTGPQwIvZSRL4Kx+2Egq5VtbME1mnldvlfBuevwyFSzW3wU5r | |
lmQkoXrtSABwmf8B0DTDGAGCx9Z5tTnyqq/WBtk1F1gcn4WXboJQtjXdp7MAMwj7ECax | |
VycQ== | |
MIME-Version: | 1.0 |
X-Received: | by 10.152.6.1 with SMTP id w1mr7228860law.91.1433991426565; Wed, |
10 Jun 2015 19:57:06 -0700 (PDT) | |
In-Reply-To: | <CAM2RGhT-BRk1pg9nM7+RzjyJzQ5K1OO5UN5JtE64QgC0fooAug@mail.gmail.com> |
References: | <CAC4O8c_GDcNGCfxOK0aokCAnhS5u8APhABcm0xxA1ptiTh7tMQ AT mail DOT gmail DOT com> |
<1467655833 DOT 733018 DOT 1433990059994 DOT JavaMail DOT yahoo AT mail DOT yahoo DOT com> | |
<CAM2RGhT-BRk1pg9nM7+RzjyJzQ5K1OO5UN5JtE64QgC0fooAug AT mail DOT gmail DOT com> | |
Date: | Thu, 11 Jun 2015 02:57:06 +0000 |
Message-ID: | <CAM2RGhT6-FQ8Hsd37A7J34yP86bzx8O4VDZ=T7CQx9fYgCsm5Q@mail.gmail.com> |
Subject: | Re: [geda-user] Interchange formats |
From: | "Evan Foss (evanfoss AT gmail DOT com)" <geda-user AT delorie DOT com> |
To: | 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 |
We have public documentation from a number of CAD vendors about how their file formats work. Is there a licensing reason preventing us from writing interfaces to them? On Thu, Jun 11, 2015 at 2:52 AM, Evan Foss <evanfoss AT gmail DOT com> wrote: > Thanks that fills in some question marks I had about STEP. > > On Thu, Jun 11, 2015 at 2:34 AM, Cirilo Bernardo > (cirilo_bernardo AT yahoo DOT com) <geda-user AT delorie DOT com> wrote: >> STEP is a different beast altogether and historically the effort >> was in IGES and driven by US government contracts and an effort >> to unify design and manufacturing files and ultimately reduce >> manufacturing costs by having a standard interchange format for >> Computer Aided Manufacturing. There was such a large global >> interest in this that groups from many countries were involved >> early in the process (in fact a lot of early MCAD algorithms >> were developed in the Scandinavian countries). >> >> That's the historical background, and STEP was created to >> overcome many of the deficiencies in IGES, but the primary >> purpose remains largely the same: to provide CAM users with >> One True Format to work with and CAD users some hope of >> being able to convey shape information to other CAD users. >> Since the early days STEP has evolved to include electronics >> documentation and testing etc. and for a long time it's had >> the dubious distinction of being the world's most complex >> standard. >> >> Having said all that, no MCAD on the planet uses STEP as its >> native format and I don't even know if STEP can provide that >> feature, so it remains little more than an interchange format. >> >> With the big changes in manufacturing in the 1990s IDF >> attempted to modernize with IDFv4 and failed miserably; >> around the same time the Pro-STEP consortium formed to work >> on an IDF replacement based on STEP. Roughly 20 years later >> the results are mixed and although there has been some level >> of adoption by the likes of Boeing and Airbus (among other >> big players). However, Pro-STEP has always been intended for >> MCAD-ECAD collaboration and not ECAD-ECAD exchange. >> >> I think for ECAD you'll be lucky to get people to agree on >> a format for representing information in schematic symbols, >> PCB footprints, and associated mechanical models; I don't >> believe you'll ever convince commercial operations to agree >> to a universal schematic/artwork definition file since that >> kills their lock-in by severely reducing the cost of changing >> software. I suspect it is possible to develop a common >> symbol/etc format though and convince vendors to adopt it, >> but you need to get the big ECAD vendors on side early on >> and expect this to take a few years. While STEP was created >> to serve manufacturing and demanded by governments as well >> as many corporate users, a common ECAD data exchange format >> would really be mostly useful for vendors to provide users >> with reference models for their ECAD work; you've got to >> ask yourself how a vendor like Altium, Mentor, or Cadence >> will benefit because if there isn't money in it for them >> (save on their own cost or give them a product to sell) >> they won't be interested. >> >> - Cirilo >> >> >> >> >> ----- Original Message ----- >>> From: "Britton Kerin (britton DOT kerin AT gmail DOT com)" <geda-user AT delorie DOT com> >>> To: geda-user AT delorie DOT com >>> Cc: >>> Sent: Thursday, June 11, 2015 8:52 AM >>> Subject: Re: [geda-user] Interchange formats >>> >>> On Wed, Jun 10, 2015 at 12:26 PM, Evan Foss (evanfoss AT gmail DOT com) >>> >>> <geda-user AT delorie DOT com> wrote: >>>> For those of us who are not as well versed in our history of this >>>> subject. I would like to know why so many common EDA formats have >>>> failed? >>> >>> I don't see how the folks selling $100k EDA tools with a bunch of locked-in >>> customers would benefit from implementing them, and without them on board such >>> efforts are probably doomed. Big outfits have large design silos that they >>> aren't going to throw out. Who forced the mechanical design tool vendors >>> to support STEP? >>> >>> Britton >>> > > > > -- > Home > http://evanfoss.googlepages.com/ > Work > http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/ -- Home http://evanfoss.googlepages.com/ Work http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |