A common environment simplifies application development

One reason for the high cost is that vendors do not settle on a common development environment for vision applications. A vendor might use a simple environment for an application involving a single smart camera and then turn to a hard-to-use, cross-development environment for programming embedded vision processor boards. By using a single development environment for all their systems, vendors could reduce costs and make it easier for customers to learn new applications.

Fig. 1  Machine-vision systems can be configured in various ways.

• fully integrated smart cameras with onboard imaging and processing;
• stand-alone vision systems with an onboard processor and onboard image-acquisition hardware connected to conventional cameras;
• digital cameras—without onboard processors—connected to a host PC through a high-speed communications link such as FireWire, USB, or Gigabit Ethernet;
• frame-grabber boards that acquire images from conventional cameras and transfer them to a host PC for processing;
• intelligent frame-grabber boards with onboard memory and some hardware acceleration that can be used for low-level image-processing functions; or
• vision processor boards with onboard embedded CPUs and frame grabbers that acquire and process images from conventional cameras. These embedded boards function as stand-alone vision systems plugged into a PC or other backplane, using the host bus and CPU for power and for user-interface functions.

Windows PCs generally serve as hosts for programming machine-vision systems and monitoring factory applications in real time. In some cases, the vision software itself runs remotely on the PC.

By using a common development environment for all types of configurations, vendors would allow users to take advantage of prior training and previously developed applications. This approach would also help the vendors themselves prepare for new configurations as they arise.

Using a single architecture has many advantages:

• It makes it easier for programmers to develop applications for various systems.
• It reduces overall development time and costs. Language-independent software components provide drop-in functionality, so developers can add new machine-vision operations and user interfaces to a system as they become necessary.
• It makes it easier to develop a common user interface for all applications.
• It allows the identical appearance of inspection components from the users' perspective, regardless of the particular CPU or available image-processing acceleration hardware. The common user interface would train the system and set parameters, which would then execute through a routine library native to the platform on which the system is loaded.

A machine-vision application can be set up to run in various ways. The program can run on a stand-alone target such as a smart camera or other vision system connected to a host over a network. It can also execute on a vision-processor board that plugs into the host computer's peripheral extension bus or on the host itself where a vision board plugged into the host's extension bus provides image acquisition and accelerated image processing.

When developing a new vision application, a programmer must

• set up a new job on the PC that will drive the system;
• try out the job (which consists of several steps), edit it, and save it directly on the PC;
• download the step program and run it on the target device, ideally without any recompilation. A run-time monitoring interface on the host PC starts, stops, and monitors the running jobs.

Any machine-vision application must extract feature information from the objects in an image. (A feature can be any data that describes parts and objects, such as size, area, length, or position.) The machine-vision system can then use this data to classify the object and make a pass-fail decision.

Fig. 2  In a typical machine-vision application, a camera acquires an image and places it in memory.

From the features, the system segments the image into one or more distinct objects by identifying their boundaries. It then checks those objects against tolerances or classifies them into categories before obtaining results and making a pass-fail decision. For any particular feature, external control inputs may enable the tolerance check and provide nominal values during the inspection step.

Fig. 3  A step program implements a simple application involving the reading of a Data Matrix code marked on a PCB, detecting the location of the board’s edge, and verifying the presence of a round feature at a specific point with respect to the edge.

• contain the list of operations that make up the application;
• encode the parameters and settings required to execute each such operation successfully;
• define the inputs that a step accepts for each operation and the resulting outputs;
• detect whether an operation needs to be set up or trained by the system's human operator;
• invoke the required common user interface components to help an operator set up and train step programs regardless of the GUI environment on which the step program is loaded.
• construct an executable program that runs on the host PC or directly on a vision target board; this executable program could detect the availability of hardware acceleration and decide whether to use it in real time; and
• allow an application to assign labels from an expression, spreadsheet, or script to each operation as well as to inputs, outputs, settings, and parameters.

The ultimate goal is to improve inspection efficiency at each step, while reducing redundancy, lowering the learning curve, and reducing costs. The concept of a common application-development environment is not new. Still, many machine-vision users must cope with a hodgepodge of environments that waste time and money. The model here demonstrates how to implement the common approach in your own operation, offering users efficiency, economy, and effectiveness.