Issue link: https://iconnect007.uberflip.com/i/374650
62 The PCB Magazine • September 2014 AND THE DATA TRANSFER BEAT GOES ON… continues linked to the graphical objects as well, and vice- versa? The problem that needs solving is taking all of that fragmented data into a single coher- ent model comprising both the PCB bareboard and the assembled PCB. Actually, in no way do I reject the idea of linking all the other information to the graph- ics objects. On the contrary: It's clear that a PCB is more than a set of images, and all the data describing it must be transferred as a coherent whole. Here, too, we agree. Where we disagree is how we achieve this coherent whole. Julian believes that the wholesale adoption of ODB++ is a practical way forward. I do not. In another passage from his July rebuttal, Julian correctly analyses why ODB++ is not more widely used: "What limits the implementation of ODB++ more widely? … I would suggest that the reason is not technological; it is a combination of busi- ness and human factors. Firstly, it costs mon- ey to change a business process; tools have to be upgraded. […] 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 meth- od is expensive and uncertain. The safe versus uncertain part is the human part." These are entirely rational and justified concerns, and clearly the vast majority of this industry feels that they out- weigh the benefits of ODB++ (or of any new format that has been tried over the decades for that matter). Who am I to judge that the whole industry is wrong? That said, our indus- try must move on, and like Ju- lian, I too would like to see CAD to CAM data transfer advance beyond current practices. This is why I propose a path that is far less expensive and risky than that ad- vocated by Julian. The first step along this path was to clarify areas in the Gerber format specification that were sometimes misunderstood, and to remove elements in it that were outdated, rarely used, or superfluous. This has been carried out in re- cent years, so the current spec is clear, sharp and to the point—there are no useless bells and whistles in the Gerber format. The second step, completed earlier this year, was to introduce the Second Extension, or Ger- ber X2 format. Gerber X2 contains attributes that specify how the layers stack up, identifies via pads, indicates where the impedance con- trolled tracks are, and describes a host of other parameters that support the image data. With X2, what was missing in Gerber has now been added—in Julian's terminology, the attributes add intelligence to the format. The neat thing is that they do not affect the image, which means that existing workflows are not broken: X2 re- quires only minimal changes in working prac- tices, and certainly none that would require approval, testing and all the rest. The fully X2- compatible CAD and CAM software will read entire Gerber X2 archives automatically, with all layers in place, while identifying the function of each object. And even in combination with older software that does not support X2, the correct image is still produced. This means that even if users do not reap the full benefits of Gerber X2, they can happily move within the X2 world without problems. Ben Jordan of Altium concurs: "ODB++ is a good standard, but Gerber X2 does solve the problems while being back- wardly compatible." More importantly, this means that nobody is forced to buy anything, and Ger- ber users can decide in their own time if, how and when to adopt new X2-ready software to take their processes to the next level. For those interested, there is a sample X2 job on the Ucamco download page. It shows the simplicity of the concept. Download it and try it on your own Gerber input software—in all probability you will be able to read in the imag- es correctly, but your software will throw some warnings. This demonstrates the compatibility of X2 with non-supporting software. Who am I to judge that the whole industry is wrong? That said, our industry must move on, and like Julian, I too would like to see CAd to CAM data transfer advance beyond current practices. " "