An IS4C lane connects to the scanner scale via the serial port. Before the computer and the scanner-scale can communicate, the usual serial communication parameters, namely, baud rate, parity, handshake, stop bit, data bit, have to be identical on both the computer and the scanner-scale. We'll worry about the computer first.
If your serial port is /dev/ttyS0 and you are using a Magellan scale, you can probably skip most of what follows and go directly to the
summary below. If, however, you want to immerse yourself in the nitty gritty, do continue.
IS4C assumes that the first serial port is at /dev/ttyS0. Ascertain that it is the case on your system. The traditional method for testing and troubleshooting the serial port is to use a null modem cable to connect the computer to another with known serial port settings and then try to communicate back and forth. We won't resort to that. Not yet.
plug the scanner-scale into the serial port, and check that it is ready to scan. issue the command
Give write permission for Apache-PHP to use /dev/ttyS0. I open it up completely:
By a happy coincidence, these happen to be the "out of the box" factory defaults for the Magellan 8500.
again and scan something. If you see a short prefix followed by the barcode translated into the right numbers on the screen, then the serial settings are correct.
You shouldn't have to program Magellan scales, since IS4C is configured to work with them. However, if you are not using a Magellan scale, and the input on the screen are not barcode numbers, don't panic, we just have to program the scanner scale to the same settings. Usually this is done by scanning a series of special barcodes provided by the manufacturer. Follow the manufacturer's instructions. Should it become necessary for you to program the scanner scale, these are the IS4C settings that correspond to common scanner scale factory defaults.
Now let's try sending data from the computer to the scanner-scale.
To summarize this section on testing
Run /pos/is4c/rs232/setport.
Test for scanned input with
cat /dev/ttyS0
You should be able to see a string of number corresponding to the barcode.
Test for output to to the scanner-scale with
echo -e "S334\r" > /dev/ttyS0
You should hear a beep.
If the results are unsatisfactory, the system won't work properly and you will have to program the scanner scale with special barcodes provided by the manufacturer.
The Scanner-Scale Daemon ssd
IS4C works with the scanner scale by continuously polling the serial port with a c program. The source is at /pos/is4c/rs232/ssd.c The program is compiled into a daemon 'ssd' and set to run at boot time, so that the lane computer is always listening to /dev/ttyS0. ssd performs two functions.
1. It separates data coming in from the scanner-scale as either scanned data or scale data based on the prefix of the data stream. Scanned data is written to the file /pos/is4c/rs232/ssddata/scanner and scale data is written to /pos/is4c/rs232/ssddata/scale. Data streams that are mis-formed and garbled, and otherwise cannot be ascertained to be either, are discarded.
2. While scanned data comes in directly as an ASCII streams, scale data has to be polled. ssd sends commands to the scale based on previous responses from the scale in a continuous polling process to capture weight readings.
To get ssd up and running,
compile /pos/is4c/rs232/ssd.c into /pos/is4c/rs232/ssd
cd /pos/is4c/rs232
gcc ssd.c -o ssd
Arrange for ssd to run at boot time. This involves putting a link to ssd in either /etc/rc.d/ or /etc/init.d and then invoking it in the appropriate initation file, such as rc.local.
While ssd is running, javascript code in a static frame uses AJAX to continuously read the contents of these files and pass them into PHP global variables. PHP also clears out /pos/is4c/rs232/ssddata/scanner after each reading, to prepare the system for the next scanned item. Scale data, however, is not cleared out, because we want the global weight value to always be the weight of the item on the scale.
Apache-PHP needs read permission for /pos/is4c/rs232/ssddata/scale; read and write permission for /pos/is4c/rs232/ssddata/scanner. It also needs execute permission for the script files in /pos/is4c/rs232/. ssd needs write permission for /pos/is4c/rs232/ssddata/scale.
Important
So far, the mechanism has involved writing the contents of the serial buffer into files on the hard disk,
and then have AJAX read the contents of those files, from the hard disk, and passing them onto php global variables. One way to improve on the mechanism is to not have the files residing on the hard disk at all, but to have them existing only in volatile memory. In the same way that Windows can create a 'Ram disk' out of memory, we specifiy a small amount of memory, and
mount it to the directory /pos/is4c/rs232/ssddata. In other words, /pos/is4c/rs232/ssddata is actually created to be a mount point that accesses a certain area of volatile memory instead of being a path to part of the hard disk.
Issue the command
mount -t tmpfs -o size=2m tmpfs /pos/is4c/rs232/ssddata
The default 2m is probably overkill. Pick a size you like, remembering that however much memory you specify will be lost to other processes.
Arrange for mounting at boot time by putting the command in /etc/init.d/rc.local. There is probably a way to do it in
/etc/fstab, for those who know these things.
For permission, I open everything up to keep the headaches at bay
chmod -R 777 /pos/is4c/rs232
Let's check to see if everything is in place.
With ssd running, read the file /pos/is4c/rs232/ssddata/scale
tail /pos/is4c/rs232/ssddata/scale
It should say 'S143'. Put a weight on the scale and read the file again. The weight should now be reported following the prefix 'S144'.
Next, scan a barcode and read the file /pos/is4c/rs232/ssddata/scanner. you should see a four character prefix starting with 'S08', with the fourth character dependent on the type of barcode you are scanning and a string of barcode number after that.
When IS4C is up and running, the javascript/PHP code does this for you, preferably from volatile memory instead of from the hard disk, and that's how it all works.
Here's some more information.
Magellan provides the following
document
detailing the polling behaviors of their single cable RS232 scales.
One Final Detail
When the scanner scale comes from the factory, it is set to give a "good read beep" whenever a barcode is successfully scanned. A good read beep, however, does not guarantee that the data stream is properly sent to the serial port and captured by IS4C. An item is only truly rung in when it is written into a table in the translog database. IS4C therefore asks the scanner scale to make a beep whenever an item is correctly inserted. When an item is successfuly rung in, with a scanner-scale that has just been taken "out of the box", the system will therefore make two beeps - the machine good read beep, and the IS4C insertion confirmation beep. The gap between the two beeps gives you an indication of how fast, or slow IS4C is running. Two beeps per items, however, assault the senses.
At the Wedge, we disable the machine good read beep, so that the cashier only hears one beep - the IS4C confirmation beep. If there is no beep, the item has not been inserted into the database, and it has to be scanned again. The machine good read beep has to be diabled by directly programming the scanner-scale with the special series of programming barcodes. Consult the documentation from the manufacturer.