Connect with:

The Complete History of Failed ECAD-MCAD Exchange File Formats

Sam Sattel


Do you ever feel like today’s engineering is stuck in the past?

Like we’re all living in an age where engineers still work on assembly lines, but instead of a real factory, we’re making the same motions at our desks?

This, my friends, is the bane of every engineer’s existence. You spend hours working on your design, hours perfecting each trace and place of a component. And then what do you do? You select the File » Export button, wrap that multi-layered board of complexity into a tiny little black box, and probably email it to your mechanical designer. And then maybe you retrieve a black box from your MCAD guy, and so the process continues. It’s like we’re all playing musical chairs, but with design data instead of people. Are we just forever stuck with this process? Maybe we need an even better file format to save us? Let’s see what history can teach us.

From the Beginning – IGES

The Initial Graphics Exchange Specification (IGES) is a file format published in 1980 by the U.S. National Bureau of Standards. At the time, digital CAD software was just coming of age, and the world needed a way to exchange data across a variety of engineering disciplines. IGES was the answer.


Over 30 years old and still relied on by engineers today, IGES.

This file format allowed the complexity of a design to get wrapped up in a container (black box) and stored in one of two file formats, either as a fixed-length ASCII file which could store information in 80-character records or a compressed ASCII format.

For its time, IGES solved a problem that had no solution. How were engineers across multiple disciplines going to share their digital data when every CAD system was locked behind a proprietary file format? Use IGES. But today, the file format isn’t in the best of shape that it once was, and suffers from some serious problems as it continues its slowly descend into the grave, including:

  • It’s really old. The last official update for IGES was in 1996. That makes this file format now 20 years old. And yet even today a lot of manufacturers are receiving this file format from engineers designing modern products.
  • It’s limited. Unlike other model-based file formats, IGES can’t provide any intelligent connection between 2D drawings and 3D models. This makes it a pain when you need to hand off your design files, leaving the receiver with no idea about which footprint connects with which 3D model.
  • It’s broken. IGES files only provide models for surfaces without any rich property information like weight, volume, surface area, centroids, etc.; let alone any meta or parametric information. Plus, it’s common to get IGES files where the 3D surface models need to be repaired, or even completely remodeled.

A Step in the Right Direction – STEP

IGES wasn’t getting the job done. And so a new standard was born with the goal to create a file that covers all aspects of a product’s creation from conception to completion. This file type would include things like geometries, tolerances, materials, and a whole lot more for a variety of engineering specialties. To make this happen, ISO 10303 was created, know as STEP (Standard for the Exchange of Product Model Data).


Need to work with 3D models straight from their source? Use STEP. (Image source)

First developed in 1984, STEP allows data to be exchanged between a variety of CAD systems and provides a rich source of product data from a number of engineering disciplines. For example, you as an electronics designer to wrap up your PCB layout in a STEP file, send it off to your MCAD engineer and allow them to do some useful things like:

  • Check for interference between the PCB and mechanical enclosure.
  • Run a detailed thermal analysis to identify any heat issues with components and copper.
  • Created detailed models of your finished board layout and all components.

STEP sounds amazing, doesn’t it? But the problem lies in its size. Unlike other exchange file formats which rely on the process of cutting down data, STEP instead includes it all! This usually makes for a massive file size that can be a pain to quickly exchange back and forth between electrical and mechanical design teams. Each time the file is exchanged the models are created again and again, as everything in the STEP file is self-contained and not reference to a centralized library. Because of its large size and difficult processes, you’ll commonly see STEP files being used for design review and final validations, instead of serving as the bread and butter of daily engineering collaboration.

Making Friends with AutoCAD – DXF

The 1980s were a heck of a time for the introduction of file formats. In the same span of time as STEP and IGES we also saw the Drawing Exchange Format (DXF) arrive in December of 1982 as part of AutoCAD 1.0. But why the need for yet another file format? Different companies and industries rely on a variety of CAD programs, each with their own file formats. But you still needed a way to share design data between AutoCAD and other CAD systems without relying on AutoCAD’s native DWG file format.


AutoCAD 1.0 in action, straight from 1982! (Image source)

Compared with STEP files, the size of DXF files are small considering the kind of data pack in. Back in the day, you could bring together a complete circuit board or landscape design with dozens of layers into a compressed file that was no bigger than 10MB. These days though, DXF is having trouble keeping up with the pace of change.

