Machine Vision System Options to Verify Print Presence ... Machine Vision for... · Vision...

Machine Vision Consulting

Machine Vision System Options to Verify Print Presence, Characters, and Barcodes Created by Ink-Jet and Laser Marking

Systems Written by:

December 6, 2006

Machine Vision Consulting 7 Old Towne Way

Sturbridge, MA 01518 Contact: Joe Gugliotti

Cell: 978-551-4160 Fax: 508-347-1355

[email protected] www.machinevc.com


Machine Vision Consulting Overview

Machine Vision Consulting is based in Sturbridge, MA, with a lab building in Westborough, MA and is focused on the integration of machine vision technology to provide automated inspection and process control during the manufacturing and packaging processes in a wide variety of industries. MVC is focused on Machine

Vision. • End users come to MVC for complete machine vision solutions.

• Machine builders and automation integrators work with MVC to develop the machine vision portion of their overall assembly, processing, handling, or packaging solution.

• OEM’s of code printers, robotics, and other process systems work with MVC

as an extension of their engineering and sales organizations to design, install, and support vision system options.

As the vision industry has matured with easier-to-use products, one thing remains

the same - vision projects are inherently complex. The development and deployment of a vision system requires an experienced vision engineer who can avoid potential problems that arise when combining high technology from multiple domains (PLC

communications, robotics, vision architecture, real world lighting and optics, motion, human intervention). MVC has some of the most experienced vision engineers in the industry and will get your vision system online and contributing to its ROI quickly. MVC will provide a thorough evaluation of your application, a detailed proposal, and

a complete vision solution per your specifications and system acceptance criteria. Whether the project is a 2-day vision sensor integration or a complex PC-based high resolution, high mix inspection platform with a custom operator interface, Machine

Vision Consulting works with you as a partner and has the experience to provide sound guidance and do it right the first time.

Introduction to Code Verification

This document has been written to provide an overview of the levels of machine vision technology that can be applied to verify characters and 1D/2D barcodes that have been printed on various types of substrates through the use of ink-jet printing

or laser etching. Three primary levels of inspection are used in these applications:

• Presence/Absence of the Code – Did the code get “printed”? Is something there?

• Verification of the Code – Minimal Distortion – Did the system print the expected code string and do the characters and codes meet the required quality threshold as an indicator of legibility and readability?

• Verification of the Code – Variable distortions, curved/flexible

substrates, high speed – Verify alphanumeric codes despite moment-to-

moment variations in the appearance of the characters caused by variations in the substrate, printing on a curved surface, printing on a flexible surface, or other factor. High speed printing. 1D/2D codes may not be readable if highly distorted.


Presence/Absence of Codes Many print verification applications require only that the vision system confirms that

something got printed. In this case, the correctness of the data that was printed and the quality of the print are not as important as knowing that something was printed. This can be done using a very simple vision sensor.

The CognexTM CheckerTM 101 Sensor (see Figure 2) is a very simple, yet powerful single-purpose vision sensor developed to fill the gap between simple fiber optic or proximity sensors and programmable vision sensors. Checker 101 comes complete

with optics, lighting, a USB cable, mounting accessories, and a screwdriver to focus the lens (from the outside of the IP-67 rated case). It is a rugged unit that can keep up with line speeds over 3000 parts per minute.

In order to help eliminate extra sensors to detect the presence of the part, Checker 101 can be self-triggered as the part comes into its field-of-view. It can also accept an external trigger. Checker's 2 outputs can be configured to indicate the part has

been detected, the part passes, or the part fails. A second version of the Checker, the Checker 101E, features an encoder input. This provides the means to count encoder pulses and time the Checker 101E outputs to coincide with the parts being in a specified position on the line, for instance, in front of a reject mechanism, to a

repeatability better than 100 microseconds. A built-in shift register tracks up to 4000 parts on the Checker 101E, potentially eliminating the need for a separate PLC. The vision “sensors” are designed to help determine part or feature presence and

include a Brightness sensor, a Contrast sensor, and a Pattern sensor. Multiple vision sensor tools can be placed on the image as needed. If any of the sensor tools fail, based on the thresholds that are set, the system will fail the part.

Figure 1 – Checker 101 Detects the Presence of the Printed Codes

Verifying the presence of the date/lot code and cap on a milk jug, as shown in Figure 1, presents several challenges, all of which are met by a single Checker. Because the dark print of the code on the light background provides significant contrast, and a

