Hacker News new | past | comments | ask | show | jobs | submit login
Pen plotters: not just output devices (2016) (scruss.com)
91 points by rbanffy 7 months ago | hide | past | favorite | 58 comments



I'm always amazed when (or how) an article of mine shows up here. I suspect it came about through this twitter exchange regarding a mystery device that came with someone's Calcomp plotter: https://twitter.com/artandtech/status/1387838582149287939

What I could never adequately explain is just how nicely made these digitizing sights are. They give a very bright, crisply magnified image of the point immediately under the pen position. This contrasts with how massively fiddly it is to try to operate exactly the right buttons on a pen plotter while squinting down a tiny optical sight.

Even though pen plotters weren't rare in the 1980s and early 1990s, I've never found any software (beyond the terrible script I wrote for that article) that uses this capability. There's probably some HP BASIC code lurking on a half-forgotten instrumentation archive that does the job, though.


When I was a grad student, some code for drawing axes would draw a tick on one side, go all the way to the other side and then swing all the way back. The motor was strong enough to make the table sway back and forth, and of course this method was slow. I remember writing code to draw a tick, come back on the tick, and then draw along the axis to the next tick. Presto, much faster!

We also had an HP plotter connected to one of those large (typewriter-sized) HP calculators, and I also wrote code to graph on that, too.

All of this was pretty low-level stuff, but not difficult, and the rewards were high for a grad student trying to get science done.

Fun times. And a step up from summer work preceding it, when I had to boot my machine by toggling binary switches for certain binary sequence that had to be loaded before it would start to read paper tape.

I think I'm old.


> some code for drawing axes would draw a tick on one side, go all the way to the other side and then swing all the way back.

Things like that were a weird combination of cool and hilarious, but in some cases you could turn it doubly cool.

When I was an intern, there was an old poster-size (D?) HP X-Y color pen plotter. Probably someone got for EDA/ECAD by our in-circuit emulator business, but someone had made a tool to make it work with CASE platform.

Being able to put a poster-size view of your system in team's area was pretty cool. (Though a Gantt diagram on the wall, of your team's entire project, to projected completion, was even cooler.)

The problem, like with those axis ticks, was that the HP-GL from our software wasn't very aware of the implications of a pen plotter, especially not the usual kind, which had to return home to change pens. Which made it almost comically slow to watch printing (though still impressive that it could draw one color for a few seconds, go change a pen for a few seconds, and then possibly return to approximately the same place, and repeat).

So, as one of my energetic intern midnight unofficial projects was to write an optimizer that read in that HP-GL and spit out HP-GL that would print faster. Rather than solve hard optimization problems, IIRC, I tried this very simple approach:

1. Do all the drawing for a single pen color in one go, before you switch pens. (Even with a rolling plotter, rather than a bed plotter, the mechanics of the pen change seemed to make it the most expensive operation.)

2. When you're done with one drawing operation, pick the next operation based on which has the nearest start point to the current pen position. (Greatly reduce the duration of pen-up movements that are not due to pen changes.)

The speedup from that very simple approach was dramatic, as you might be able to imagine, even if you've never seen a pen plotter work.

(If it hadn't worked so well, I'd have had to be smarter about optimization, like looking ahead multiple steps in a plan rather than just looking for the nearest start point, and getting more flexibility, like being able to reverse the direction that a pen-down movement is drawn. Or maybe you'd even even sometimes break up an atomic movement, for a really big win, like in the hypothetical of a few-foot border segment drawn along a page, and near midpoint of that border axis has a little adornment drawn. In that hypothetical, you could draw the half the border, pick up the adornment, and then resume the border, gaining speed at the cost of your border looking slightly less perfect.)


> I think I'm old.

No. We’re vintage.


To this day HP still sells "plotters". They are just mostly used for cutting but you can definitely put a pen in there. And they have an optical eye to read markers on the printed media.

See HP Latex cutter: https://www8.hp.com/us/en/printers/large-format/latex-plus-c...

EDIT Oh, and they still speak HP-GL!


You can still make many HP and compatible laser printers speak HP-GL (well, HP-GL/2) through some arcane PJL commands.

Fun fact: HP-GL is equally compatible with metric and US customary measure as it uses 1/40 mm as its base unit. This just happens to be 1/1016 inches: not a tremendously useful integer factor, but every bit of integer goodness mattered back when peripherals were 8-bit.


> Fun fact: HP-GL is equally compatible with metric and US customary measure as it uses 1/40 mm as its base unit. This just happens to be 1/1016 inches

That’s a brilliant hack.


Reminds me of a high precision delta-sigma ADC I saw that had nulls at 60 and 50 HZ.


> This just happens to be

The inch is defined as 2.54 cm, since 1959. You might know this, just thought I'd add this note.


and you guys finally got rid of the US survey foot - the bane of this Canadian's existence when working on big civil jobs in the states. We'll get you guys using proper units afore long


The HP Latex cutter is a rebranded Summa cutter. AFAIK HP doesn’t produce plotters/cutters anymore, they do however produce large format printers (which operate on a totally different paradigm)


Note how I said "sells" ;)


