How can you use vision data?

Ask someone who works on a production line what a machine-vision system does, and most likely, they'll tell you it examines products and sweeps any defective ones into a reject bin. In fact, machine-vision systems can do more than give a go/no-go indication of product quality.

Most of the time, engineers must program a machine-vision system to look for specific types of faults at specific locations. In the case of a PCB, for example, a vision system could identify problems such as excess solder paste, insufficient solder paste, missing components, rotated components, misaligned connectors, and so on.

You can run analysis software either on the vision-system's host PC or on a remote computer, probably located on a network. But how do you get your data from the machine-vision software to the analysis software? The answer depends on what type of machine-vision software and hardware you plan to use and what you want to do with the data.

Most vision systems produced within the last few years use an open-architecture Windows-Intel (Wintel) PC as a host processor. This standard system simplifies the task of linking machine-vision software to other applications. Perhaps the easiest way to examine the data obtained for a defective product is to transfer it to an Excel spreadsheet.

Once you have inspection data in the spreadsheet, you can analyze it, plot defect trends, or "drop" yield data into reports. Vision software that conforms to either the DDE standard or the newer OLE standard for information exchange will let you link machine-vision data to an Excel spreadsheet (see "Terms and standards," p. 12). You'll also find other commercially available software, such as Quality Analyst 5.1 from Northwest Analytical (Portland, OR; www.nwasoft.com ) that links to DDE-compliant applications to extract inspection data for SPC analysis.

Even if your vision-software doesn't conform to either the DDE or OLE standard, it may let you export data in a file format, such as comma-separated-values (CSV), that Excel can import. Importing and exporting such files takes processing time, so if you must resort to this approach, you may want to process inspection data on a separate PC and not on the vision system's host computer. No matter whether you use a DDE- or OLE-compatible program or one that exchanges data in another format, ensure that your system saves its data in a standard format that you have access to in the future. Data saved using a proprietary file format will have little value if you can't extract the data in a form you can read and other applications can access. Ensure the application software also can save images in standard formats designated by the file extensions such as jpg, gif, or bmp.

To increase the usefulness of vision software and ease its communication with other applications and external devices, look for commercial software that makes it easy to add or extend features. The DT Vision Foundry software sold by Data Translation (Marlborough, MA; www.datx.com) can operate as a control from within a Visual Basic program. By using it as a control, you can provide an overall Visual Basic program that communicates with other applications and uses DT Vision Foundry as a machine-vision "component" of your overall inspection application. You also can use DT Vision Foundry as a DCOM wrapper so it can easily exchange variables and data with other applications (Ref 1).

In a similar vein, National Instruments' (Austin, TX; www.ni.com) IMAQ Vision Development Module provides software that lets you create machine-vision applications software and have the applications interact with programs written using LabView, Visual Basic, Visual C++, or other languages. National Instruments also sells DIAdem, a software package that presents a spreadsheet-like interface and includes many data-processing and data-analysis operations.

If your machine-vision software doesn't include support for network connections, it should at least supply the necessary "hooks" so you can link it with communication ports and a LAN card. This capability lets you connect what would otherwise exist as a stand-alone vision system with other vision systems and computers over an Ethernet LAN. Communications can take place using a variety of protocols, depending on the type of networked equipment your system must talk to. Because most Wintel PCs come with an Ethernet port, or can accept an Ethernet add-in card, the Ethernet has become the connection of choice for vision systems that must communicate with remote computers.

Some vision software comes with built-in HTML and e-mail protocols, so you can structure inspection reports for delivery as e-mail messages, or you can produce Web pages for use on the Internet or on a company Intranet. A vision system that can communicate using the FTP protocol can transfer entire files of data over the network to a remote server or PC. Of course, some of these applications will require setup or programming to produce messages, files, and Web pages in the proper formats. There's more to configuring a useful LAN connection than simply connecting vision systems' host PCs to a LAN's coaxial cable.

A LAN connection can allow vision software to transmit data to databases from which other applications can extract data. Microsoft's ODBC database standard predominates, so if you expect to save a large quantity of inspection data that other applications can access, save data using an ODBC-compliant format.

After you save the results of inspections in a remote database, a program such as InfinityQS SPC from InfinityQS International (Manassas, VA; www.infinityqs.com ) can extract the data and produce SPC charts and tables for engineering, production, and management reviews. This software operates with standard databases such as Oracle, SQL Server, Sybase, and Informix, which companies typically use for enterprise-wide applications. If you plan to use this type of analysis-and-reporting software and a corporate database program, you'll need to talk with your local IT department. The IT experts can tell you how to work with an existing database package or what software you should buy to produce the types of reports you need.