missing code provides little contrast, the Checker contrast sensor easily detects the presence of the inkjet code. Checker is always running and can self-trigger when the bottle comes into view.


Complexity and Cost

A Checker implementation is the easiest and least expensive of all of the vision systems described in this document. Everything is built-in and included with the kit. Set-up time, once mounted, is literally minutes and can be done while a line is in

operation, thanks to the built-in multiple image capture capability. A set-up program runs on a USB-connected PC. Step-by-step instructions are part of the interface. Once set-up is complete, the PC can be removed and the Checker 101 will run continuously, just like a standard non-vision sensor (proximity, contrast, brightness).

The Checker sensors and accessories are in the $2000 price range and include hardware and set-up software.

Figure 2 – Checker 101 Presence/Absence Sensor

Integration costs should be minimal and would include mounting, wiring to an external trigger (if necessary), and wiring the two outputs to any external controls (PLC, reject mechanism). One or two days of integration and testing would be

needed if a systems integrator is brought in to take systems responsibility, at a cost of $1200 to $2400. A number of Checkers could be installed in that time.


Optical Character and 1D/2D Code Verification – Minimal Distortion, Consistent Print Quality

At this application level, the requirements are to verify that the correct alphanumeric characters and 1D/2D codes have been printed and that they meet some minimum quality standard. In terms of the alphanumeric characters, they need to be the intended characters and they need to be legible. Examples include Lot codes, Date

codes, and Product codes that provide important information to consumers, agencies, or distribution networks. In terms of 1D and 2D barcodes, these codes must be readable downstream in the distribution channels so that handheld or fixed

laser or vision-based code readers can reliably read the codes. An important limitation in applying this level of machine vision technology is that the codes, whether alphanumeric or 1D/2D, have a minimal amount of distortion in their

appearance. That is, the printed characters and codes must not deviate much from their intended appearance and shape. Print quality must be consistent.

For these applications, Programmable Vision Sensors, such as the In-SightTM and DVTTM products from CognexTM, generally meet the requirements for automated code verification. Vision sensors are self-contained in that an external PC is not required for operation; the vision processing takes place on the vision sensor itself. A PC

interface is required to run the application development software but, once the application is written and stored on the vision sensor, the PC can be removed, if necessary. The use of the PC online is determined by the customer’s requirements for viewing images, viewing the print errors, viewing defect counts, and providing a

set-up screen for re-positioning vision tools or training printer fonts in a high mix printing environment.

Figure 3 – In-Sight Vision Sensor and DVT Vision Sensor

The vision sensors are compact and have their own discrete I/O capabilities to connect to triggers, PLC’s, lights, and other external devices. The vision sensors are also Ethernet-enabled – they have their own TCP/IP address on a plant floor network

and can be accessed remotely, share information, or transmit inspection data and images to a server or remote PC. This is useful when multiple vision sensors are being used so that they can be upgraded remotely, programmed from a central


location, backed up to a central server, or supported by a systems integrator

remotely through an Internet connection (a very useful capability). Font Training and OCR/OCV Tools

In using vision sensors for Optical Character Verification, it is necessary to pre-train the vision sensor on what all of the possible printed characters look like. Except for OCR-specific fonts, such as OCR-A and SEMI that are pre-trained on the DVT vision sensors, the vision sensors allow multiple examples of each expected character to be

trained, improving the robustness of the application. A statistical model of each character is created and stored in the application program on the vision sensor and referenced each time an OCR (Optical Character Reading) or OCV (Optical Character

Verification) tool is used. Figure 4 shows the In-Sight Font Training Screen.

Figure 4 - In-Sight Font Training Screen. The Selection Shown is the Statistical Model

Created From the Multiple Examples of a “0”.

When applying OCR (the data to be read is not known in advance), the vision tool looks at each character in the printed string and selects, from the stored font training file, which characters it decides are the best shape-matches between the printed

character and the trained models of all of the characters. This is where minimal confusion between the shapes of the characters becomes important. If the character is not formed correctly and does not match any of the trained character shapes, that character will fail the read. It is also possible that the OCR tool makes a decision that


the printed character matches a trained character, but the expected character shape

does not meet the quality level necessary to maintain a high enough level of confidence that a match has been made or the character will be legible and the character fails the read.

