Last week at LabelExpo Americas, I saw more emphasis on inline verifiers than I have seen in the past. I am skeptical about its effectiveness. Surely there are circumstances where 100% automated, unattended verification is helpful.  However, I am skeptical that the trade-off of accuracy for convenience is a good business decision in most cases. Yes, we have the technology, but how many companies actually need it? I think it is being oversold.

There is concern about how well it does what it purports to do. GS1 aptly makes the case that verification should occur when the barcode is in its final form. By that they mean all post-production processes and variables are in place: product is in the package, shrink wrap or laminate is on the barcode, etc. Whizzing past a scanner with a strobe at high speed is not exactly “final form”. Nor is it compliant with the ISO spec, which calls for 660-680 nanometer light—not white light. At the very least, these systems must be carefully configured to emulate fixed angle and distance if they have any hope of capturing and grading reflectivity and contrast. Most inline verifiers do not do that.

Inline verifiers fail verification protocol in other ways too. Illumination is usually only on two sides—not four as required by the ISO specification. There are other failures as well:

• Apertures defaulted to 50% of X
• Calibration card (if supplied) not NIST traceable or available only at additional cost
• No option to generate ISO verification report (single scans or batch)
• Non-repeatable results, especially “Contrast Uniformity”
• Sensitivity to ambient lighting

None of the high speed inline verifiers that I saw are based on true verifiers—they are all adaptations of machine vision systems using fixed mount scanners. While it is true that a verifier is, in a sense, a scanner, which must decode the symbol in order to verify it, the way the captured data is handled is quite different than a scanner whose only task is to decode the symbol.

To say that inline verifiers are being “oversold” carries two connotations. First, they are oversold when described as “verifiers” as shown in the bullet points above, which are not a complete list of inline system failures. Oversold also relates to the overkill of doing much more than is reasonably necessary—for example in static barcode reproduction—when the printer is producing thousands and thousands of copies of the same barcode. There, periodic spot checking offline is sufficient and much easier to track and monitor gradual changes in parameter grades. Unless something devastating happens with the printing press (highly unlikely and easily discerned by the naked eye), barcodes and other graphical images don’t change or degrade rapidly. A test every several thousand impressions or every 30 minutes gives you a good look at the overall quality of the symbol without burying you in data from every individual image.

There certainly are circumstances that warrant 100% verification—I have installed and maintained such systems: high security variable or sequential printing environments where the output barcode image must match the input design data is one such circumstance. I’m not saying high speed inline verification is never necessary: just because we have the technology does not mean it is always the best tool for the job.

Comments are always welcome.