Machine-Vision Software: It's Not Just for Experts

Help is at hand. Many companies now offer PC-based software that makes it fairly easy to tackle machine-vision applications. In most cases, you won’t have to do any coding, and you can have prototype software running in a few hours. But to properly apply machine-vision software, you must carefully analyze the inspection problems you need to solve. And the first steps have nothing to do with software.

The best way to start is by meeting with all the people who need the information your inspection system will provide. (The system includes the camera, frame grabber, lights, PC, and software.) Most often these people work in production and quality-control departments, but their needs for inspection information aren’t always the same. The production people aim to ship as many products as they can, so they may accept some products that the QC people would reject, based on the same inspection data. Why acquire and process data on line if the production people don’t need it and the QC people only need it later in the process?

To determine the most pressing inspection needs, have the QC and production staffs meet and draft a list of the things they need to inspect for. Then have the group assign priorities to every item on the list. The group should assign its priorities based on how each inspection operation will help the company produce good products.

Chart Your Priorities
When you have a list in priority order, make up a Pareto chart (Fig. 1) that shows which inspection operations will have the greatest effect on production.1 After the key production and QC people agree on priorities, you can determine what the machine-vision software should do. You will know, for example, that proper connector-lead spacings are more important to production than is the position of a bar-code label. In this case, the need for gauging has a higher priority than absolute-position measurement. When you seek information about machine-vision software, you’ll know to look for a variety of gauging operations.

Keep in mind that machine-vision software needs time to perform each operation. So, if you have a production line that produces one product per second, the software must accomplish all its tasks in under 1000 ms. There’s no rule of thumb for the speed of a processing task. You’ll have to try your application and see how fast it runs on a PC. If you must reduce the number of inspection tasks the PC can perform, the prioritized list can serve as a guide.

At the same time you’re evaluating what and how to inspect, you also need to determine what actions will take place as the result of an inspection. The application software should control signals that cause actions to take place, and it should produce statistical information. The "action information" signals the production line or a technician how to handle an inspected product. The choices might include "pass a good product to the next stage of production," "move a failed product to a rework bin," "discard a ruined product," and so on.

Software Can Control I/O Ports
If you want your application to control external devices, be sure that the supplier spells out what sort of external control its machine-vision software provides. At the least, the software should let an application program control digital outputs and read digital inputs, which suffice for most applications. The digital-output signals can control a programmable logic controller (PLC), motors, actuators, and positioners. Digital-input signals can let the software determine the state of an external device or mechanism. Machine-vision software suppliers may specify whether the software works with specific digital I/O boards or with the parallel (printer) port on a PC.

The machine-vision software also should provide statistical information that describes the failures it detects. Instead of simply indicating that a product failed an inspection, this information can indicate to operators that a production line needs adjustment, that components are out of spec, and so on. Managers and QC people may rely on such information to tell them how many defects occur, what defects occur, and why they occur.

Machine-vision software should furnish defect information in formats that easily mesh with existing applications such as databases and spreadsheets. Most software will transmit detailed inspection information through a PC’s serial port. But you might also want to look for the option to control a network interface card (NIC) if you need to communicate with another computer at high speed over a LAN.

All-In-One or Libraries?
Now that you know what you want to inspect for and what the inspection results should tell you, it’s time to choose a software path. You have two main choices: Buy a library, or collection, of machine-vision functions written for a language such as C, C++, or Visual Basic (VB), or buy an integrated development package. The first choice appeals to system integrators, OEMs, and software developers who know a great deal about machine vision.

Think of this approach as buying a set of tools with individual instructions for each tool, but without instructions on how to use them together. Unless you’re a very good programmer and already good at machine vision, I don’t recommend taking this route.

The second choice—an integrated development package—fills the needs of people who want to solve machine-vision problems but who aren’t expect programmers and who don’t want to master machine-vision algorithms. Several vendors offer integrated development packages that provide a simple-to-use graphical user interface (GUI) . The GUI makes it easy to link operations such as "acquire image," "determine threshold," "read bar code," and so on to create a working prototype or application (Fig. 2).

The ability to connect the operations and rearrange them as needed makes it easy to test operations and sequences. Unlike functions in libraries, the steps in an integrated package don’t require you to keep track of pointers, arrays, and parameters that get passed back and forth.