When applying OCV (the characters to be verified is known in advance), the vision tools compare the image of each printed character with the trained model of what each expected character is supposed to look like and makes a decision as to the quality of the match. If the shape match quality exceeds a threshold set in advance,

the character passes verification. It is possible that the correct character is presented and detected, but fails to meet the quality threshold for the shape-match score, resulting in a character failure.

When selecting the font to be used on the printer, whether ink-jet or laser, it is important to select a font that has a minimal amount of confusion between similar-looking characters. Potential confusion tends to be higher between characters such

as S and 8, 6 and 8, 3 and 8, 2 and 7, and others, depending on the font. Ideally, an OCR/OCV friendly font should be chosen whose characters have been designed for improved machine readability, such as OCR-A or SEMI. The issue is that, in some

cases, a little bit of extra or missing ink can mean the difference between detecting the correct character and falsely detecting an incorrect character that looks more like the expected character or one of the other trained character models due to a printing issue.

Fonts such as OCR-A, shown in Figure 5, are purposely designed so that each character has a unique appearance even if a portion of the character is missing or obscured. Minimizing character confusion by selecting an appropriate font will greatly

increase system performance and reliability.

ABCDEFGHIJKLMNOPQRSTUVWXYZ

0123456789 Figure 5 – Example of OCR-A Font

Vision Sensor Examples

The following two images show the interface of a DVT vision sensor verifying a Lot and Date code. In verifying characters with a DVT vision sensor, the vision sensor is using an OCR tool to read the code, using the trained character models. The logic in

the interface will compare the characters that are read to the expected character results. If the expected characters are read, the code passes, otherwise it fails. The interface shown is the standard DVT interface. A custom GUI can be developed in

Visual BasicTM. The DVT vision sensors can also be used with a DVT program called SmartLoggerTM to provide the means to build a 21CFR Part 11 compliant code verification system that controls log-in access and tracks program changes.


Figure 6 - The Image Above Shows a Match With The Expected Characters

Figure 7 - The Image Above Shows a Failure to Match With the Expected Characters

– The Characters are Read, But Are Not What Was Expected

The following images show an OCV interface developed with the In-Sight vision sensor. This vision sensor provides for additional customization of the operator interface from within the In-Sight application development environment. The In-

Sight is using an OCV tool to verify that the characters presented are the same as the expected character. If the wrong character is presented, the OCV tool will not determine which character is present, only that is does not match the character that was expected.


Figure 8 - The Characters Match the Expected Characters. A Custom Operator

Interface is Used to Enter the Expected Characters and View the Quality Scores of

Each Character

Figure 9 - The Second Character in the Date Code is Incorrect on the Label.

Note That the Lot Code Portion of the 2D Code Does Not Match What is Expected.

In all of the above cases, the character shapes do not vary enough from the shape of

the trained character models to cause a problem. The character distortion level is low and the printing quality is consistent.


1D/2D Barcode Verification

There are basically two levels of barcode verification:

• Can the printed/etched code be read by a vision sensor?

• Does the printed code meet applicable industry standards for formation and readability?

For 1D barcodes, a laser barcode scanner can be used to simply try to read the

barcode after it has been printed. If it is readable and returns the correct string of data, it was printed properly. 1D barcodes can also be read by a vision sensor. However, adequate image sensor resolution must be used to properly form an image

of the linear barcode – the primary concern is that the thinnest bar in the code must cover at least 3 pixels in the image in order for the vision tool to read the code. Since there is no error correction built into the 1D linear barcodes, the code will not

be read by the vision sensor unless all of the bars can be clearly imaged and are wide enough for the vision tool to detect the on-off transitions across the code. This is especially important if any code quality data is desired. Linear code quality

verification tools are included in the code reading tools on the vision sensors.

UPC Code Code 39 Interleaved 2 of 5

Figure 10 – 1D Linear Code Examples

2D barcodes, such as Data Matrix, require an area scan array on a CCD imager to

acquire the code image and read the code. The vision sensors have tools to read the 2D codes, as well as verify that the codes meet a number of quality standards.

Since most 2D barcodes contain some level of error correction, the fact that the code can be read by the vision sensor does not necessarily mean that the code was printed with a high level of quality. The goal of a 2D code reader is to read the code despite damage, missing information, low contrast, varying code cell size, or other

