Getting a HP 7550A plotter to work under Linux

This is the thing, it's huge and exceptionally well built. Right: a HP-85 that I pulled from the stockpiles once. I could have used it to control the 7550A, but I sold it in 2005.

The Electronics faculty of Delft University of Technology has a strange way to get rid of their obsolete equipment. They put everything on the side of the road in big containers and wait for people to clear them out. After a week or so, whatever's left goes to a trader. Everyone wins: we poor students can get our hands on obsolete but cool equipment, and the faculty has to pay less to the recycling company. I keep a keen eye on these clearouts and always check them out thoroughly. During the last one, I came across the giant HP 7550A pen plotter that's the subject of this page. It just so happened that I'd been reading something about converting these units to sticker cutters the day before, so you bet I took it home right away. But when I got home and tried to make it communicate with my Linux server, it took me a bit longer than I anticipated. The serial settings are a bit hard to get right, but in the end I got everything up and running with the help of old Usenet postings and various obscure websites.

Connecting it

The first step in getting the 7550A up and running is understanding its interfaces. They're on the back and there are three of them:

1. a proprietary HP-IB connector;
2. an RS232 serial port;
3. a terminal port.

The HP-IB interface is obsolete, it's a proprietary HP communication protocol that was used in labs a lot, but is now defunct. The terminal port is a bit more interesting, I read somewhere that it's basically the same as the serial interface, only with a character echo, so you can send commands to the plotter per Telnet and see what you're typing. We won't bother with it here, because by far the easiest way to communicate is via the serial interface.

But to interface the plotter and the computer, we first need the right cable. The strange thing about the serial interface on the 7550A is that it doesn't use the industry standard 9-pin connector, but a 25-pins connector of the kind usually used for parallel ports. My computer uses the standard 9-pin connector for its serial port. The two connectors on either end of the cable have to be cross-wired in a proprietary scheme that can be found on various places on the internet, but which I've reproduced below for convenience. HP will sell you a proper connector cable, but the easiest and probably cheapest way to get one is to make one yourself. Just take some seven-veined cable and some do-it-yourself snap-in connectors from the electronics hobby store and hook them up as in the diagram below.

The whole thing visualized.

This should take care of the physical connection, but now we have to set up the software so that the two machines can actually communicate.

Communicating

Baah, ugly.

I found that the 7550A automatically listens to all its inputs, so you can just send data to it without having to make it listen specifically. The communication settings for the serial port are stored in non-volatile memory, so your unit probably has some presets there. I got a working setup with the following configuration, but feel free to choose your own settings: remote standalone mode, 9600 baud, 8-bit, odd parity, XON/XOFF handshaking, direct, full duplex.

I chose to use the parity bit for basic error correction. If I'm not mistaken, all the bits in a data frame are added up and produce a 1 or a 0 if the sum is odd or even. This bit is then sent with the data, so that the receiving machine can run the same check on the data and see if it matches with the sent bit. If it doesn't, something went wrong and the data is resent. It's a bit crude, but any error correction is a good thing.

XON/XOFF handshaking is another good idea in serial transmissions. Normally when you connect two devices over a serial line, they should only speak when the other party is ready to receive. XON/XOFF handshaking provides a means for this. When the computer receives a ^S character from the plotter, it stops sending data, allowing the plotter to process its input buffer. When the plotter is done, it sends a ^Q to the computer, telling it that it's ready to receive again. The computer starts sending again, keeping the plotter fed with data just in time, which is necessary because it only has a 9Kb (or so) task buffer. Large tasks need to be sent piecemeal, or the plotter will complain about buffer overflow errors almost immediately. That's why handshaking is absolutely essential.

You can change the settings for serial communications on the LCD screen by pressing enter and next page. Changes must be confirmed by pressing enter, just going to the next page won't lock your settings.

At this point the plotter is all set, but the computer isn't. We have to set the proper parameters for the serial connection to get it in sync with the plotter. To do this, we use the somewhat cryptic and low level stty utility. First you need to figure out what your serial port is named, but usually it's the fairly standard /dev/ttyS0. Check the status of this port as follows:

stty -a -F /dev/ttyS0

That will give you some info on the current settings. Some parameters will usually be set up correctly, but the following will set everything in one go:

stty 9600 parodd parenb ixon ixoff -F /dev/ttyS0

This means: 9600 baud, set parity to odd, send parity bits, honour the XON character, honour the XOFF character. If this went well, the computer and the plotter are now in sync and we can try catting a test file to the serial port.

/dev/ttyS0 < test.hpgl

This should spool and plot the file without problems. We're done!

If XON/XOFF handshaking should work but doesn't, either plot at very low baud rates (300 baud or so) to keep the plotter underfed with data (but this may cause ink spills), or set a higher pen velocity to finish your buffered tasks quicker. You should also reboot the plotter and the computer and see if handshaking works when both come back online. The first time I tried to link mine, it didn't work even though I was certain all the settings corresponded. It took a hard reset on both machines to get everything up and running.

Note that I didn't have to use nonstandard devices (/dev/ttyD0), that I didn't have to start strange background processes (I read somewhere about having to enter cat /dev/ttyS0 > /dev/null &), and that I didn't have to make strange changes to my system. All I needed to do was setup the proper serial connection to get everything to play well together. I haven't looked into installing the plotter in CUPS or some such, serial works for me and it's hard to see how the interconnect could be any more streamlined than this. It's just catting a file to the serial port, what could be easier?

Troubleshooting

If you think you set it up correctly and it didn't work, try checking all the settings and rebooting a few times. That did the trick for me. If you have any specific problems, try searching for 7550a on HP's website, it has quite some information about connection and paper errors. Another really good resource is the Usenet archive, which has lots of posts from the 1980's and 1990's from scientists and computer professionals struggling to get their plotters connected.

Plotting stuff

Plotting an image of a Cadillac. Photographed through the plastic cover, so a bit murky. The image of the Cadillac was created by tracing a photograph with potrace (open source tracing software), then exporting the .eps file to "a vector editor", then exporting to .dwg format, then importing in AutoCAD, then saving in HPGL format.

Okay, so we have the plotter up and running, now what can we do with it? One of the most interesting applications is to turn it into a sticker cutter, but I haven't tried that so I don't have much to say about it. There are some good resources online on how to convert your plotter. Another interesting related project could be to turn it into a stencil cutter for graffiti art.

One thing that does interest me is making use of the programmable pen speed and pen force of the 7550A. I think it could be possible to write a plotter driver that lets the 7550A plot photographs and line drawings with pencil or fineliner, rendering bitmaps by modulating force and speed. That would definitely be an interesting project to work on. Another thing I would like to do someday is make a pencil mount and convert my plotter to a pencil printer. If I ever get round to those projects, you'll read about it here.

It amazes me how precise this plotter is. All the lines are spot on, even when drawn with a very fine pen, and the plotter never seems to lose sync, even after drawing thousands of small boxes. This is due to solid engineering and the giant sanded wheels used to handle the paper.

Something to keep in mind when sending control characters directly to the plotter is that many auto-generated HPGL files (for instance from CAD programs or the Windows driver) contain their own XON/XOFF initialization commands and can interfere with any clever manual tweaks you made.

Force and speed

HP's tech support seems to tell us that we can set a pen force between 15 and 66 (grams) with the FS <force> command, and speeds between 1 and 80 (cm/sec) with the VS <speed> command. It's a bit confusing, do we enter the literal physical values for force and speed? I can't believe so, because both parameters can also be set on the plotter, and there the ranges are only 1–8 anfor force, and 10–80 infor speed in steps of five.

To test all of this, I wrote an AWK program that creates a HPGL script that generates a plot of force against speed by drawing little squares with varying speed and force. I first plotted 4160 little squares by varying the speed over 1 to 80 and the force over 15 and 66, like HP said. The results: force seems to be uniform everywhere, so it's probably capped at 8. However, speeds lower than 10 do have meaning, because at the start of the plot, there is a giant difference between VS 1 and VS 2.

Next I tweaked the AWK script above to plot force and speed using the range of the plotter itself. Force in the range of 1 to 8, and speed in the range of 10 to 80 in steps of five. The results: we lose the really crawling speeds at the beginning of the range, but we get an obvious difference in pen pressure that we didn't see before.

Overall conclusion: speeds have a meaningful range of 1–80, and speeds which are not a multiple of five are probably also meaningful. The pen speed is intimately linked with the hardware and timing circuits, so the actual physical speeds can probably be easily honoured by the plotter. Force probably has a meaningful range of 1–8 and caps after that. The force is probably not as tightly controlled (through a feedback loop) as the pen speed and is probably created by a simple duty cycle from the microprocessor, not by monitoring the actual force. It makes sense to enter abstract 'steps' rather than actual physical values.

Very high speeds are quite difficult to get due to acceleration and deceleration constraints. When plotting the squares, you see that after a certain point the plotter just doesn't go any faster.

Contact
Commit bd3bb89 at Tue May 31 23:52:16 2022 +0200