As AutoCAD becomes more complex and powerful, the DXF file type is struggling to support the new object types being added. A large part of this has to do with complete documentation for new object types as they’re added, which in turn affects how easily another software developer can support those objects in another CAD program. And if you load a DXF file into your CAD program of choice and some objects aren’t supported, then you’ll wind up with data that gets lost in translation.

Built for Collaboration – IDF

If there’s one file type out there that was born for ECAD-MCAD collaboration, it’s the Intermediate Data Format (IDF). This file type was developed in the early 1990s with the idea to create a text-based file that would allow data to be easily exchanged between electrical and mechanical CAD programs.

With IDF, you can quickly send over your design data to a mechanical designer, who can then extract your footprint data to make some simple 3D models. But that simplicity is also IDF’s downfall. All you’ll get is basic block models for all of your components without any of the rich details that show what those parts will look in reality.


Just needing basic shapes for your components? IDF is the way to go. (Image source)

There are currently three versions available for the IDF format, these include:

  • IDF 2.0. This version is a simple text-based format that doesn’t include any support for keep-outs, keep ins, and outline object types.
  • IDF 3.0. This version is just like IDF 2.0 and offers a simple text-based format to exchange data with the addition of keep-outs, keep-ins, and outline objects.
  • IDF 4.0. This version was released in 1998 and did away with many of the limitations of IDF 3.0 by offering an XML file structure and support for new entity types. Despite all of the new functionality, the change was just too drastic for manufacturers and support has never caught on for IDF 4.0.

These days, IDF 2.0 and 3.0 are the most popular versions of the IDF file format. But whatever version you use, you’ll encounter some similar limitations. The first is that each IDF file includes two files that you’ll need to manage. The first file contains all of the information necessary to model the board, including where holes and cutouts go, and the positioning of components. You then need a second file that describes the actual shape of the components. Put all of this together, and you now have two individual files to manage at any given time, and that just increases the chance for versions to get mixed up.

There’s also no unified method of naming file suffixes between CAD programs for IDF 2.0 and 3.0. In some programs, you’ll find .emn for the board file and .emp for the library file. In others you might see a .brd/.rpo combo, or .brd/.lib. What a headache that is trying to keep track of all those variations!

I Thought This Was About Failed File Formats?

Aha, right you are! And this is where we need to have a talk. Do you notice any kind of pattern about the file formats above? Most of them were made in the 80s. Let that sink in. We still depend on collaboration technologies that are over 30 years old. Not only that, we’re relying on collaboration methods that are over three decades old to design today’s rocketships, pacemakers, satellites, life-saving devices the list can go on.

The real question that you need to ask is this process of importing and exporting design data back and forth doing us any good? Because when you really boil it down, what we’ve created here is an assembly line method of working with our fellow engineers. We’re not connected together, working on complete products. We’re just working on our own little parts, and then passing our design down the line, potentially never to see it again.  Saying the whole time, “That is someone else’s problem.”


It’s time to think outside of the box to solve our problems. (Image source)

This right here, this method of collaborating and communicating by relying on the exchange of files and emails is the kind of engineering made from the Industrial Revolution. But now it’s time for an Engineering Revolution! So let me leave you with a few questions to think about:

  • What does the future of engineering look like if you don’t need to rely on the exchange of file formats?
  • What if there was some kind of single point of data that could address the needs of every engineering design domain, without having to import/export a file?
  • And more importantly, if we didn’t have to throw dumb black boxes around, what would that do to our engineering processes as a whole?

Your Ticket to Freedom

This might sound a little crazy, but the world doesn’t need another exchange file format? Because no matter how much more data we include when we hit that import button, we’re still not getting to the root of the problem. We’re still focusing on designing and engineering in silos instead of working together on complete products. That’s the real problem, and we need to fix.

Here at Autodesk, we believe in the Future of Making Things that aren’t bound by black boxes of data. Look around you, and you’ll see electrical and mechanical engineering starting to blend into one in things like molded-interconnect designs (MID). How is another black box going to help us design these kinds of products that are almost entirely merged?

This is why we see the current reliance on exchange file formats as a failure. They’ve gotten us to where we are today, but they won’t get us to where we’re going in the future. It’s time to think differently…time to think out of the black box.

Want to be a part of the change? Very soon, we’ve got some big surprises in store for how you share your ECAD design data. Until that time arrives, download your free version of Autodesk EAGLE today!

Subscribe to Autodesk EAGLE

For as low as $15 a month.