quality issues. The code may be readable by the vision sensor used on the printing line, but reading problems can occur once the code enters the distribution chain and must be read by a variety of vision sensors and code readers, which can vary in

performance. To ensure that a code is printed to the highest possible level of quality, it may be necessary to verify the code. The goal is to provide any downstream readers in the

chain the opportunity to get the highest possible read rates. When verifying the quality of 1D and 2D codes at the point of printing, it is best to utilize accepted quality standard measurements that are available to evaluate the code. These may include contrast against the background, cell or bar size variations, code geometry,

and the amount of the built-in error correction algorithms that must be used when reading the code. These code verification capabilities are part of the 1D and 2D code


reading tools in the vision sensors and can provide valuable process control

information, detecting changes in code print quality as printing proceeds.

Figure 11 - 2D Data Matrix Code Reading and Reporting of Quality Metrics on an

In-Sight Vision Sensor

Depending on the industry or intended end customer, code quality verification can

become a critical step in the printing process and may be a delivery requirement. These issues become more important in aerospace, military, and medical marking applications. In these industries, very strict published mark quality standards, such

as ISO and IAQG must be met. Complexity and Cost

Using vision sensors requires a higher level of integration and expertise than a simple presence/absence sensor. Optical Character Reading and Verification can be very challenging, especially in an environment where there are uncontrolled or uncontrollable variables in the process used to mark the materials. Even when print

quality is good, this can be a challenging type of vision application. At the hardware level, a number of components are required. Each is listed, along

with the application-specific issues that need to be considered:

• Vision Sensor o Image Resolution o Image Acquisition Speed Required o Expected Variations in Print Quality o Environmental Enclosure o Size – Space Availability

• Optics o Working Distance o Field-of-View

• Optical Filters o Ambient Lighting o Covert Inks o Reflective Surfaces

• Lighting o Strobing Requirements for Moving Parts


o Strobe Speed o Lighting Color – white, red, green, blue, yellow, infrared, ultraviolet o Lighting Shape – Ring, Linear Array, Dome, Spot, On-Axis

• Input/Output o Image Acquisition Trigger o Product Changeover o Online Status of Vision Sensor o PLC Communication o Counting o Strobe Triggering o Reject Mechanism

• PC

o Laptop o Panel Mount o Touch-screen o Environmental Enclosure

On the application development side, there are additional usage issues to consider:

• Data Entry and Set-Up o Codes That Are Expected o Change in Code Position in the Image o Quality Thresholds for characters and barcodes

• Results Reporting o Overlay Graphics o Storing Images of Failures for Later Analysis for Cause o Defect Counts and Part Counts o Code Quality Results – Alphanumeric and 1D/2D Codes

• Secure Log-In • Change Tracking (for 21CFR Part 11)

• Code Types • Font Training Process • Required 1D/2D Code Quality Metrics – IAQG, ISO, AIM • Custom Graphical User Interface Development

The cost to put together a basic solution at this level includes a number of items:

• Hardware and Software (included with vision sensors) - $5,000 to $15,000

• Application Development - $4,000 to $15,000

• System Integration, Installation, Testing, Training - $3,600 to $8,000 The range is approximately $12,000 to $38,000. It’s a wide range that depends on the specific application issues and requirements for the installation. The initial

application development cost may be spread over multiple deployed systems. When the application reaches this level of complexity, it is important to understand

the imaging and printing conditions, the variations in print quality that may be controllable and uncontrollable, and the range of character and code verification applications the system will need to solve in its lifetime. When the preparation is thorough, a project has a better chance of success.


Optical Character and 1D/2D Code Verification – Potential for Character Distortion – High Speed – Variable Orientation of the String of Data At this level of Character Verification, the amount of distortion in the characters is

more severe and varies moment-to-moment. The character strings may also be presented in a random orientation, as when printing on the top of a can. The printed objects may also be moving at high speed. In these cases, a PC-based vision system

is generally required. The vision hardware that is required includes the same items used in a vision sensor-based application, but would use a video camera, whether it is using a FireWireTM,

USB, or Ethernet connection or uses a frame grabber to bring the image into the PC. The frame grabber is a card that sits in the PC and connects to each camera through a standard video or CameraLinkTM connection. The goal is to get the image into PC memory so that the vision software application can then process that image. The

choice may depend on triggering requirements, speed, or other factor. The choice of the image acquisition components is critical and very much application-