Even within the integrated development package category, software packages offer different features. For example, Data Translation’s NeuroCheck software provides a "wizard" that guides you through an application, step by step. You can use the resulting sequence of steps for prototyping or in your application. National Instrument’s IMAQ Vision Builder also provides a stepwise setup for rapid prototyping. After testing the prototype software, you use the "builder file" to integrate your application into the company’s LabView program, or Visual C/C++ or Visual Basic, from which the application runs.

Link Programs to Other Software
Most machine-vision software lets external ActiveX controls, dynamic link libraries (DLL), and VB programs work with your application. This flexibility lets you extend a machine-vision application by adding bits and pieces of software that don’t come with the development package. You might choose to use VB to provide an operator interface for your machine-vision application (Fig. 3). Or you might decide to move data from a machine-vision application into an Excel spreadsheet. You could write or purchase a VB routine to perform this function.

The best way to learn how these packages work is to obtain demonstration programs from their manufacturers. The demonstration programs let you run the software and see how the image-processing operations work. The demo software may prevent you from saving an image or performing some other operation. You cannot use the demo software in a real application.

You can run the demo software without first having to learn how all the processing operations work. Most people can’t describe how a fast Fourier transform works, but they know it will reliably convert their time-domain data into the frequency domain. So it is with machine-vision algorithms. You’ll learn how the processing steps operate by trying them on test images and seeing the results. Take time to try a variety of the types of operations you think you need. The best way to learn about individual operations is to try them alone and in combination with other operations. If you want more details about how the algorithms work and what they do, several books provide this information (see, "For Further Reading," Below).

Start with Test Images
Because you’re still evaluating software, you may not have a camera and frame grabber set up to supply test images. So, start experimenting with images that the software vendor supplies, or obtain test images from several Web sites using links at www.vision1.com/imagedb.html

You won’t find the most efficient combination of image-processing steps that solve a particular problem right away. Be prepared to spend several hours getting used to the software and running experiments. Manuals and help files should provide sufficient information to get you started putting together rudimentary step-by-step programs.

After spending time getting used to the software, you should set up your camera and lights properly to obtain images of the product undergoing inspection. You can acquire images of your product and test the software routines that find defects, locate positions of missing components, and perform other tasks. After the application works well, test the software under more realistic conditions.

As products move along a production line, they won’t always move to exactly the same position in the inspection station. Slightly vary the position of the product you’re inspecting to be sure that application software will still locate objects of interest and process the images properly.

You may have set up your camera so the image of a product completely fills the display area in at least one dimension. If so, you may need to adjust the camera’s position so it doesn’t clip the edges or corners of a slightly out-of-position product in the final image.

The way you have structured your application software may prevent it from handling a product that shifts position slightly from image to image. In this case, first have the software locate a specific point, perhaps a fiducial mark, and then reference the other measurements to it. Keep in mind that these steps take computer time.

As you move a product along your simulated production line and test both good and bad products, remember that variations in components will show up, too. A supplier may switch from a white connector body to a green body, or a new batch of the product may use a yellow bar-code label instead of a pink one. The image-processing routines should take such changes into account. If they do not, try using other routines to account for expected image changes. If you had used libraries of functions in a C or C++ program, making such changes would prove more difficult than changing a few links to routines in an integrated-development package.

No matter what machine-vision program you use to develop application software, the inspection system should present an operator with a simple interface (Fig. 4). An interface could provide go/no-go indicators, a production-status indicator, QC statistics, an image of the part undergoing inspection, and other information. The software you purchase should provide the means to set up such a visual display of information separate from the screens you use for development work. Visual Basic provides an easy way to set up such operator displays, so no matter which package you choose, you could use VB for this purpose and link it to your application software.

FOOTNOTES
1. Gregory, Rob, "Know Your Machine-Vision Components," Test & Measurement World. March 1999, pp. 47–52.
2. Masi, C.G., "Lighting Makes Its Mark on Vision Systems," Test & Measurement World. May 1998, pp. 11–14.
3. VanDommelen, Carl H., "Choose the Right Lighting for Inspection," Test & Measurement World. October 1996, pp. 53–58.

FOR FURTHER READING
Baxes, Gregory A., Digital Image Processing, John Wiley & Sons, New York, NY. 1994.

Jain, Ramesh, Rangachar Kasturi, and Brian G. Schunch, Machine Vision, McGraw-Hill, New York, NY. 1995.

Myler, Harley R., and Arthur R. Weeks, Computer Imaging Recipes in C, Prentice Hall, Upper Saddle River, NJ. 1992.

Russ, John C, editor, et al., Image Processing Handbook, second edition, CRC Press, Ann Arbor, MI. 1995.