Electronics Manufacturing Files: What We Need

Manufacturing is all about taking data from you and delivering some good working circuit boards. Well, it can be just data — as in full turnkey — or data plus some parts and or PCBs, as in a partial turnkey or a kitted job. Regardless of whether you’re sending parts and boards, or having the us as the EMS buy everything, we need good data, and a lot of it.

That data are the difference between the working boards you want and need and a random jumble of expensive paperweights.

We need a bill of materials (BoM), the job specifications (which you give us by ordering and describing any special instructions on our website), and the CAD design files. Fab and assembly drawings are always a good idea too. A little extra time spent on the files sent reduces risk, and that’s a very good thing.

The CAD design files include Gerbers, a centroid (aka pick-and-place or XYRLS file), and intelligent CAD files, such as ODB++ or IPC-2581. In some cases, such as Eagle CAD, we can use the native CAD board file.

The ODB++ and IPC-2581 file formats are the future of electronics manufacturing. They come with more data, and more accurate data, than do Gerbers. If you can send either of these two, please do so. Even if you have those, still send us the Gerber files. Gerbers are the lowest common denominator, and provide a base that we and PCB fabricators can work from.


The Gerbers are a set of files used to create the various layers of the board. Each layer requires an individual file, so a six-layer board (six copper layers) will typically require at least 13 distinct files: one for each copper layer, top solder mask, bottom solder mask, top silkscreen, bottom silkscreen, the drills holes, and solder paste for the top, and bottom if the board has SMT parts on both sides.

The drill file is combined with the Gerber files to line up the via and through-hole component holes with the appropriate spots in the PCB. Then the pick-and-place file will tell the assembler where to put each component, what angle to place it at, and which side of the board it goes in.

Fab drawings hold a human-readable, often in PDF format, description of the board and any special instructions needed by the fabricator. The assembly drawing would be the same, but for the assembler.

Sometimes the parts are too densely packed for the reference designators and polarity marks to show up on the actual board, or for aesthetic reasons, the designer doesn’t want them on the board. In such cases, all that information would be put into a set of assembly drawings; PDF files showing all of the necessary reference information.

As of this writing, the ODB++ and IPC-2581 file formats aren’t universally accepted, but are getting more so all the time. Use of these new intelligent CAD output file formats helps to reduce the number of manual steps and human interpretation, and will eventually lead to better quality and faster manufacturing times.

Duane Benson
What do we need?
What does it really matter?
Matter converts to energy
E=(what we need)C2

ODB++ Plus, Plus, Plus

I wrote a bit about ODB++ back in October. Nothing has really changed much since then. I’m just clarifying a few things.

First, I want to put more emphasis on the use of ODB++. In addition to being beneficial to the manufacturing process, it can make your job a little easier. If you send ODB++, you do not need to send either the centroid or Gerber files. The ODB++ replaces both.

Eagle CAD does not have an ODB++ export. However, the Eagle .brd file will work too. You can send the .brd instead of the centroid and Gerber files.

If you can’t send either of those formats, we as an EMS still need the centroid and Gerbers (top copper, bottom copper, solder paste stencil, silkscreen and solder mask layers).

Duane Benson

Number Six
I am not a number, I am a free man!

http://blog.screamingcircuits.com/

More Fun File Facts: ODB++

In my last post, I wrote about the up and coming IPC-2581 PCB manufacturing file format. While IPC-2581 may be looked at by PCB fabricators and assemblers as a holy grail of sorts, it’s not yet widely adopted by CAD software. But, that doesn’t mean that Gerbers are the only option.

ODB++ was developed by Valor in the waning years of the last century as an improved method for getting manufacturing data into their CAM systems. Valor and, hence, ODB++ was purchased by Mentor Graphics in 2010. ODB++ is still widely available, however there’s concern in some circles that it’s not truly open. That concern is where IPC-2581 came from. In fact, IPC-2581 is somewhat derivative of ODB++.

I can see how a CAD software developer might fear the use of something owned by a rival. However, my understanding is that Mentor does it’s best to treat it like an open standard and has made it available more or less as though it is open.