specific. They will vary by imager resolution, image acquisition speed, and other factors. However, in the end, the image ends up in the PC’s memory. In terms of solving a high speed application with undistorted characters or codes, the

PC’s processor is many time faster than the processor that’s built into the vision sensors and the application will run faster. The additional image acquisition options available also enable the vision system to grab more images in a shorter amount of

time. Basically, everything will run faster. As we bring character formation variations into the application, the challenge is to interpret what characters have been printed despite variations such as bowing,

skewing, stretching, compressing, or flexing.

Skew Bow Perspective

Figure 12 – Examples of Character Distortion

It is normal for many on-the-fly code printers to suffer random variations in the appearance of their printed characters; there are many process setup variables, such as line speed variations, marking head misalignment, package shape, nozzle

distance, and other factors. Thus, the yield of the vision system used to verify the


accuracy of these critical printed codes is a key contributor to the yield of the line –

how often you get the correct answer, whether it’s Pass or Fail, even when the individual characters or the entire string vary in appearance because of processes one cannot always control.

Many producers are now bright-stocking, whereby they make a standard product, apply product codes to the container directly after manufacture, and send that marked product into the warehouse unlabeled. The product may then be brought back into the labeling line and custom-labeled, based on orders received. It is

essential for consumer safety, especially when isolating allergens, controlling drug interactions, or safeguarding against spoilage, that the contents of the can and the label being applied match up properly. Thus, not only is code verification required

after the printing process, it is required before the labeling process when containers are brought to the labeling line from the warehouse. At this point, the containers, such as a can with a code printed on its top, may no longer be oriented the same way as when the code was printed and originally verified, in addition to having

potentially distorted codes.

Figure 13 – Codes Printed on Can Top

In addition to characters that are distorted, incorrect characters may be present. If an incorrect code is being printed and the printing error is not detected quickly, the loss can be substantial, perhaps an hour or two of production that must be destroyed because its history cannot be verified. Once a product is marked incorrectly, it

generally has to be destroyed, as its pedigree can no longer be guaranteed. Given all of the issues just mentioned, the machine vision software that is used to verify these difficult codes becomes the critical component of a code verification

solution. If a character is so distorted that it is unreadable, the code needs to be rejected. However, an acceptable level of character distortion must be tolerated in this type of application to minimize false rejects and maintain the yield of the line.

Font Training

At the vision sensor level of OCV solutions, the characters of the font being used are

trained by taking images of every character and building up a statistical model of each one. In the situation where the characters exhibit moment-to-moment variations, image-based font training would be a never-ending process. At this


application level, the best way to train a font is to use the electronic version of the

font that the printer uses. A TrueTypeTM font is an example of an electronic font file. Most ink-jet and laser printing systems are utilizing an electronic font description file and a vision system can use the same type of file to train the character models. Thus, font training involves selecting a font file to import into the vision system. The

selection of the font should still be done with consideration of minimizing character confusion. Dealing With Character Distortion

An advanced vision tool from CognexTM, called PatFlexTM, forms the foundation for an Optical Character Verification tool called FlexOCVTM. PatFlex can basically un-warp an

image such that it appears relatively normal and can be operated upon by PC-based OCV tools. In the example below, PatFlex technology is used to un-warp characters so that they can be verified.

Figure 14 – How Advanced Vision Technology Corrects for Print Distortion

The electronic font file characters are represented by the Trained String. The vision system is verifying that the expected characters are present, so it understands what the characters should look like in the image. In taking the input image into the

software, the vision tools match the shapes as closely as possible, then determine how the features in the character image correspond with the features in the character models. Once the Warped Pose is understood by the software, an image

transform is run to bring the character shapes as closely as possible to the Trained String shapes. The un-warped character images may not be perfect, but Flex technology brings the printed character shapes much closer to those of the models and makes a previously un-readable string verifiable.


The images below show a series of warped character strings. The blue grid pattern is

the deformation grid and provides a graphical representation of how the FlexOCV tool perceives the overall distortion of the character string in the run-time image.

Figure 15 – Representation of Print Warp

Standard OCV tools cannot easily deal with characters that do not look almost identical to the trained models. Bowing, skewing, and size variations are going to bring the reliability of a vision sensor-based OCV system to an unacceptable level, especially when a false accept can lead to a dangerous situation for the consumer,

such as mislabeling dairy as soy or clam chowder as cream of mushroom. The PC vision tools can also include 1D and 2D code reading tools. Distorted

