There is a dedicated community of plotter enthusiasts who keep their often-aging X-Y axis pen drawing devices going decades after they were built, and who share plotter-generated paper artwork online. [Dhananjay Balan] was seduced by this, so acquired a second-hand HP7440A through eBay and set about bringing it to life.
Bringing it to life was in the first instance the usual progression of cleaning the mechanism and checking all was in order, before doing a bit of research to find that the missing power supply was a 10-0-10V AC item. Then some adapters and a USB-to-serial port had it talking to a modern PC, and thanks to the wonders of HPGL it was working once more. This could thus have been a very simple tale worthy of the dreaded Not A Hack moniker, had the focus then not changed from the hardware into the software.
Back in the day, a 60-byte buffer in a plotter must have seemed huge. But in 2019 a plotter can be sent data at a rate that will swiftly fill it, after which the commands are not stored and are never drawn. Introducing a delay between sending commands solves the problem, but at the expense of very slow plotting. This was solved with a very clever use of the HPGL command to send the pen position, which waits until the pen has finished moving before sending its return value. This became a handy way to detect when the plotter was ready for more, allowing speedier printing without buffer overruns.
The plotter has an expansion port into which an optional module containing trigonometric drawing functions could have been plugged, but was missing in this example. HP’s idea was that the buffer was so small that a programmer would have difficulty writing their own, but the buffer hack in the previous paragraph put paid to that. Python code for all this and more is in a handy GitHub repository.
Via Hacker News.
Neat, although overkill.
Back when I went down the rabbit hole of plotting, I suffered greatly until I realized that the HP plotter I was using (since junked for other reasons) actually supported hardware flow control! Zero hacking needed, just a not-shitty serial adapter.
Uh, shouldn’t he just have enabled the hardware flow control of the serial port? RTS/CTS.
It looks like the base plotter doesn’t support RTS/CTS. It crashes if the buffer of 60 bytes overflows. There seems to be an add-on board (which he doesn’t have) that enables handshaking, expands the buffer, and adds certain graphics primitives (https://support.hp.com/us-en/document/bpp01354)
So it doesn’t support RTS/CTS flow control?
Maybe it has been fixed in the meantime, but some time ago i learned the hard way that RTS/CTS does not work with CH340 on Linux. Bad day! (and no, couldn’t write it myself, to little knowledge…)
You can also add delays after each command using a look up table for how long the command is known to take. Lines and ellipses have a very easily calculated draw time. I sold my plotter when I got low on thermal paper because it was too difficult for me to get more paper and I needed the money more for parking fees in college.
IIRC this plotter uses DTR for handshake, but also speaks XON/XOFF.
Just messed with one that uses Xon/Xoff… autocad add a plotter doesn’t seem to like software flow control. Realterm worked fine.
Thermal paper in a plotter? Tell us more!
This is very suspicious, I smell a plot! I’ll let myself out.
I used to have a single pen version of this plotter. I had no trouble at all using it connected to a real RS232C port of a decently fast computer.
The HPGL language is pure low ASCII characters. That makes it dead easy to use from a command prompt. From your CAD program that can save PLT files (or use a 2D DXF to PLT conversion program) save the PLT file in HPGL ASCII (or plain text, not binary). Then you simply use the COPY command in a command prompt like this.
C:\>PLTFILES\COPY FILE.PLT COM1
If your plotter is HPGL/2 which uses some non-ASCII characters, you’ll want to use the /B for Binary switch
C:\>PLTFILES\COPY FILE.PLT /B COM1 /B
To make things easiest, you’ll want to set the COM port speed, baud, stop, and parity bits in the operating system’s options to match the plotter settings. For Windows you can make a CMD or BAT file to run in the command prompt to do a MODE on the COM port before sending PLT files to the plotter.
mode COM1 BAUD=9600 PARITY=n DATA=8
I used mine to plot out some cutting patterns for pieces of masonite to stack together for making a prop Astro Automatic pistol from the 1974 Space Battleship Yamato anime series. Then I sold it because I was never going to get around to converting it to a vinyl cutter.
Losing data when sending to a serial device is a symptom of having the port baud rate set higher than the device’s baud rate, or a very poor USB to serial adapter.
Try GENPLOT and RUMP with the plotter. http://www.genplot.com/ Windows 9x/NT, Linux (with source code), OS/2 versions. The GENPLOT manual on its own looks like a treasure trove of useful info on many old plotters.
A few weeks ago I inherited a Roland plotter that also uses the HPGL command set, however this plotter has a buffer size of around 4KB. I encountered the same issue when trying to plot complex artwork and had to come up with a solution. Many people simply use CUPS to spool the data to the device, however needing CUPS to run the plotter IMO is massively overkill, so I wrote a little spooler in python:
https://gist.github.com/gnif/d8b9889929e835b85a6fc521295874fe
This script actually interrogates the device asking it for it’s current buffer state and waits until there is enough room to send each command.
With my own plotter (Motori, featured here a decade ago, sigh), which uses FT232R, I had trouble using RTS/CTS flow control from under macos. No matter what I’d do, it just didn’t work at all. No problems under windows, even from within VirtualBox ran on the same machine. I guess it’s more about the drivers than the OS itself. If something works for your combination of serial usb/os/driver version, it does not automatically mean that it works equally well for everyone else.
And plotters are awesome.
Interesting point… now with USB adaptors, there are [at least] Three physical buffers involved, one at the device, one at the Serial port’s chipset, and one at the USB host… A poorly-designed serial chipset may presume that flow-control is the computer/OS’s responsibility, at which point the serial-port chipset may continue to dump its buffer contents while waiting for the host [rather than device] to tell it to pause, which could occur several USB packets [and several more buffers’ worth of data] down the line! Weird era.