The history isn’t really important. What is important is that ODB++ is a more complete format than the Gerber and is widely supported. Pretty much everything good that I said about IPC-2581 in my prior post also applies to ODB++.

The bottom line is that, regardless of whether Screaming Circuits is your fab (through our partner Sunstone) and assembly (through our factory right here) provider, ODB++ is a good thing. It makes the job easier and more accurate than does use of Gerber files. Both “easier” and “more accurate” help keep costs down and keep ambiguities to a minimum. As you know, ambiguity is the bitter enemy of both accuracy and quality.

Unfortunately, for all of you Eagle users, Eagle does not yet support ODB++. If anyone out there is really good with Eagle ULP scripting, you might want to create a on ODB++ and/or IPC-2581 creation ULP.

Duane Benson
I was ionized, but I’m better now. 

http://blog.screamingcircuits.com/

ODB ‘Partners’ Up

After the IPC-2581 Consortium was founded to support the move from Gerber, it was only a matter of time before Mentor responded with a similar group to push its own format, ODB++.

Today, that measure was officially announced, with some 18 companies among the initial partners in what is being called the ODB++ Solutions Alliance.

Astute readers will notice many of the same companies are publicly supporting both formats. It will be interesting to see how that unfolds, given concerns by some of Mentor’s competitors about the advantage it gains with its hold on the ODB++ format.

Major Major and Standard Standard

We ask for your bill of materials, Gerber and centroid files to assemble your PCBs. All those pieces of information are necessary to properly program our machines to place your parts. That’s pretty standard stuff, but did you know that when the Gerber format reference book was first published, Jimmy Carter was President of the United States, Russia was the “Soviet Union” and Voyager 1 was well inside the Solar System?

Use of the format has been going on even longer. Yeah. It’s been around a while. For some reason, it has been very difficult to get everyone to agree to and use a standard file format. Gerbers really don’t have enough information in them to do the job properly, but it is the standard. Hopefully not for too much longer. How many of you reading this were even born when Gerber was new?

There are a number of formats around that are better than gerber and Screaming Circuits will accept many of them. First, your CAD software probably will export an “ASCII CAD file”. This is a good format. Some export ODB++, which is one of the newer formats, again a good choice. One of the newest standards is the IPC-2581. It’s been around a few years and is now getting a lot of attention. If you happen to use Eagle CAD, you can also send us the Eagle “.brd” file.

IPC-2581 includes the best of ODB++ and GenCAM. It has all of the fab data, assembly data, netlist and BOM. Everything needed in one convenient file. My understanding of the format is that you can exclude portions of the data set that you consider proprietary. You can learn more about the format here. There’s more background information on the subject at PCD&F magazine.

Duane Benson
Where’s Henry?
I need an inductor.

http://blog.screamingcircuits.com/

Data Transfer in the News

A couple new articles are out on the IPC-2581 and ODB++ data transfer formats.

On Oct. 2, longtime EDA journalist Richard Goering provided a well-written writeup on the “lively panel discussion” (“Data Transfer in the 21st Century”) we held during PCB West on Sept. 29. Richard does a nice job capturing the frustration of the designers present and historical give-and-take that has led us to the current situation.

And yesterday, EDN weighed in with interviews of participants from the data transfer panel held at PCB West and other key spokespersons.

Given the new support for IPC-2581 by Cadence and Zuken, among others, this issue isn’t going away.

Talk Isn’t Cheap

Communicating is hard. It took thousands of years just for man to develop a common language. I don’t suppose, then, even in our “enlightened” state, we should expect it to be easy to develop a common, complete method for describing all the myriad features of a printed circuit board.
This week at PCB West, the Silicon Valley annual trade show, a special panel will convene to address just that decades-old issue. (Disclosure: I’m the moderator.) I don’t expect the group to solve all the industry’s data problems in just 90 minutes, but I do think a few key aspects will be noted.

Here’s a question I plan to raise: Would the problem of unintelligent data files be essentially resolved if the initial cost to upgrade were lower?

