Issue link: https://iconnect007.uberflip.com/i/378511
September 2014 • The PCB Design Magazine 19 THE GREAT GERBER VS. ODB++ DEBATE continues feature way forward is to use Gerber for the graphical data and another format for all the other in- formation that Gerber cannot carry. Thus, he promotes the idea of intelligent, all-encompas- sing formats for carrying data, but excluding the graphical part. Why reject the advantage of having all of that other information linked to the graphical objects as well, and vice-ver- sa? The problem that needs solving is taking all of that fragemented data into a single coherent model comprising both the PCB bareboard and the assembled PCB. Keeping parts of the pro- duct-model seperate for simplicity is fine if you are only interested in a narrow subset of the PCB product-model, but it is a big problem if you need a complete definition of the product, as do all DFM and NPI engineers! There is no escape from the fact that, sooner rather than la- ter, the data must be integrated. Reductio ad absurdum: To take the idea to an extreme, maybe there is a drilling expert out there ready to explain that Excellon should be used for holes information, but all of the "other information" (including the layer graphics, no doubt) should be carried in ODB++. Obviously it is absurd to keep part of the PCB product-mo- del (in this case, the holes) separate from all the rest. The first thing a CAM engineer would do in this case would be to read the Excellon file and integrate the hole data into the ODB++— an unecessarily time-wasting and potentially error-prone process. There is a broad consensus across the indu- stry that fixing the highly fragmented nature of the CAD-to-CAM data files problem is long overdue, and that the answer is to implement integrated, intelligent formats such as ODB++. Many have already taken the step with ODB++, attesting to the benefits of having a more stre- amlined design-to-manufacturing hand-off pro- cess. Over a million different PCB designs have been processed into manufacturing using the ODB++ format since its introduction. It works, and is widely implemented by some of the lar- gest electronics OEMs in the world, as a stan- dard part of their NPI business process. What limits the implementation of ODB++ more widely? Why do people still use all tho- se fragmented narrow-scope data formats such as Gerber, Excellon, netlist, component-pla- cement list, etc? I would suggest that the re- ason is not technological; it is a combination of business and human factors. Firstly, it costs money to change a business process; tools have to be upgraded. But in order to gain the time/ cost/quality advantages, an investment has to be made, and that is nothing out of the ordi- nary. Secondly, there is a perception that con- tinuing to use the old method is not only free but also "safe," whereas to use the new method is expensive and "uncertain." The "safe" ver- sus "uncertain" part is the human part. There is an jargon-acronym for it: FUD, which stands for Fear, Uncertainty and Doubt. The same was true when the Gerber format was introduced. Using it required a high level of investment, and it took time for the industry to see that the benefits outweighed the uncertainties even though the idea of it was obviously a good one 50 years ago. Hand-drawn artwork was still used for many years after, even though a bet - ter method (Gerber data) was available. It took time for the industry to make the change. But change is inevitable if businesses intend to ad- vance given the complexities of today's systems designs. This is why I advocate ODB++ as the new data format standard. Julian Coates Director of Business Development Valor Division of Mentor Graphics Corporation Karel Tavernier's Rebuttal: And the Data Transfer Beat Goes On… In a recent article, Smart Data Formats Auto- mate CAD/CAM (February 2014), Julian Coates of Mentor Graphics wrote an article about the ODB++ format. My reaction to this, Gerber— the Smartest Way Forward, appeared in the July 2014 edition of the same publication, as did a rebuttal by Coates of my article. Here I would like to rebut Coates' rebuttal of my rebuttal. To be merciful on readers, I will keep it brief, so that the rebuttal process con- verges rather than spinning out of control. In Coates' July rebuttal, he wrote: "No doubt Gerber is a very fine format for defining the graphical layers of a PCB."