Bar Code Tutorial: Scanning
When companies start to add bar codes to their existing systems
there are a number of basic questions that occur immediately. This
page attempts to answer some of those questions, and give you the
knowledge you need to make intelligent selections during your
bar code implementation.
How Do I "Bar Code" my Company?
Bar coding your company requires that a system be designed
for your company, and a method of implementation agreed on.
This can be complex, and we refer you to our excellent
resellers for help in that matter.
Fundamentally, though, you need to print the bar codes and
attach them to the parts to be tracked, and then scan the bar
codes into your applications. Printing bar codes is covered
here. We will cover here the four
basic ways to scan bar codes into your applications:
Each method has its own advantages and disadvantages.
Originally, a wedge was a piece of hardware with a scanner
and a keyboard cable attached. The keyboard from a PC was
plugged into the wedge, and the cable from the wedge was
plugged into the PC. Whenever a bar code was scanned, the
wedge sent the data the PC exactly as if it were
keystrokes. This is a simple but powerful way to scan bar
code data into your applications.
When laptop PCs were developed, there was no way to attach
a wedge to them (their keyboard was integrated into the PC.)
Software wedges were developed to fill this need. A scanner
with an RS-232 cable was attached to the serial port of the
PC (the laptops had serial ports.) A piece of software was
then loaded onto the PC that constantly monitored the serial
port. Whenever a bar code was scanned, the software converted
the scan into keystrokes which were then sent to the
keystroke buffer.
The advantages of the
wedge are that they are inexpensive, they are very quick to
implement, and they do not require that you reprogram your
existing applications (the bar code data will go into any
screen that accepts keystrokes without modification.) These
advantages are significant, and hardware and software wedges
are a common method of reading bar codes.
However, wedges has a
significant disadvantage, too. There is no way for the wedge
to tell if the data being sent as keystrokes is being properly
handled. If the receiving program is crashed, or the user shut
it down, the keystrokes will be sent to whichever application is
at the front. This means that the wedge user must be at the PC
screen to monitor the activity and ensure that everything is
going fine. In cases where R/F wedges are used, some amount of
risk is assumed, in that the data being scanned may not be
getting to the right application.
Intelligent wedges
In an attempt to solve some of these problems, Datatech
has developed methods to give Keyport
(our software wedge) some intelligence. These methods are so
revolutionary that we have patents pending to protect them. Keyport
combines verbal prompting, data checking and system monitoring
in such a manner that the user can be sure that keystroke
data is being handled by the correct application.
Keystrokes can be targeted to a particular window. For
example, assume that the user wished to scan a part
number and quantity into a receiving screen. This screen
is contained in a window titled "Receiving". Keyport
constantly monitors user activity, and if he brings
the "Receiving" screen to the front, Keyport would prompt
"Receiving transaction, please scan part number." The user
would then know that the correct application was in the
front, and ready for data.
After a scan, Keyport would check the data to ensure
that it was a part number. If it was, the data would
be sent as keystrokes, and the user prompted "Please
scan quantity." If it was not, the user would be
prompted "Invalid scan, please scan part number."
In this manner, the user
can be sure that all is proceeding correctly when using a wedge,
even if he can not see the PC screen to monitor activity. In the
case of an R/F scanner, the user could wear wireless
headphones and be prompted even while completely
away from the PC.
Multiple-scanner wedges
Relatively recently, Intermec and Welch-Allyn have
begun to market wireless devices where more than one
scanner can send scans to one base station. This
can be connected to a PC either via a keyboard cable
(standard wedge) or a serial cable. When operated with
one scanner connected to the PC with a keyboard cable,
this system is merely a typical wedge (although with
wireless capabilities.)
When operated with two or more scanners connected
to the PC with a serial cable, however, the system
posseses much more potential. What is needed is a
piece of software to gather the scans from the
different scanners and feed them as keystrokes to
the appropriate application without inter-mingling
scans from different scanners.
To meet this need, Datatech developed
Multiport. Multiport
takes advantage of out new "smart-wedge" technology
to gather the scans from up to nine scanners, sort
the data appropriately, and send the data as
keystrokes to the correct application (even
across a network to another PC.)
This means that
wedges can operate effectively as wireless devices
(remember our patent-pending, smart-wedge technology
allows the user to leave the PC.) Further, only one base
station and one PC needs to be purchased for up to nine
scanners.
The second common method of scanning bar codes into your
application assumes that you have an existing application
that works with data terminals. Intelligent readers (readers
that are programmable) are obtained that run a terminal
emulation program. These readers then act as your existing
data terminals do except that they can scan bar codes,
which are then entered as keystrokes into your application.
The advantages of terminal
emulation is that it is very quick to implement, the user gets
the normal feedback that he is used to (on the reader screen,)
and you are not required to reprogram your existing
applications.
The disadvantages of
terminal emulation are
- it is more expensive than the wedge solution,
- if an R/F reader goes out of range of the base station
the user can not do any work, and
- if the mainframe is down, the user can not do any work.
Terminal emulation remains a very common way of implementing
bar codes, primarily because the user gets to use the existing
terminal program he is used to.
Most major manufacturers sell fully-integrated bar code readers.
These are equivalent to a personal computer with integrated
scanner, but repackaged into a small size. Some run MS-DOS,
some run Windows or Windows/CE, and some run PalmOS. These
readers are quite powerful and run custom programs, usually
written in C.
Once a custom program is
written, it provides the most powerful method of implementing
bar codes. The readers can perform sophisticated error checking.
They can provide appropriate user feedback. Finally, when the
mainframe is down, or the reader is out-of-RF range, the
reader can go into back-up mode, and the user can
still collect data. This data can be uploaded later when
the situation improves.
Although it usually
provides the best solution once implemented, custom programming
has several disadvantages.
- It is very expensive. The intelligent readers are
more expensive than scanners, and the designing and
developing the programs to run on the readers is expensive.
- It takes the longest to implement. If done properly,
designing, developing, and testing the program is time-consuming
- the developers need to learn how to program the readers
to communicate with the in-house data systems.
Dispatch was designed by
Datatech to make this job easier.
Despite the significant disadvantages, custom programming
remains an attractive alternative, because of the superb results
that can be obtained.
If you have an existing database, MRP system, or other system
that you are contemplating adding bar code to, you should check to
see if they already have a bar coding module that can be purchased.
If they do, it will fall into of the three major
classifications above, but it will likely be less expensive than
it might usually be, because the development costs will hopefully
be spread out over other customers. However, the company that
developed your MRP package may not be a bar code expert and it
may pay you to implement your own method.
|