Your vision application may need to extract information from a remote ODBC-compliant database, too. Suppose the product undergoing inspection includes FLASH memory. You might set up a programming station that includes a machine-vision system. The inspection system would read a bar code or 2-D data-matrix code from the product and send the code to a remote database server. Then, the server would tell the inspection station which version of firmware to program in the product's FLASH memory. The database server also could update the programming station with new firmware as needed. Data in the server could note when programming took place, what version of firmware got installed, and so on for later problem tracking.

This type of database access, based on information read from a product, could find other uses. A vision system could access product data to

• determine that a specific module about to be inserted in a subassembly has passed all previous tests,
• ensure that a product about to undergo functional testing contains the latest firmware revisions, and
• set up the next test station for tests that work only with a specific type of PCB assembly.

It seems obvious that a vision system should collect information about defective products, but you may need to collect information about products that pass inspections, too. A system that inspects ball-grid array (BGA) packages, for example, should obtain information about ball size, ball circularity, placement accuracy, and other characteristics for all packages, good or bad. This data lets you track the ball-attach process and take corrective action before products start to fail.

Because a BGA can include 500 or more solder balls, the amount of data you acquire can accumulate quickly. In many cases, a vision system must communicate with a networked computer that can save large files of inspection data. You may have to consider compressing data files prior to transmitting them over a network connection.

Simply connecting vision systems to a corporate network may cause bottlenecks as large inspection-data files clog the system. You must determine how much network capacity the IT people have available and how much network capacity you need. Perhaps your vision system's host PC can temporarily save files and upload them when the network "sees" little activity. Of course, if engineers or managers need access to the files in real time, you may need to take another approach.

You might consider providing a network server for use only with vision systems. This sort of arrangement would reduce the network capacity required to transfer large inspection-data files, and when engineers need specific inspection information, they can request it from the vision-network server. Of course, such a dedicated server—even though it services many vision systems—adds to the cost of a machine-vision project.

Machine-vision systems may need to communicate directly with production equipment or programmable-logic controllers (PLCs) that provide special connections and conform to protocols developed for industrial use. The Profibus, for example, is widely used in industrial controllers, and protocols such as SECS/GEM, Modbus, SRFF, and OPC aim to meet the needs of equipment makers in specific industries.

Published standards document how these networks and protocols operate, but support varies, and few, if any, vision-system hardware or software vendors support all forms of industrial communications. If you need to include one of these specialized communication links in a vision system, expect only limited assistance from suppliers. System integrators who deal with these types of interface issues regularly and who have experience in your industry should provide better assistance. And because integrators work under contract, you gain the assurance that any systems they deliver will work with the industrial bus you specified. If problems occur, you know who will solve them.

If you choose to "roll your own" connections to an industrial bus, you can find third parties that offer various protocol adapters and add-in software modules that control them. But don't expect much handholding from these vendors. They expect you to know what you're doing and what you want to accomplish.

Although you can feed inspection data back to process equipment, at present, few people in the electronics industry actually take this step. Under ideal conditions, an inspection system could detect a run of several poorly positioned SMT components and alert the pick-and-place equipment to make a correction.

According to John Arena, a marketing manager at Teradyne (N. Reading, MA), production-equipment manufacturers have been reluctant to implement closed-loop control of their equipment when the loop relies on third-party vision systems as "detectors." In the electronics industry, the normal production variations (colors, shapes, and so on) of components and materials can lead to erroneous measurements. Should a manufacturer change from green to red PCB materials or from yellow to black components, for example, a vision system may have difficulty due to differences in appearance or contrast. Thus, what the vision system "sees" and communicates to a pick-and-place machine as positional data or as a fault may indicate more a failure of the vision system than a problem with the production equipment.

Before pick-and-place equipment accepts a measurement or fault diagnosis from a vision system at face value, the equipment supplier must ensure an associated vision system can provide accurate information. The vision system must do this despite the variations in materials and processes that normally occur on a PCB assembly line. According to Arena, the production-equipment supplier is best able to take raw inspection data and decide how to analyze specific measurements that correlate with the placement equipment's operation.

The inspection equipment itself shouldn't dictate an action. In the case of placing individual components, the vision system could report raw position, absence/presence, rotation, orientation, and other data. Then, the pick-and-place equipment's software could analyze the measurements and decide to take corrective action, to alert an operator to a potential problem, or to ignore the "problem." In short, the electronics industry has a way to go before production equipment can rely exclusively on the output of machine-vision systems for closed-loop control.