Data, data, everywhere, but not a digit can I read
Well, it is not as bad as it sounds. Over the last 25 years, PCB fabricators and CEMs have learnt to live with whatever data the electronic trade throws at them.
What’s the problem then? Electronic design is by its nature prescriptive and certain. In contrast, the data passed to manufacturers to make these designs is often disjointed, unintelligent and random.
A long time ago we started with drawings that could be eyeball read and informed the manufacturer of everything they needed to know about the product. Production machine programming was manual, laborious, and error prone. But the drawing had all the information required in one universally readable document. It was compact and complete.
Modern CAD design
Today, all designs are on CAD, so raw data is available for every aspect of production engineering. And this is the problem. Being a contract electronic manufacturer (CEM) interpreting client data can sometimes be like listening to a crowd shouting instructions. Some of the instructions will be in the data, some on an email, some in a phone call, some in the CAD file. Some will be missing. Highly trained staff are required to translate this babble into a prescriptive and certain electronic design. They have to sift the data sent to them, filter out the nonsense and flag the trip-wires. Expensive software translation tools are required to read the infinite variety of data dialects and to interface between the various manufacturing machine processes. Human intervention and judgement are a necessity. A robust engineering system this is not.
Despite this, most CEMs do a good job. They have to, because clients assume that if they find their instructions ambiguous. They do whatever it takes to get the job done right.
Does it have to be like this? Clearly not, but attempts to standardise electronics manufacturing data have only been partially successful.
One problem is the sheer complexity of the task. CEMs now use every piece of the design data to assist in the manufacturing process, and they would if they could, use it all in a direct readable format (XML of course).
We are talking of:
- Gerber for artworks
- Net-lists for electrical testing
- Profile data for routing
- Drill programmes
- Copper thicknesses for builds and etching
- Layer construction for multi-layer build, blind and buried vias
- BOMs for estimating, buying, kitting, AOI, component identification, pick & place
- Footprints for solder paste stencils
- Schematic diagrams for final test.
- Component centroids and rotations for pick & place
- Data for shop-floor documentation
and more…
Comprehensive data standards for PCBs have been around before. ODB++ (Open Database, Valor Genesis / Mentor) was supposed to be the solution as was IPC-D- 350 and its successor GenCAM. Neither is now widely used. They could be used, but for the most part, they never achieved critical mass support in the electronics community. When CEMs do receive ODB++ data, some is not readable by translating software because of the poor observance of standards by CAD software vendors. So electronic engineers mostly stick to sending Gerber, BOMs, pdfs, and component centroids. This is for a very good reason. It is because it works and the costs of translation and interpretation are not charged to them explicitly.
So the issue of data compatibility has fallen into disrepute. There is a lack of belief that it will ever be possible, and that “workarounds” are OK. They have to be, we work in a real world, and jobs have to be done. Data translators and interrogators have become intelligent and sophisticated, and ever more expensive. They mostly function effectively. It is the 80:20 rule. Most PCB designs are straightforward or pretty standard. It is the minority of complex PCBs that cause the problems.
The latest attempt to achieve a universal electronic manufacturing data standard is IPC2581, an XML development of GenCAM. This builds on the shoulders of previous standards. It is an attempt to be all encompassing and to provide every bit of manufacturing data in a standard electronically readable format. IPC2581 describes the entire circuit board from schematic to parts list to board assembly and test.The team behind it are encouraging adoption and implementation.
It is a complex standard. Success is highly desirable. The current incoherent data structures are a poor solution, and electronics deserves a standardised data. Some significant CAD software vendors already support IPC 2581. Some are sitting on the fence. Others are ignoring it as too complex.
I am reminded of the universal language called “Esperanto”. What a great idea that was. One simple structured language that everyone could learn as well as their local language. Then everyone could communicate with each other, and only ever to have to learn one new language.
IPC2581 would be the common language of electronic manufacturing data interchange.
The problem is we already speak the other languages, so why should we learn another? Is this where we are with IPC 2581?
We have already sunk money in buying and maintaining software tools to read, analyse and translate manufacturing data of every description. IPC2581 is another input format, with additional licence fees to be paid. Until the CAD vendors incorporate IPC2581 outputs as standard, free of charge, there will be no supply of IPC2581 data. What is the point of having the facility to read IPC2581 if none is ever sent to you? It is chicken and egg.
We, at PCB Train, are ready to read IPC2581 data. We just do not see any of our customers offering it to us yet. The low end CAD software vendors also do not seem too interested in it, having no reported plans to incorporate it as standard. Some high end CAD vendors do support it, and there is an active community pushing its introduction which deserves support.
Let’s hope they succeed, IPC2581 is a much needed and desirable tool which will deal with our anachronistic data standards, and benefit the electronic community as a whole. If your PCB CAD layout software cannot output IPC2581, ask your supplier why not. Make IPC2581 compatibility an essential requirement when you upgrade.
Meanwhile, how do you say “please send us IPC2581 data” in Esperanto?
Philip King
Latest posts by Philip King (see all)
- 11 Inspirational Electronics TED Talks - 26th June 2015
- Team Impulse Win UK CanSat - 1st June 2015
- What is Graphene and What Will it Bring to the World of Electronics? - 19th May 2015
Leave a Reply