Automating & Educating the World’s Leading Companies

Abstract:

A LabVIEW Test Executive program was created that can load specific vision inspection algorithms developed using VBAI 2010 to perform various inspections of device features. The system was designed for flexible inspection configuration allowing use of any VBAI inspection file with any of the system’s eight camera images.

From Humble Beginnings

An unstable legacy vision inspection system that only performed a single inspection for label presence and correct characters through Optical Character Recognition (OCR) had to be replaced with a more robust system. The legacy system utilized “smart” cameras to store the desired inspection, but the inspection would have to be uploaded to match the desired unit selected for testing. This often caused the system to lock up due to memory management issues with the cameras. Since multiple devices with distinct inspection criteria could be put through the system, this was not an ideal solution. The lighting for this legacy system was also highly problematic and the inspection area was open to shop lighting that could change if light fixtures had bulb outages.

Let There Be (Stable) Light!

In order to be able to inspect 5 sides of a cube, adequate light is required. For the vision inspection algorithms to perform in a repeatable manner, the lighting of the product must be repeatable, abundant and uniform. To meet this requirement, two large LED light panels were fixed at angles above the parts to be inspected (Figure 1). These lights were oversized past the end of the parts to allow for lighting of the ends of the devices. This configuration mimics the lighting supplied by a dome light without restricting access of the part loading path.

Figure 1 -

Inspection Box Diagram

I Need More Power!

One of the key complaints regarding inspections using the legacy system was the need to use fixed Regions of Interest (ROI). Due to hand placement of labels on the DUT these ROIs would oftentimes needed to be adjusted. With the inspections running on 10 year old “smart” cameras, it was not feasible to set up the inspections to be dynamic based on feature detection.

The ability to dynamically set the ROI for each inspection is exactly what was gained in moving to a high-performance dual core PC as the main test system backbone. VBAI provided the ability to construct very robust inspection algorithms for such things as locating a bar code label, setting the ROI for reading the 1-D barcode, and providing the results of the bar code reading. The built-in inspection components within VBAI made configuring these inspections much less time consuming. Being able to dynamically locate ROIs made the inspection algorithms much more adaptable for inspecting similar features on other faces of the DUT. This removed the need to have dedicated inspections tied to a particular camera and style of device. Reducing the number of inspections makes the system administrator’s job much easier.

Vision Executive for Production Test

The main application created using LabVIEW 2010 is the Vision Executive for Production Test or VExPrT for short. This system handles operator login, test recipe selection based on bar code scanning of product style, and vision inspection results review through pop-up inspection result dialog boxes that show the actual images acquired and the results of the individual VBAI inspection algorithm steps. See Figure 2.

Figure 2 - VExPrT UI

Basically VExPrT selects a text file that outlines which VBAI inspection is to be used to analyze an assigned camera image. This allows the VExPrT system to be reused for practically any type of vision inspection system. The architecture put in place also allows for technicians to easily create their own VBAI inspections that run in VExPrT without any modification of the main architecture. It does not even need to be used with the lighting and cameras configured in this particular system – the combination of using LabVIEW and VBAI allows for a truly adaptivescalable vision inspection architecture.

The new VBAI API in LabVIEW 2010, is what makes VExPrT possible. VBAI itself contains an Inspection Interface to
serve as a GUI, but it is intended for basic GUIs. Using the VBAI API in LabVIEW provides the capability to develop a
more complex LabVIEW application with the power of VBAI built into it.

VExPrT Interface

The first screen that the user sees in the VExPrT system is the operator log-in screen. This login screen checks the system
database for operator privilege level – either operator or administrator. Once the operator is logged into the system, they are asked to select the particular style of product that they wish to inspect.

This product style is then used to query the system database to look up the appropriate inspection configuration file that
details which VBAI inspection is to be run with the associated system camera. See Figure 3 for an example of the inspection recipe configuration file.

Figure 3 – Product Scan & Inspection INI File

VExPrT then acquires images from all 8 cameras using LabVIEW and passes the necessary image to the associated VBAI
inspections for analysis.

The main screen shows a list of inspections that are being run and the results of the individual steps, whether it is passed orfailed. After the inspection has been completed, the operator can click on an individual step to inspect the specific imageused for the inspection and the VBAI step results. See Figure 4. This feature allows operators to visually verify if the inspection failed due to a missing feature or if the algorithm provided a false failure.

Figure 4 – Inspection Review GUI

The individual test inspection screen will allow the administrator to visually verify if a test should be passed and override if necessary. Individual step and overall test results are stored into a database to allow for reporting and tracking of any VBAI inspections that might need to be made more robust. This also solves a problem that the legacy inspection system had.

Namely, the legacy system required that the inspection be adjusted to make it pass even if the administrator could visually verify that the test should have passed. This new VExPrT inspection and override will save time on the production line by moving this algorithm adjusting offline.

Ready for the Future

If a new device that has not been configured for inspection is placed into the system the operator will be alerted that an inspection recipe does not exist. The operator is then presented with the option to acquire images from the eight system cameras and save them to a central network location to allow the vision inspection experts to test the currently existing inspections against the new device feature or create new VBAI inspections based on actual system images.

Summary

The project’s success is due to the synergy designed into LabVIEW and Vision Builder for Automated Inspection. The VBAI API allowed for development of a flexible, adaptive and powerful vision inspection solution in weeks, for what otherwise would have taken months. Data Science Automation was easily able to build a scalable vision inspection system that can be applied to almost any product line.