Tag Archives: electronics data transfer

More Fun File Facts: ODB++

Posted on by

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/

Fun Facts about Manufacturing Files

Posted on by

Circuit boards live and die by their manufacturing files. Without complete and accurate information, the board fab house can’t fab the boards, the assembly house can’t assemble your boards and nobody can buy the parts.

Our old standard, the Gerber file, has been around since about the time King Arthur pulled the inductor out of the solder pot. It’s old. We all use it because it’s familiar, but it’s day is done. It’s time to pass the torch.

IPC-2581 is the new standard in manufacturing files. It hasn’t been fully adopted, but it’s showing up in more and more CAD packages. The IPC-2581 format is much more advanced and has the complete data set in one file. While we still work with Gerbers every day, we can also accept IPC-2581 manufacturing files.

I’ve been called the champion of bad analogies, but I’ll try one out anyway.

Imagine, if you will, a map of the city. All of the streets are there. All of the houses are there. What’s missing are all of the street names. No street names, no numbers and no landmarks of any sort are labeled.

Given that information, find John Smith, at 1620 SW 14th Avenue. There is a house at 1620 SW 14th Avenue. There are a dozen or so houses at 1620 something. You just don’t know where 14th is, or which direction 14th runs, or where the street numbering starts.

You can physically walk each and every street until you find John’s name on his mailbox, but it’s not an easy nor error-safe process. And, hopefully, the town only has one John Smith. That’s a Gerber file.

IPC-2581, on the other hand, is an electronic map, with everything clearly labeled, and a GPS guiding you. Which would give you more confidence?

Duane Benson
IPC-2581 is like shatter-proof glasses for Henry Bemis

http://blog.screamingcircuits.com/

 

ODB ‘Partners’ Up

Posted on by

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.

2581 Hits a Milestone

Posted on by

For years one of the hangups for any data transfer format hoping to supplant Gerber has been the lack of independent validations that the output from a given CAD tool could be accurately read in CAM.

That’s why the IPC-2581 Consortium is right to herald today’s announcement of not one four independent validations as a “significant milestone.”

Today the Consortium published a validation matrix showing data output in Cadence Allegro and Zuken CR5000 has been correlated and validated against typical proprietary and multi-file manufacturing formats by Adiva, Wise, EasyLogix and DownStream. Those CAM vendors also are launching viewers — free, in most cases — to help users compare the data themselves.

The Consortium will take its show on the road next week, presenting a paper at Apex and also at the Cadence users group meeting in March. Both events represent an opportune time to question the members on their progress. If you can’t make the conferences, tune in to PCB Chat on Feb. 22, where the members will answer questions in our new online moderated chat forum.

Chatting It Up

Posted on by

Fresh off the success of our premiere PCB Chat, we have quite a few more planned.

Tomorrow (Feb. 7), SMT process consultant Phil Zarrow will take your questions. Designers may remember Phil from some of the past PCB West and PCB East conferences, where he spoke on DfM/DfA.

Next week we will host the IPC-2581 Consortium, taking questions on the new data transfer standard.

On March 2, yours truly will discuss the IPC Apex Expo trade show.

We begin accepting questions for the chats a few days early, so don’t worry if you can’t make the live event. Transcripts are available in real-time and after, too.