Reading time ( words)
By Chris Brais
While RS170 or charge-coupled/infrared (CCIR) cameras are common, the need for more detail and faster acquisition rates is rapidly driving frame grabbers in the direction of higher resolution, progressive-scan cameras.
The "frame grabber" features required for machine-vision-assisted printed circuit board (PCB) assembly differ significantly from those of multimedia, medical and most military applications. One of the more common machine-vision tasks is to provide an image for a host-computer memory where it can be analyzed before a decision is made. For example, with PCBs moving down an assembly line, a part passing a sensor prompts an image to be taken. A computer-based algorithm then determines the part's correct alignment and its quality. Inspection rate, algorithm details and physical constraints will often determine the speed, resolution, and type of camera and optics required.Camera SelectionCurrently, most machine-vision solutions are implemented via analog cameras. While digital-output cameras are available and may give better signal-to-noise results, the benefits are not often cost-justified. With few exceptions, a machine-vision application will require an A/D converter capable of conversion rates of at least, and usually faster than, those of the RS170 (10 MHz).
Camera control. A minimum requirement is accurate analog/digital circuitry and either a very good phase-locked loop (PLL) or the ability to provide a clock to drive camera timing. Without these features, the fidelity of the acquired image will be in question while both quantitative and qualitative applications are compromised. As for control, most applications require an image be acquired via an external event, i.e., a trigger. While many frame grabbers provide this capability, others cannot issue a strobe signal through a trigger. (If they do, there may be no way to adjust or delay the strobe pulse relative to the trigger event.) The ability to time the strobe to the trigger pulse can vastly improve lighting on the subject.
For many vision applications, a frame-reset-capable camera is required to permit its timing to be interrupted and reset at any point, guaranteeing instant return to the top of the frame and acquisition of the image immediately on receipt of the external event. Without this feature, a delay occurs between the trigger signal and when the camera acquires and provides data to the frame grabber. Worse, the delay will be variable because the timing is unsynchronized. For interlaced RS170 signals, such delays can vary from almost 0 to an entire frame (33 milliseconds).
Input signal conditioning, such as the ability to control gain and offset, are important for minimizing the effects of camera variability, lighting fluctuations and to provide the best camera signal to the A/D converter. A lookup table is frequently used at the input to modify the data for easier signal processing or better display capabilities.
Processing the DataBecause many applications require the host computer to control several devices and manage multiple events, there has been a trend toward multitasking, interrupt-driven software. A frame grabber and software capable of running in an operating system such as Windows NT and using interrupts and multiple threads are desirable.
Often, to lower manufacturing costs, frame-grabber suppliers will not put much, if any, memory on the unit itself. These "memoryless" systems rely on the speed of the PCI bus to perform line-by-line transfers of the acquired data to the host memory. While this method works and, in some cases, achieves real-time or close to real-time capture rates, the drawback does not become apparent until viewed in the context of a machine-vision system. These systems are not just acquiring an image for display; rather, they are multitasking, i.e., reacting to interrupts, processing I/O and analyzing acquired data. With memoryless frame grabbers, the real "cost" is in the increased load to the central processing unit the host CPU is "busy" handling the line-by-line data transfer and may not be available for the required processing.
The SoftwareWhen considering software, the machine-vision developer first must assess the extent of the software-integration task he is willing to assume. The choice of writing a custom algorithm or using an off-the-shelf package will depend on the custom nature of the application and the time constraints of the project. In general, using software packages written specifically for machine vision not only speeds the completion of the project, it usually results in a more reliable solution.
One of the more common bottlenecks in this process is the integration of the host-based software with the frame grabber. Strong attention should be directed at the maturity of the interface between the frame grabber's software and the image-processing package under consideration. Many grabber manufacturers' software packages are underwritten and require common machine-vision functions to be written by the end user. At a minimum, basic software functionalities should include methods for achieving triggering, strobing, frame reset, data transfer to host, image display and a way to dynamically tweak the camera interface. These features are invaluable when first setting up an image-acquisition system.
Once the image is acquired and delivered to the host memory, the task of actually solving the machine-vision problem begins. Here, access to a powerful image-processing library designed for machine vision (vs. medical or general-purpose image analysis) can greatly improve performance and decrease development costs.
ConclusionMany machine-vision frame grabbers are available but support different intended applications. It is important to understand the actual demands that the machine-vision process makes on both the host computer and the imbedded frame grabber; selection of the wrong board could result in project failure.
Questions to ask:
1. Review the camera requirements. Can the frame grabber handle them? Must the camera interface be developed, or does the manufacturer deliver a ready-to-go plug-and-play interface?
2. Consider the quality of the digitization. Will "noise" obscure or make the measurement unreliable? "Multimedia" boards typically fall into this category.
3. Will the following be needed?
- Frame reset
- PLL acquisition
- Timing to the camera
- Input-signal conditioning.
4. What demands will be made on the CPU for processing? Will the frame grabber "steal" too many CPU cycles?
5. Check the maturity of the software and its compatibility with other machine-vision products. Are algorithms for the application available, or must they be written "in house"?
Once the real demands of machine vision are understood, quality frame grabbers are available.
CHRIS BRAIS is manager of application engineering for Imaging Technology Inc., 55 Middlesex Turnpike, Bedford, MA 01730; (781) 275-2700; Fax: (781) 275-9590; E-mail: firstname.lastname@example.org; Web site: www.imaging.com.