barcodes cannot be read because they cannot be un-warped. However, well-formed


1D and 2D codes can be read on PC-based vision systems given sufficient image

resolution. Complexity and Cost

As with the vision sensor systems, the camera resolution, lighting, optics, and I/O issues are the same. Enough resolution is needed so that the character shapes and barcodes can be understood by the vision software. The lighting design needs to deal with the substrate conditions that contribute to the difficulty in character printing,

such as curved surfaces, flexible surfaces, and can ends with ridges that cause reflections.

While the PC is optionally installed with vision sensors, it is a required component at this level of the technology and likely needs the most processing power available. It is not unusual to require a multi-CPU computer, including multiple dual core processors and a lot of RAM.

At high speeds, triggering, timing, execution time, and precise I/O are essential. The Operator Interface features need to be determined, image storage and display may

be required, and 21CFR Part 11 compliance may be required for medical applications and food processing. The proper font files need to available from the printer manufacturer so that they

can be imported into the software. This makes font training much easier, but the level of difficulty of developing this level of the technology requires a high level of expertise in image acquisition, optics, lighting, and higher language computer programming (C++, .NETTM, Visual BasicTM). An experienced machine vision systems

integrator is required. In terms of costs, they may break down as follows:

Vision Hardware $15,000 to $25,000 Includes: Core Vision Tools, Camera, Optics, Lighting

Frame Grabber, I/O, PC, Trigger sensor Optional Vision Software (OCV, FlexOCV, Barcode) $3,000 to $6,000

Application Development $12,000 to $24,000 System Integration, Installation, Testing, Training $6,000 to $12,000

The range is approximately $36,000 to $67,000. Again, this is a very wide range and it will be critical to put together a clear specification as to what is required of the machine vision system in order to develop an appropriate quotation. High resolution

cameras, specialized lighting, and high power PC’s will drive the price toward the high end of the hardware range. Custom operator interfaces, complex multi-line codes, random code orientations, and severe distortion will drive the cost of the

application development toward the higher end of the range. PLC programming, extended testing, and involved integration issues will drive the implementation costs toward the high end of the integration range.


Conclusions The price ranges shown in this document are estimates based on past experience.

The actual final price of a project is based on a very wide range of application-specific issues and requirements. The capabilities discussed at the basic levels of machine vision technology applicable

to reading and verifying codes are based on the general requirements for simple presence/absence and verifying and reading well-formed codes. More capability is required when verifying and reading codes that can vary unpredictably on the

production line. These variations may be due to variables in the printing process, the material handling systems, the process at which the codes are being verified, and the substrate on which the code is being printed.

The simple presence/absence applications that can utilize a Checker should be easily integrated by a technician. Vision experience is nice to have, but not required at this level if the technician is familiar with general purpose sensors. Systems integrators

can also be used if systems responsibility is required. Once the code verification application requires a vision sensor or higher level machine vision system, an experience vision systems integrator should be brought in

as early in the specification development process as possible. It is very helpful to have a vision engineer’s input when trying to figure out the code verification and inspection requirements.

Code verification is not a simple vision application. It may appear that way, but it is one of the more complex types of vision projects. Understanding the way codes are printed, how consistent the printing process is, and the level of print verification that

is required will lead the customer toward one of the three technology levels discuss here. Proper preparation and the development of a clear specification and system acceptance criteria will make any project run smoother.

About the Author:

Joe Gugliotti is responsible for Sales & Marketing at Machine Vision Consulting and

has been a part of the machine vision industry for 21 years. He spent 10 years with a leading distributor of cameras, optics, and lighting systems for use in machine vision applications, working closely with Vision OEM’s, Systems Integrators, and End Users across the U.S. to evaluate their image formation needs and provide the

appropriate solution. Joe spent the next 10 years as an OEM Account Manager and Senior Sales Engineer for a leading Machine Vision OEM, gaining exposure to hundreds of applications across a wide range of industries and using vision

technology ranging from simple sensors to advanced PC-based systems and custom cutting-edge solutions. In his position at MVC, Joe applies all of this experience to providing full machine vision solutions and consulting services.

Machine Vision System Options to Verify Print Presence ... Machine Vision for... · Vision...

Documents

Transcript of Machine Vision System Options to Verify Print Presence ... Machine Vision for... · Vision...