Upstream, Intel, for example, sends an army of engineers to its suppliers to help them implement new processes. Few companies have the resources of Intel, of course. No fabricator does. And this leaves the fabs in a bind: They know that Gerber is insufficient, and spend countless hours massaging (often without their customer’s knowledge) the bad or incomplete data received from design. But with tooling jobs stacking up on their desks, and margins cut to the bone, they claim no resources to spend on implementing one of the richer data transfer formats like ODB++ or IPC-2581.

So who pays?

Neither IPC nor Valor make any money directly from their respective data transfer formats, so it’s unlikely either would see the value in extending themselves further by underwriting the onsite development and implementation work. (Whether they should anyway is a column for another day.) Designers tend to be risk-averse: They are unlikely to risk their jobs on something upper management is not mandating. Thus, it may be that the fabricators need to start assigning a CAM engineer to its key customers — perhaps one at a time, to keep costs down — to help them get up and running — no matter which rich format they choose.

The argument for switching to a superior format(s) is that manufacturers will save money down the road. I understand, however, that quantifying the cost savings is exceedingly difficult. Moreover, as one CAD developer told me, there’s an unwritten incentive for the status quo (read: Gerber) because manufacturers don’t want to appear inflexible.

I would argue that the industry’s margins can’t afford to keep sending bad data downstream and hoping for a miracle in return. Fabricators over the past decade have lost most of their influence over the printed circuit board development. This is an area where they can truly coach their customers — and add value in the process. They should grab it.

Talk Isn’t Cheap

Communicating is hard. It took thousands of years just for man to develop a common language. I don’t suppose, then, even in our “enlightened” state, we should expect it to be easy to develop a common, complete method for describing all the myriad features of a printed circuit board.

This week at PCB West, the Silicon Valley annual trade show, a special panel will convene to address just that decades-old issue. (Disclosure: I’m the moderator.) I don’t expect the group to solve all the industry’s data problems in just 90 minutes, but I do think a few key aspects will be noted.

Here’s a question I plan to raise: Would the problem of unintelligent data files be essentially resolved if the initial cost to upgrade were lower?

Upstream, Intel, for example, sends an army of engineers to its suppliers to help them implement new processes. Few companies have the resources of Intel, of course. No fabricator does. And this leaves the fabs in a bind: They know that Gerber is insufficient, and spend countless hours massaging (often without their customer’s knowledge) the bad or incomplete data received from design. But with tooling jobs stacking up on their desks, and margins cut to the bone, they claim no resources to spend on implementing one of the richer data transfer formats like ODB++ or IPC-2581.

So who pays?

Neither IPC nor Valor make any money directly from their respective data transfer formats, so it’s unlikely either would see the value in extending themselves further by underwriting the onsite development and implementation work. (Whether they should anyway is a column for another day.) Designers tend to be risk-averse: They are unlikely to risk their jobs on something upper management is not mandating. Thus, it may be that the fabricators need to start assigning a CAM engineer to its key customers — perhaps one at a time, to keep costs down — to help them get up and running — no matter which rich format they choose.

The argument for switching to a superior format(s) is that manufacturers will save money down the road. I understand, however, that quantifying the cost savings is exceedingly difficult. Moreover, as one CAD developer told me, there’s an unwritten incentive for the status quo (read: Gerber) because manufacturers don’t want to appear inflexible.

I would argue that the industry’s margins can’t afford to keep sending bad data downstream and hoping for a miracle in return. Fabricators over the past decade have lost most of their influence over the printed circuit board development. This is an area where they can truly coach their customers — and add value in the process. They should grab it.

A New Push on ODB++

As promised, here’s our interview with Julian Coates of Mentor’s Valor division. Julian has spent years working on ODB++, and he talks about Mentor’s plans and strategies for the data transfer format here.

More Info to ‘Transfer’

I’ve had the chance to speak with the ever-gracious Julian Coates about ODB++ and Mentor’s plan for the data transfer format. Will post that interview in a bit.