Obviously, the Gerber format has and continues to serve the industry well. If it didn't we'd already have significant adoption of an alternative format. The reluctance of so many engineers to embrace a successor is testament to the durability of the format.
However, ODB++ and IPC-2581 include a lot more information. I liken it to looking at a city map with no address information as compared to one with full address information and a good legend.
The additional information included in the newer standards is incredibly valuable to assembly service providers. It is certainly possible to get all of the information needed to build a quality board out of a traditional set of files, but ODB++ and IPC-2581 reduce the time needed and reduce the opportunity for errors. Both of those factors are very important in today's world of super fast turn-times and extreme cost concern.
Indeed, Ucamco wholeheartedly supports IPC-2581. My message is not a statement against 2581, quite in the contrary. I am indeed aware of the limitation of Gerber: while 2581 is a full CAD-to-CAM date transfer format while Gerber is a modest image file format.
However, I object to allegations that Gerber is bad image file format.
- I object because it is utterly untrue. Gerber is a perfectly adequate image transfer format. Otherwise millions of PCB', from the simplest to the most complex, would not have been made with it. With a well-implemented Gerber file the image will be transferred without a snatch. As is usually the case.
- I object because 2581 is debased by statements that 2581 is a cure for alleged deficiencies in Gerber as an image format. If this is what 2581 brings to the table we do not need 2581. Images can be transferred without a glitch with a properly implemented Gerber workflow. The value of 2581 is what it does beyond the image. This is what must be explained. Repeating over and over that 2581 is great cure for painting or for the lack of scale/unit is an insult to 2581. Surely, better reasons to use 2581 can be given than this!
Ed, you are of course correct that there are poor Gerber implementations. This is a real issue and it must be addressed. But 2581 as not a solution for this, quite in the contrary. If anything, it will make implementation issues worse. Does anyone really think that if someone can't be bothered to move from D to X will move to 2581? Does anyone really think that if a someone unable or unwilling to implement a simple format as Gerber properly after all these years will miraculously make a state-of-the-art implementation of the far more complex 2581 – or ODB – in any reasonable time; we should already be grateful for a proper Gerber implementation. Promoting 2581 as a solution for poor Gerber implementations makes no sense.
We at Ucamco do what we can to address the issue of poor implementation. We are a small company but we do our best. (And gain not a single dime and little gratitude for this effort.) When issues pop up, we go back to the specification and clarify it when needed – it is now the clearest image file format specification in de industry. We coordinate with Graphicode about their well-regarded viewer. We write protocols on invalid files for the benefit of the originators of files ; we contacting companies producing such files; some react and improve their software, some don't care. This is the only way, patience, clarifying, explaining again, and again. For such problems, a new image format will not improve matters; it can only make it worse.
Yes, I want 2581 to succeed. However, I think that asking people to dump their current workflow and adopt a new format wholesale is asking very, very much. The track record is not encouraging. Despite several attempts, IPC has never succeeded with a full PCB description format. It's only successful format is 356, very useful indeed, but a modest success. 2581 is 10 years old and not a single production PCB has been made with it. (Admittedly, the consortium can very well make a difference here).
I think a gradual approach can break the deadlock. Initially keep good old Gerber for the images and 356 for the netlist, and use parts of 2581 for areas where there are no existing standards, especially the stackup. In other words keep what works, break nothing, and improve what does not work. And over time the role of 2581 can be expanded. This is the best way to kick-start a move towards 2581. (For those interested, these ideas are explained in detail in my article "Kick-Starting a Revolution: IPC-2581 Meets Gerber." published in the PCB Design Magazine of January 2013.)
But I have nothing against at two-pronged approach: a full conversion for the strong and the brave, a gradual conversion for the majority.
Ucamco, under Karel's guidance, is among the 12 companies who founded the IPC-2581 consortium to advance industry adoption of the standard. Karel knows IPC-2581 well, having served as a principal member of the committee responsible for the standard, and no one could be more aware of the limitations of the Gerber format than he is. Yesterday, on October 16, the IPC published Revision B of the standard as finalized by the 46 companies, including Ucamco, who now comprise the consortium, toward implementation throughout the PCB manufacturing chain. Whether IPC-2581 ultimately will speed fabrication depends on how well the CAD tool vendors, DFM software developers, and CAM software suppliers implement the standard, which is no less true of any other scheme for PCB description.
Karel points out that Extended Gerber superseded Gerber D two decades ago and that it eliminates ambiguity about how data are formatted. There are dozens of CAD tools for PCB layout, some of them free. They output Gerber files, but in some cases their implementation of Extended Gerber may be flawed or incomplete. PCB fabricators sort out the results day in and day out, and continue to deal with designs that arrive in Gerber D format. Karel proposes sticking with Gerber files and borrowing the stackup provisions of IPC-2581. Whether his argument gains traction or the IPC concensus prevails, PCB manufacturers have no financial stake except for saving time and labor.
Thanks for explaining the benefits of integrated formats such as ODB++ over Gerber. All mainstream EDA tools have the capability to output ODB++, with all the benefits that you describe so well in your article. Regarding the future development of the format, I would point all readers to the new revision of ODB++ (released earlier this year at http://www.odb-sa.com/resources/ - sign up free of charge to download). The format is open to the whole industry, as it has been since original introduction, contrary to what Mentor's competitors may wish to imply. A large proportion of the world's PCBs are manufactured based on this data format.
This is an informative article, but unfortunately it repeats some persistent errors about the Gerber format. As developers of the Gerber format, we feel compelled to react.
- The author writes: "When a board manufacturer receives Gerbers, someone in front-end engineering has to identify how the data is expressed [...]. Is the data in metric or English units? Are coordinates in absolute values from an origin or in incremental values? Is the coordinate data in 2,3 or 2,4 format?" This was true in the days that only Standard Gerber or Gerber D was available, now more than 25 years ago. This issue was addressed by the %MO and %FS statement in Extended Gerber or Gerber X. Gerber D was deprecated many years ago. Yes, a small number of people continue to use Gerber D. However, if these people cannot be convinced to make the simple step from D to X, how will they be convinced to jump to ODB++ or 2581? A totally new format is not the solution, in the contrary it makes abandoning deprecated D harder. Fortunately, only a few D diehards remain – less than 2% of new jobs are in D according to a statistic from large European manufacturer. We can condider this problem solved.
- About "There is no fixed rule for naming layers,[...]". This criticism is justified. However, the statement "Worse, if the layer designations are misinterpreted, DFM analysis can be incorrect [...]" is overdoing it. Granted, the manually setting the layer structure is manual work, and this must be addressed, but far less scrap is produced by errors in the layer structure than by errors in the image. (The same manufacturer mentioned above stated: "There are actually very few problems with Gerber images.") In the technical note Extending the Gerber format with attributes on www.ucamco.com/downloads we make a quite simple proposal to solve the lack of standards in this respect. A summary can be found in "Gerber grows attributes" published in PC Design and Fabrication in August this year. The neat thing about this proposal that it a simple solution to a simple problem. The complex part of CAD to CAM image transfer is the image transfer. Errors here are fiendishly difficult to detect, and these do lead to scrap. Industry practicioners are not morons, as some try to make use believe, and they are understandably reluctant to abandon a trusted and field tested image format for the modest benefits of a formal layer naming convention. The neat thing about our proposal is that that they reap the benefit of more automation without abandoning the image transfer. It leaves alone what works well, and improves what does not work. We are encouring industry practicioners to give feedback before we cast this in a formal revision of the Gerber format.
- About the single format and single file to describe for image and netlist, etc. This is altogether a misconception. The same format cannot describe image and netlist. Image and netlist are totally different entities. One can call a netlist and image format by the same name, one can publish the format in the same document, they can even be stylistically similar. But they are not the same. It is not because a piece of software can read an ODB++ image it can micaculously read an ODB++ netlist. They latter needs a separate development for, well, a separate format. Gerber is perfectly adequate for the image. IPC-356-A is perfectly adequate for the netlist. They are different, as they inevitably are. As different as the image and netlist description in ODB++. As to the statement that they must be in a single file? True enough. If you zip the Gerber layers and netlists together you have a single file. This is actually what ODB++ does. ODB++ is a fairly complex directory structure, representing the native Genesis CAM format. To make it a single file, it is compressed in a single .tgz. I have no problem with this, but I feel to see why I Gerber archive would be different in this respect.
I am firmly convinced to road forward is by building on existing standards, use what works and enhance what does not work, as described in the article above. Gerber works for images and IPC-256-A works for netlists. Keep them. Does it mean we are against IPC-2581? Quite in the contrary. IPC-2581 covers areas where there now are no standards, mainly the materials and components. Let us adopt these subsets of the standard, but for those that are undestandably reluctant to abandoned tried and trusted Gerber use Gerber for images, and IPC-2581 for the materials. (According to the same manufacturer: "Gerber images and IPC-2581 stackups, this is the best of both worlds.) Both Gerber and 2581 are part of the ideal solution. This concept is explained in more detail in the article "Kick-Starting a Revolution: IPC-2581 Meets Gerber." published in the PCB Design Magazine of January 2013.
Timely article... I hope more companies follow the move to offer IPC-2581 format design files. I wonder how long it will take for a majority of the EDA tool vendors to implement this, this is a badly needed piece in the ecosystem.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.