Issue link: https://iconnect007.uberflip.com/i/378511
22 The PCB Design Magazine • September 2014 Coates makes much of the claim that ODB++ is a single format and that what I propose is a collection of different formats. This underpins his argument that the good old Gerber format should be dumped and replaced with some- thing entirely new. This is a curious argument indeed: ODB++ is in reality a collection of fold- ers with different syntaxes for each type of data, which are all zipped together in a single archive file. In my opinion this is not a showstopper— on the contrary, it's an inevitable consequence of the fact that components, materials, graph- ics and netlists are all entirely dissimilar objects. They must all be stored in appropriate formats, each of which, by its very nature, is very differ- ent from the others. All they have in common is the ODB++ name. This is clearly demonstrated by the following: if ODB++ image input is im- plemented in your software, it will not miracu- lously read materials. Even though you may be able to write images, you cannot automatically write a netlist. These are separate items that re- quire individual implementation, each with its own specification, each in its own folder. This is OK; it is impossible to put these intrinsically different objects into the same format. But I fail to see the difference between zipping together a collection of very different ODB++ folders, and zipping together Gerber and IPC-D-356A files. To anyone who might object that 356 is a different format from the Gerber format, I would propose the following thought experi - ment: Take the 356A specification, tear off the title page and replace it with a page with the title "Gerber Netlist Format." Lo and behold, now, images and netlist are in the same Gerber format! In other words, there's no substance to the claim that ODB++ is a single format—it's all in the name. Of course, in both cases, the in - formation must be consistent. If you offset the netlist to the image, well, you have a problem, both with Gerber and ODB++. What I propose is that we, as an industry, take a practical and pragmatic route to improvement: by keeping what works well, changing what does not and adding what is lacking. With Gerber X2, we are doing just this, as Graphicode's Paul Wells- Edwards points out: "The beauty of Gerber is that it's simple, and very widely used, and Ucamco's use of attributes is a very clever and straightfor - ward way to improve and build on it. By extend- ing the format and making it far clearer, Ucamco has improved the CAM task no end." Indeed, it makes no sense whatsoever to to- tally abandon something as good as Gerber's im- age format, which covers the most difficult and critical part of any PCB data archive, to resolve issues relating to the archive's far simpler ele- ments. The industry intuitively senses this, and this is why it has stayed with the Gerber format. X2 has been designed to be easy to imple- ment and easy to adopt, as it consists of just three new straightforward commands, and sup- port for it is growing. Graphicode is pioneering the X2 wave with GC Prevue v22.3, the indus- try's first X2-ready viewer software, which is now available for download. Altium too has been quick to recognise the value of X2 and will support it in the upcoming version of Altium Designer. I was recently informed that DipTrace and Kicad will also output X2 in the course of 2014, and LPKF will support it from Q1 2015. Eurocircuits and AT&S offered to beta test it, and it will be in real production by the end of 2014—less than 12 months after its introduc- tion. This demonstrates the benefits of smart improvements: fixing what is broken but leav- ing in place what works well, which takes into account the community's legitimate concerns about cost and risk. This is why I advocate X2 as the smart way forward. Karel Tavernier Ucamco feature THE GREAT GERBER VS. ODB++ DEBATE continues