After many years of trying half-heartedly to get my HP 7475A plotter working under
a modern linux kernel, I finally suceeded.  Mostly, it involves getting the stty 
settings correct.  I know this is a lame excuse, but I had the devil of a time 
understanding the typos and other mistakes in a script I found that allows you to test
your plotter using a shell script.  After correcting the script, lo and behold, the 
plotter sprang to life and wrote a bunch of garbage.  I had to adjust it some more
and the final script doesn't really vary much from the original.  Most of the 
adjustments had to do with timing, and making sure the plotter's buffer wasn't 
over-run.

The script is simple enough, so I'll post it here and make comments about it.


#!/bin/sh
stty 9600 -parenb -parodd cs8 crtscts -cstopb </dev/ttyS0
echo "PU;^O" >/dev/ttyS0
echo "SP1;^O" >/dev/ttyS0
echo "PA 0,0;^O" >/dev/ttyS0
sleep 5
echo "PA 20000,20000;^O" >/dev/ttyS0
for i in 0 2000 4000 6000 8000 10000 12000 14000 16000 18000 20000; do
   for j in 0 2000 4000 6000 8000 10000 12000 14000 16000 18000 20000; do
      echo "PU;^O" >/dev/ttyS0
      echo "PA $i,0;^O"  >/dev/ttyS0
      echo "PD;^O" >/dev/ttyS0
      echo "PA $j,20000;^O" >/dev/ttyS0
   done
   sleep 20
done

The stty command is half of what's important.  The line from the original script 
looked like:

stty 9600 -parenb -parodd cs8 -crtscst -ostopb </dev/cua1

Which has some odd typos in it.  It almost seems like it was scanned in from a 
text document and never corrected.  In any case, I'm not sure why crtscts was
turned off anyway.  I initally thought that maybe the plotter couldn't do 
hardware handshaking.  I managed to get my hands on a scanned copy of the
HP 7475 Graphics Plotter Interfacing and Programming Manual at
http://www.luberth.com/help/HP_7475_Graphics_Plotter_interfacing_and_programming_manual/
and found out about all the different serial handshaking options for the plotter.  
This information led me to write a better driver in perl.  I'll get to that later.

Another thing that was causing me trouble was even after I was sure the stty 
options were correct, I still had problems having the plotter execute any of the 
hpgl without complaining.  In this script, I decided to use the flush buffer command,
"^O".  I also found out later after reading the manual that you can send DOS 
EOL characters and those will cause the plotter to take the commands.

Even with sending the commands to the plotter so that it would interperet every one, 
it was still ridiculously easy to cause the plotter's buffer to overflow.  So
there's the sleep 20 seconds kludge.  Of course you'll have to adjust that depending
on the speed of your plotter or the speed at which you set your pen.

I decided I needed a little more I/O power and since I'm a perl geek, I decided to
figure out how to do this in perl.  Here's my perl script, again, not complicated
and I'll make some comments about it at the end.

#!/usr/bin/perl
#
# Perl script to feed a serial plotter (HP 7475A in this case) an hpgl
# file.  Quick and dirty.  
#

$plotter_port = "/dev/ttyS0";
$numArgs = $#ARGV + 1;

if ( $numArgs == 2 ) {
        $plot_file = @ARGV[0];
        $plotter_port = @ARGV[1];
} elsif  ( $numArgs == 1 ) {
         $plot_file = @ARGV[0];
} else {
        print "USAGE: plotit.pl PLOTFILE [ PLOTTER_PORT ]\n";
        exit();
}

system "stty 9600 -parenb -parodd cs8 crtscts -cstopb <$plotter_port";

open (PLOT_FILE, $plot_file) || die "cannot open $plot_file\n";
open (PLOT_DEV,"+<$plotter_port") || die "cannot open $plotter_port\n";

$esc_at= "ESC.@;17:\r\n";
$esc_e= "ESC.E:\r\n";
$wrote = syswrite PLOT_DEV, $esc_at;
if ($wrote > 0) {
    syswrite STDOUT, "Wrote $wrote bytes.\n";
}
    
while ( $linein = <PLOT_FILE> ) {
        chomp $linein;
        @hp_cmd = split ( ";", $linein ) ;
        while ( $plt_cmd = (shift (@hp_cmd ) ) ) {
                $plt_out = "$plt_cmd;\r\n";
                syswrite PLOT_DEV, $plt_out;
                syswrite PLOT_DEV, $esc_e;
                sysread PLOT_DEV, $esc_e_res, 10;
                }
        }
}

First a note.  The ESCapes are escape characters and not the letters E, S and C in the 
$esc_at and $esc_e variables.  If you look at the Programming Manual, it shows these
as the necessary escape sequences to use for hardware handshakes.  I forget exactly
what "ESC.@;17:" sets, but 17 is a bit-mask for specific options.  I know that one
of those options is to set block mode.  This is where you can send a block of data
to the plotter and the plotter will accept the block or reject it with an error code.
This is better than sending a stream of data, then finding out that the buffer 
overflowed at some point and you don't really know what data you need to resend or
that you've sent an incomplete hpgl command.  ESC.E: is used to return any error 
codes (buffer overflow for one) to determine what kind of corrective action needs 
to be taken.  Basically, the most common use is to determine if the the last block 
of commands needs to be resent.  The really nice thing about this is you don't have 
to do any buffer housekeeping as you would with software handshakes.

One option I never played with is to set the block size.  The buffer on the HP7475A
is a whopping 1024 bytes and the default block size is 80 bytes.  You can assign up 
to the whole 1024 bytes to the block, but the recommendation is to max out at 512
bytes.  I guess if you wanted to be ultra-efficient you could make sure that you 
could fill up the block with a whole 80 bytes (or whatever size) every time, but
in all reality, this plotter is so slow, you could probably program this using
qbasic running under an interpreter on a Mac or something like that.

One last interesting point.  The Programming Manual states that the error light
should never go on when plotting.  When I plot something with my script, it flashes
regularly, but I have yet to lose any commands, so make of that what you will.  I
welcome any improvements to my scripts or any comments about my analysis.