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
Content-Type: text/plain; charset=UTF-8
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

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/