Hi Walter,
Walter Banks wrote:
[attributions elided]
You can also opt to use UPC register and never mistake a
cap for a box of cheerios.
But that requires the person operating the register to
be aware of the distinction (pick something other
than caps and cheerios and repeat the exercise)
In the UPC cas that is essentially all users are registered. The
registration cost is very low to encourage participation, the
benefits are data security and rare false positives The standard
UPC record checking will weed out essentially all the rest
of the unregistered UPC images..
UPC was developed to eliminate the problem that you
have been describing. A bunch of years ago the barcode
industry was filled with many different transport layers
and data formats most with a unique application area.
The only security was each company creating their
own encoding and data and record formats.
Exactly. Because the entire namespace ("message space"?)
was available to all users. Imagine if anyone could make up
any FQDN and tried to operate in the presence of other
folks (sharing a namespace).
The problem with the UPC route is it would cause you to use
up huge blocks of numbers needlessly. E.g., imagine if
UPS/FedEx used UPC labels as their "package identifiers".
These are essentially disposable identifiers yet putting
them into a shared/administered namespace would waste
big pieces of that namespace needlessly.
False positives are rare, once format, validation and context
Only if you can pick a unique combination of the above!
Doing this blindly has no guarantees. As I said, if I
arbitrarily picked a 6 character Code 128 identifier
and used that, eventually I *will* scan a label on a Dell
PC and find a coincidental match with some other object
in my database. Granted, you can recover from this.
But, it is a problem that need not happen if I had picked
some other scheme.
are accounted for. For example, the automotive industry
has literally hundreds of suppliers using two or three
standard barcode encodings and don't have a problem
with false positives because of this.
But I imagine they:
- don't let items come into their receiving dock without
rigidly defining how they are labeled; or
- instruct their staff to obscure any other barcodes
that may be on the packaging/items; or
- instruct their staff in *which* barcode is the "correct"
barcode to scan
- etc.
I.e., they can't just scan a barcode -- ANY BARCODE IN THE
BUILDING -- and be assured that it is *the* barcode that they
wanted to scan.
(they are also big enough to be able to enforce their wishes
on their suppliers -- "you will label your parts in this
fashion")
I can work around *some* problem areas by visual cues in
the labels. E.g., location identifiers are affixed to
blue plastic placards so a user "knows" this is a location
identifier and doesn't have to go hunting for it. But,
the software can't tell that the data scanned came from
a "blue plastic placard".
Actual Dell now uses a 7 character identifier for service
I stand corrected. I was looking at a license tag. <
tags. However you just identified an important point
on identifying barcode, context. Dell uses several barcodes
on the bottom of there laptops top identify product,
manufacturer software licences and service tags.
Yes. So you either have to know which barcode to scan
or have to encode information in the label that lets
the system figure out which label you've scanned and
prompt you to scan some other (if it is awaiting some
specific piece of information).
I want to be able to have a label scanned and be able
to tell the user authoritatively that it is the "right"
label to scan and/or the right label 9item) he is looking
for.
Probably quite a few and a lot more Code39. Fewer
using the same field format for the actual serial number
fields which encode manufacture data, product id and
actual identifying number.
But 123-45-5678 from Dell means something different from
12-34-556-78 from T.I. (bogus examples). I.e. the
namespace (messagespace) isn't standardized. I suspect
folks like Dell make this work by having *lengthy* labels,
possibly with large hamming distances or lots of enforced
redundancy -- and by controlling the items that can
get "on the floor" *with* "foreign labels".
Barcode formats are implemented in layers. Additional
checking in some cases is important. Do it. I am not
I intend to. Beginning with verification of the symbology
used in each scanned label.
sure what you application is? Describing the application
may identify or reject some of the standard solutions.
Loosely speaking, inventory tracking. But, using the labels
throughout -- to identify parts, to identify stock locations,
to identify shipping manifests, to identify the individuals
picking/packaging/shipping the items, etc. Their just
manifestations of "universal identifiers". I just want to
minimize the chance of some *other* (foreign) label being
erroneously interpreted as "one of mine" and having the
process stop while folks sort out why the item the item they
seek isn't in "this" location ("Oh, you scanned a barcode
that *Digikey* had applied to a component; *not* the little
blue plastic placard that we use to identify locations!")
The Average Joe isn't going to understand the nuances
of "barcodology" :-/