Is there a return for extending your CAD data knowledge?

In conversing with test and inspection professionals, I’ve noticed many are discussing system programming time and issues that relate back to their original CAD data. One likely reason for this is that the standardization efforts that organizations like IPC and iNEMI have attempted have not resulted in a widely accepted standard. This means users still have a variety of CAD formats on both the input and output side, which contributes to mass confusion in the test and inspection world. While the process preparation and programming solution providers have made great advances in database infrastructures, customized outputs and the reconstruction processes to convert CAD types into manufacturing friendly data, etc., the reality is users still wrestle with the effective use of CAD data in manufacturing, inspection and test environments.

The CAD you start with will directly impact the program you end up with and will influence how much time you have to invest to come up with a robust test program. In general my experience with test engineers is they do not want to spend a lot of time messing with the CAD. They would like to trust the sources and simply plug-and-chug through a CAD conversion process using whatever CAD translation tool is available.

I believe this applies across the board to imaging and in-circuit system programmers. I would bet that the process engineers have similar motivations when trying to program a screen printer or pick-and-place system. The less time they spend with CAD, the better. Therefore, in many cases, test and inspection users and programmers are trying to follow a CAD conversion process without first learning their target system requirements. In this case, the definition of target system is automated optical inspection, automated x-ray inspection or in-circuit test system. In many cases, users are not investing the time to evaluate the target system requirements in concert with what data they have. This is partially because of bandwidth, but if they did invest and then looked at what they have in their toolbox to create the required test system output data, that alone would shorten the time to production and reduce needless errors.

For example, when trying to ensure data compatibility with the desired task, if a Gerber file is all that’s available and you are trying to use that to populate files for ICT, you have a fundamental disconnect. How many examples have I heard where folks have spent hours or even days “playing,” only to find themselves in this situation. You cannot drive ICT with just Gerber because it lacks the netlist and component-level data. It seems obvious, but countless stories about time wasted made me realize there must be a bigger problem here.

It seems that, in the absence of widespread standardization, if test and inspection system programmers invested time upfront to learn about the file formats in concert with really understanding what their target system was after, the ROI would be great.

How can test and inspection professionals become more proficient in handling CAD data? Most of the formats are detailed online and can be found via a quick Internet search. Reading about the formats is a good first step. CAD solution providers are great resources, too; they are interested in helping users and offer classes, online support, and so on. Programmers can also open most formats in Notepad and get a feel for what’s included. If you did this, you could identify early that, for example, you are working on a process that is centroid-focused, but that the file you are working from does not have centroid data!

Again, it seems obvious, but if you do not invest the time to dig into the files to see what you have, you risk days of waste. Ask yourself, are these reasonable data? Can I just dump them to the given format? If not, what do I need to do with them? Sometimes those who extract the CAD and give it to the programmer do not always know what is needed by the target system. Thus, if you accept what they send without evaluating it, time can be wasted. If the programmer is educated about what is needed, they can specify these exact needs to the extractor. In the global manufacturing world, often is the case where the designers or layout group and test engineers do not sit in the same place – or even the same company. Another path could be a centralized data solution that pushes the CAD interactions farther upstream.

Learning about the CAD ecosystem for your process from the files available, what is in those files, what you need in the files, what your target system requires and then what your CAD tools can and cannot accomplish will put you in position to shorten time to production. CAD layout tools were never intended to drive test and assembly the way they support bare board fabrication. But very often, unfiltered non-optimized CAD data are all you have available to do your job. Therefore, you really need to know what you are trying to accomplish in order to succeed.

Stacy Kalisz Johnson is Americas marketing development manager at Agilent (agilent.com); stacy_johnson@agilent.com.