One way to do this might be to make a computer emulate the serial printer, and receive the job and handle it. Some serial printers are very simple, they accept ASCII text at 9600 baud. However, a serial port printer can also send various status information back to the printing device. Rather than figure out the communications between the printer and measurement device, we decided to just intercept it all, and extract what we needed.
At first, when I would test-run snooper with the command
snooper /dev/ttyS0 /dev/ttyS1it would fail with an error message about "inappropriate devices" and return me to the prompt. This stopped happening but I am not sure why; I did recompile snooper once while trying to figure that out (I added some debugging messages to the source code where that error was produced, but the program started working instead of giving me more information).
(Note: I have now isolated the problem to the permissions that the snooper executable is assigned when you do "make install". When the snooper executable has the permissions
-r-sr-xr-x 1 uucp bin 55678 2005-10-02 12:18 /usr/local/bin/snooper*it does not work, and if I change them to
-r-xr-xr-x 1 uucp bin 55678 2005-10-02 12:18 /usr/local/bin/snooper*it does work. I don't know why.)
snooper /dev/ttyS0 /dev/ttyS1. On the computer without the modem I ran
echo "AT" > /dev/ttyS0and sure enough the modem lights flickered, and I saw an "AT" and an "OK" in the snooper output !
I also ran minicom on the second computer, so I could type "AT" and visually see the "OK" come back.
To log this data, I pressed "L" in snooper and entered the name of an ascii log file. This will be annotated by escaping the non-printable characters and marking each line as to the direction the data is travelling ( ttyS0 to ttyS1, or vice versa ). I also pressed "B" and gave it a log file to keep the raw binary data entering from one port in, and then pressed "B" again to give it a separate binary log file for the data going in the other direction.
After printing another test measurement, the data we wished to get was in one of the binary log files in ascii text; we did have to parse out some of the printer control commands.
Eventually I would like to be able to do the same thing with parallel and USB connections. In fact, if you know of a way to do this with USB please send me an email and let me know. All I know of is various programs that work on the same computer as in the usb host, such as usbsnoop; since USB is not inherently symmetrical, but has the notion of a host and device built into it (I think), this may not be easy.
For this project, I did not end up completely finishing it to the point where it extracted the printed information and filed it in a database, because we did not need to, although that had been our original goal.
For intercepting parallel port communications, this circuit and documentation seems essential: Parallel Printing Capture System by Kris Heidenstrom. Ideally, I would build the circuit board described on that page, and hook it up to a small linux computer, capture the printed information in linux, and then store it in a database or on a USB flash drive depending on the application.