Oops, you’re right! :)


I wonder how many implementations there were of that sort of thing. I wrote one for an HP flatbed plotter sometime in the 80s to digitize plots from papers, but I never heard of another. I don't remember the implementation, but it must have been cheaper hardware than the one shown, and only had a plastic lens as the sight. (Nowadays you have http://markummitchell.github.io/engauge-digitizer for instance.) I mainly used the plotter for acetate slides for talks when I'd only seen hand-written ones.

Some related history of input/output in physics: At the time, the "Bubblies" (bubble chamber particle physicists) used "flying spot digitizers" on their photos; I don't know how they worked, and to what degree they were automated. In contrast to that sophisticated input, HEP output was mainly histograms on line printer paper, stacked high, occasionally the grotty Tektronix 401x storage tube. Fortunately, nuclear physics had fast direct manipulation vector graphics and Benson roll pen plotters -- from whose song you could recognize types of plot across the room. Later the colour plots were sacrificed to faster monochrome Versatec electrostatics. (The Versatec printed my thesis, the first I knew produced electronically locally, long before we had an implementation of TeX.)


didn't know about Engauge: thanks! I've always used [WebPlotDigitizer](https://automeris.io/WebPlotDigitizer/), which doesn't require any installation


Around 1991 or so, I built an extraordinarily slow and deeply terrible scanner out of a plotter which had a simple fiber optical sensor instead of a pen. It was one of those "see what you can do with this stuff" projects that got thrown at me and I just coded this up with a data acquisition board and some flavor of BASIC. Supposedly about 1000 dpi.

I eventually came up with routines to speed up the scanning (left to right, move up, right to left, move up ...) and even hit upon using the "judder" from the repositioning of the pen to, properly timed, grab a point. This saved me from having to fully stop, I could just vibrate the pen forward. This ... probably did not do much for the lifetime of the plotter.

Man, that was a hot mess.


I think that's an improvement upon Forrest M. Mims III's plotter scanner. (He's the one who hand-drew some of the books at Radio Shack, like Getting Started in Electronics, and the 555 timer application notes circuits.) IIRC, for an article for Computers & Electronics magazine, he rigged up a flatbed X-Y plotter with an optical sensor (maybe one of the cadium sulfide photoresistors that RS sold?), and the resolution was very low, but it was pretty inspiring to kids. (It also gave you another reason to crave a plotter, which you now saw was really a robot module.)


Yeah, I used to have all of the Mims books from RadioShack. They were fantastic.

I recently found a partial printout of my "software," so I am looking at code three decades old. And it still had my style.


Interesting mention of Ferranti back when I was young we had a state of the art A0 Ferranti digitizer delivered (serial no 7)

My boss said “interesting project for you – hook this up to the PDP 11 make it work and then go and talk to Dave so he can use it to digitize the droplet cloud from an experimental rig”

First order of business was to get my soldering iron out and make up a suitable cable


I must admit I didn't realise that Ferranti did things like digitisers. I used to work at the Western General Hospital in Edinburgh, just down the road from the Ferranti site on Crewe Toll, where a couple of my flatmates were radar engineers. Don't know if that's where they produced the digitisers though.


the mailing address for Ferranti-Cetec was at Crewe Toll. I have a vague memory of the Ferranti-Cetec office being further west, though, but I could be wrong


I loved our HP pen plotter, back in the early 1980s. I never used it for input, but one of the more useful bits of software I wrote back then was to take the output of a Coulter counter (see https://www.wikiwand.com/en/Coulter_counter ) via some strange sort of serial interface it had (current loop?) and store it on floppy disk on a CP/M machine. I then wrote another utility to read the disk and plot parametrised graphs of it on our HP pen plotter.


We used to have a plotter when I was a teenager, in the 90s. My dad was into any kind of tech, and bought it 2nd hand, even though he'd never done any kind of CAD or anything like that (he did that with all sorts of stuff). I think it was a Roland device, and I think it was A3 sized, but it might even have been A2.

I got a copy of AutoCAD from a warez site (downloaded over dial-up, obviously!), and learned how to use it, using the plotter to print my masterpieces - things like floor plans and building elevations - yeah, I was a weird teenager, and went through a phase of being interested in technical drawing. I thought I'd end up as a draftsman or an architectural technologist.

Anyway, it was absolutely fascinating to watch the plotter at work! The pen would fly across the page at high speed to the next target site, then make all these incredibly quick, tiny, precise movements, before flying off to another part of the page. I can still remember the pleasing electrical whine of the motor as it worked. Wonderful bit of kit :)


I love them for similar reasons.

In my case, I was doing precision sheet metal and would often produce 1:1 layout plots for various purposes.

They sound amazing, and the better ones can really move and repeat to crazy good precision.


Can you make printed circuits by filling the ink cartridge with acid? I know it does not happen rightaway, put if you keep plotting same pattern and occasionally wipe the board clean. Eventually it would work for sure, but how long would it take? It would be slow but much easier than any other method.


There's conductive ink. There are pens that dispense an etchant. There's making printed circuit boards by iron-on toner transfer. There are little CNC routers for making boards.

All these approaches are worse than the standard photolithography process with plated through holes. It's so cheap and easy to get boards made now. Upload files, pay a few dollars, boards come back.


I've heard this so many times, but making your own is just a strong learning experience you don't get when you purchase them. You get exposure to mistakes!


Most of the alternative techniques are not precise enough for modern surface mount pin spacing. At 2.5mm pin spacing (0.10 inch, DIPs) they work. At 0.5mm spacing, not so much. It's mostly for retro projects that use through-hole components.


> It's mostly for retro projects that use through-hole components.

Welp now I feel very old.


> Welp now I feel very old.

Your username is a reference to colossal cave adventure; I'd be disappointed if you were younger than me (40).


You raise a good point, but alas you are less than a decade my senior.


I looked into making my own PCBs and came out with the impression that unless you need truly rapid prototyping JLCPCB is just better on all other accounts.


JLCPCB is excellent, but there's nothing rapid about them. Sometimes you just want to iterate on a board, and 4-6 weeks per iteration is loooong. Admittedly, 5.5 out of the 6 weeks is postage, but still.


Probably some kind of photo resist would work


Related folklore: Thunderscan - turning a dot matrix printer into a scanner.

https://www.folklore.org/StoryView.py?project=Macintosh&stor...


Pen plotters were fascinating to watch. I wish I knew what the motion optimization algorithms looked like. It would do stuff like draw the tail of an "R" but then wouldn't come back and draw the remainder of the letter until two minutes later.


if you want to see how it's done in modern plotters/CNC, Bart Dring's [Grbl_ESP32](https://github.com/bdring/Grbl_Esp32) is fairly easy to follow with good docs. I have one of Bart's plotters, as I don't have space or money for an Axidraw with all my other old plotters around the place.

For actual optimization of input files, [vpype](https://github.com/abey79/vpype)'s the one most people use.

Going back to really old/simple plotters, there wasn't enough code space to do any optimization. For example, the (fairly terrible) Commodore 1520 roll paper plotter had 2KB of ROM for all the 6502-compatible code its micro-controller used. When I first looked into the [firmware](https://e4aws.silverdr.com/hacks/6500_1/), I was pretty shocked that it printed text by scanning a table of character data from the start every time. Then I realized that even storing pointers for each character would use up about ⅛ of total storage, and the mechanical plotter mechanism was always way behind anything the code could do. So small mattered more than efficient


All of the ones I used had no optimization. They were basically CNC machines.

Feed it the ops, and they do those ops with precision and speed and will repeat all of that a zillion times.

Optimization was a front end process, if it was one at all.


the plotters themselves don’t have any, really. i do an optimization step before sending anything to the plotter.


HP pen plotters were/are highly intelligent devices - for example you could tell them to draw a pie-chart, provide the data and the labels, and they would go off and do it. If they were not intelligent, and you had to plot all graphs by individual pen movements, no business would have used them. They also optimised things like pen changes and paper movement.


A basic desktop plotter that spoke HP-GL couldn't do that. You couldn't tell it to just go plot a pie chart. It did have an arc primitive, but you had to specify the radius, color, start and end angles, and whether the arc was filled. You could build a basic pie chart out of several such arcs. There was also a label primitive, but only one font (variable sizes though). So if you had a fancy font you had to tell the plotter to draw it with simple line segments and arcs.

That said, most professional graphics software knew how to break down their elaborate output into HP-GL primitives with an appropriate output driver for the plotter. So few users actually had to do this unless they were talking to the plotter directly through a BASIC program or something.


On some of the really common older plotter models, like the 74xx/75xx, these features were present but it's often desirable to not use them as the plotter linearizes curve segments much more slowly than the host computer can. So you'll get markedly faster plotting (and less inconsistent ink bleed) if you reduce everything to line segments on the host. This can be as much as a 90% improvement in plotting speed if you have the linearization set pretty high (which is default a startup).

And at least on the 74xx, I have never experienced out-of-order execution of instructions, I'm skeptical that any plotters other than very recently implemented this as it would break assumptions made by a number of plotting packages if the plotter executed out of order. Many HPGL commands are highly stateful, considering how slow the on-board processor on these plotters was it'd probably make them net slower if they even tried to optimize.

The buffer is also very small in 'compatibility mode' but modern packages should be fine with the 'extended' buffer size that can sometimes fit a whole document if it's not too complex.


I have a 7575a. It will do some light reordering by pen number, nothing more. My Roland DXY-1150 which does "RD-GL" or whatever (but is functionally HPGL) does none at all.


Do you send the data and the labels to the plotter, or to the driver software running on your computer? I always imagined HP-GL would be a list of lines/curves, and that the plotter would plot them in whatever order they came in.


HP-GL was always able to plot text labels and make graph data markers: it was meant for scientific graphs, after all. Later plotters added arc sectors and filled (hatched) polygons. All the clever optimization was handled by the host computer: a plotter will just output what you tell it.

There is a feature in HP-GL that does make certain types of XY plotting simpler. While it's not a programming language like PostScript, you can scale, rotate and offset the plot by arbitrary amounts. HP instrumentation manuals claimed it was possible to directly plot experimental data by feeding it straight to the plotter after setting the scale. I feel this was a highly aspirational statement, and one not seeing much real use.


I was using a CP/M computer - there was no driver architecture. You sent HP-GL instructions and data as text via the RS232 interface. The plotter obviously had a limited buffer size, which would prevent certain optimisations, but then so did the CP/M computer!


So interesting!

In the most recent reference guide I found just now, it seems you can draw a segment of a pie chart using a single EW (Edge Wedge) instruction but, for a complete pie chart, this method would require you to calculate the angles of each segment yourself. And of course to add the labels yourself. Perhaps I'm looking in the wrong place or perhaps the instruction to draw a whole pie chart has been deprecated.


You may be right - this was a looong time ago. Calculating the angles from the data is not difficult though, so I may have forgot that I did it. I can't really imagine calculating and placing the labels myself though, but perhaps I was cleverer then!

Anyway, the HP pen plotter we had in the early 1980s was a very impressive device, when what we had were Z80 based computers driving them.


You misremember. It doesn't do any of that.


> The plotter obviously had a limited buffer size, which would prevent certain optimisations, but then so did the CP/M computer!

Yeah, but which had more? :) Reminds me of that time in the 90s(?) when people connected printers to computers, but the printers had more powerful processors than the computers. (Or later, when someone poked into the WiFi board on their arduino and realized that it was a more powerful microcontroller, but that's not so directly related)


HP-GL has a few convenience functions for text and fills and so on. It doesn't do any reordering aside from grouping pen operations together (so it doesn't change back and forth) but only if it fits in the buffer.


here is my HP DraftPro DXL going full tilt: https://www.instagram.com/p/CF048Zlpu2u/?igshid=1xsl4wmrcx2f...

Here is my CNC router with a paint pen also zooming along: https://www.instagram.com/p/CMT56JwA9sA/?igshid=15p9mru3f5ug...

if you want to get into this, the way to go is the Axidraw from Evil Mad Scientist Labs


I was going to get an axidraw but on a whim I checked locally and scored a HP7475a for $60 and got it working.

So definitely worth looking around a bit before going with new!


warning: images are not shown, just a social media login page


On mobile you can watch the videos without logging in.


I stopped browsing IG content completely because of this completely artificial restriction.

I love people that post to #plottertwitter and similar content, so pretty-please, don't post on IG or platforms that do this if your aim is to SHARE.

I don't have an account there, not planning to make one or to use an app to get it.


I grew up with books about technology and computers and whatnot which always seemed to include plotters in their sections about output devices (along with laser printers, CRTs, etc) and even contemporaneous books in the mid-1990s still talked of plotters as present-day output devices, yet I still haven't ever seen one in-person (but plenty of HP's large-format inkjet printers which still look-like plotters from a distance).


Ooooo.

Yet more reason to get my Draftmaster II up and running.

I wonder, is this command also what's used by vinyl cutters with the laser-sight for doing contour-cuts around vinyl printed in a different machine?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: