Machine Vision News
Vol. 11, 2006
Vision Club of Finland
Previous
Index
Next

More than just libraries

A defining factor in comparing different machine vision software packages nowadays is not he speed or accuracy of the algorithms, but rather the ease of use the packages can deliver. Most leading packages today provide pproximately the same number and complexity of algorithms, the variation is in how easily the algorithms can be used, and how the resultsare communicated. Every machine vision system must do three things: acquire images, process images, and ommunicate results. The leading vision software packages available today will most likely support the camera that fits the application. Furthermore, these top vision software packages feature very similar algorithms for processing images, such as pattern matching, particle analysis, OCR, and 2-D barcode readers.


Image 1. The presence of an O-ring is verified.
Photo: National Instruments

Ease of Use

Because most top vision software packages feature similar algorithms, the real technical difference is how easily and quickly an inspection routine can be developed and implemented. Easy-to-use vision software usually contains three components: an application prototyping environment, automatic code generation, and an intuitive, graphical programming interface. The prototyping environments are usually menu-driven interfaces where the user can test different analysis scenarios on images before building code. With these prototyping environments, users can emphasize certain image features with filters, try out different imaging functions for the application, as well as set parameters for the functions, to create a script of the exact steps necessary to properly analyze the image. For example, in an oil filter inspection, where the goal is to identify the oil filter by the number of holes around the center, verify that an Oring is present, and communicate the results to other industrial devices, the prototype of the inspection routine has three basic steps. These are to find the center hole with a pattern match, count the number of smaller holes using particle analysis, and verify the presence of the O-ring by checking the intensity along an annulus. (see Image 1) After developing a script that correctly analyzes the images, prototyping environments should tell the time it takes to run the script. This information is extremely valuable if the inspection has to finish in a certain amount of time. In the oil filter inspection example, it takes 53.5 milliseconds (ms) to complete (see Image 2): 12.3 ms to find the center with a pattern match, 11.9 ms to count the surrounding holes with particle analysis, and 8.2 seconds to quantify the intensity of the O-ring pixels. The remaining 21 ms were to open the oil filter image from file. Now that the inspection has been prototyped, and the user knows that the routine will finish in the required time period, the user will need to migrate the inspection from the prototyping environment to a programming. The best prototyping environments make this transition easy by automatically generating ready-to-run code for C/C++, Visual Basic, and NI LabVIEW for users can to insert into a larger application or run on its own.


Image 2. The prototyping software displays the amount of time it takes to perform the inspection.
Photo: National Instruments

Graphical Programming

While prototyping environments and code generation greatly simplify the development of machine-vision applications, the greatest technology for simplifying development is graphical programming. Software such as LabVIEW can be used to program vision applications by wiring function icons together and creating custom user interfaces. This type of graphical programming allows engineers and scientists to program vision applications in a shorter period of time by working with flowcharts and block diagrams rather than text-based function calls and semicolons (see Image 3)

External Communication

It is important to consider the big picture of automation when designing a vision system. For example, machine vision systems may need to power actuators to sort products and remove defective parts; communicate with PLCs and PACs to close control loops; guide motion systems and robots; and integrate with enterprise data-bases and SCADA systems to monitor trends and store statistics. To greatly simplify this process, some software programs feature tools to help develop and integrate distributed systems. Projects can manage and synchronize the processing and communication between many distributed systems, like programmable automation controllers (PACs), motion controllers, embedded vision systems, operator interfaces (HMIs), and SCADA systems. To accomplish this, programs should have methods of sharing parameters over the different platforms. An example of such in LabVIEW is a feature called “shared variable engine” that abstracts the management and control of different distributed systems across industrial buses and protocols, such as OPC, Modbus, and even deterministic Ethernet. In terms of the oil-filter inspection program, it is likely that the results of the inspection will need to be communicated to other automation devices. For instance, when a defective oil filter is found, the system will need to reject the defective item off of the line with either a blast of compressed air or a solenoid. Because of the visual nature of the applications, operator interfaces play an important role. To successfully inspect the oil filters, operators need to view the inspections in real-time to know if they need to adjust set points for changed lighting or choose a new inspection to run when the line changes to produce a different product. Finally, every successful manufacturer tracks quality statistics and trends. They can use inspection results (beyond just pass or fail) from vision systems in these calculations. However, they may face the challenge of incorporating vision data into larger SCADA systems and enterprise software. Software such as LabVIEW 8 contains the tools for communicating SQL databases and enterprise software to route data to servers and databases. In general, vision software is a lot more than just a collection of image processing libraries. Without tools to ease programming and communication, users may find Image 1. The presence of an O-ring is verified. Photo: National Instruments that the powerful vision algorithms that come with some software packages are useless. When choosing between vision software packages, look beyond the list of algorithms to figure out how easy it is to develop an inspection and communicate the results to existing equipment. By starting with the right software, it may come as a surprise how easily and quickly a machine-vision application can be developed.




Image 3. Engineers can use LabVIEW graphical development instead of text-based language to save development time.
Photo: National Instruments


Contact Information:

Kyle Voosen
Vision Product Manager fo
National Instruments (Austin, TX)
Kyle.Voosen@ni.com
www.ni.com/labview

Previous
Index
Next