Capturing Screenshots Using A Fake Printer

If you have very old pieces of analogue test equipment with CRTs on your bench, the chances are they will all have surprisingly similar surrounds to their screens. Back when they were made it was common to record oscilloscope screens with a Polaroid camera, that would have a front fitting for just this purpose.

More recent instruments are computerized so taking a screen shot should be easier, but that’s still not easy if the machine can’t save to a handy disk. Along comes [Tom] with a solution, to hook up a fake printer, and grab the screen from a print.

Old instruments come with a variety of ports, serial, IEE-488, or parallel, but they should usually have the ability to print a screen. Then capturing that is a case of capturing an interpreting the print data, be it ESC/P, PCL5, Postscript, or whatever. The linked page takes us through a variety of techniques, and should be of help to anyone who’s picked up a bargain in the flea market.

This isn’t the only time we’ve touched on the subject of bringing older computerized equipment into the present, we’ve also shown you a disk drive emulator.

Thanks [JohnU] for the tip.

16 thoughts on “Capturing Screenshots Using A Fake Printer

  1. Wasn’t the GPIB port meant for taking the sampling data out and re-visualize it on a computer? I mean, it’s not a screenshot per se but you can also zoom in and out and display some more information than the CRT.
    At least, that’s how I did it for my internship in 2001…

    1. GPIB is great for control, automated test and collecting data from older instruments but is way overkill if all you need is a screenshot for a document, blogpost etc. so this is a pretty cool solution (though I have a feeling I’ve seen it or something very similar elsewhere, maybe even on HaD)

      1. This blog post is not one specifically about Fake Printer, but a more generic one about different ways in which I capture and convert test equipment screenshots.

        However, in many of the methods I use Fake Printer, which is one of my earlier projects and blog posts, and one that has been featured on Hackaday as well.

    2. If you’re interested in the pure data for visualization or post processing, GPIB is the way to go. But for my blog posts, I usually want screenshots: they look way cooler. :-)

      Also, there is absolutely no standard to transfer GPIB data: for each instrument, I would need to Google or write a script. The screenshots generated by old and new test equipment are all transmitted by some know standard format. Some those, like HPCL and PostScript, are quite a pain to convert to bitmaps, but one reason why I wrote this blog post is as a notebook to myself to remember the recipes of doing so.

    1. To me it looks very much like the motivation was created in reverse. There are quite a lot of DIY options for GPIB / IEEE-488 from various sources There are some on Hackaday and EEVblog, some also have sourcecode on publicly available GIT repository sites. It looks like OP already made a simpler printer adapter, and he also has a few “official” GPIB interfaces, so he never had a reason to dive deep into the DIY market. But on the other end, I won’t be surprised if some of the DIY projects are better maintained and work more reliably with an equipment mix from different manufacturers ten the “official GPIB interfaces, from one of the well known brands”. I assume the latter are only interested in support for their own brand of equipment.

      But overall, making screenshots of scope screens is often 90% of what people want to connect to their oscilloscope for, and this seems quite a nice solution for this.

  2. I totally found one of them old polaroid cameras in a cupboard at work a few years ago.
    There’s also the draw with the usb floppy drive (in iMac translucent plastic) and disks for some slightly less ancient machines from 90s to early 2000s and small usb drives for test equipment from the 2000s.

  3. Funny to see symptoms like this:

    I’m able to talk to the device and send commands like “*IDN?” and get a reply just fine,
    but the GPIB script that works fine with the TDS 540 always times out eventually.

    I’d had similar problems with my GPIB adapter (another one of many hand-made designs: https://github.com/T3sl4co1l/GPIBSerial ) — mind, at best vaguely so, given they don’t go into detail here, or try to debug their issue — but, based on hand-prodding my adapter via PuTTY, I seemed to need an extra +read once in a while. Maybe this is itself a sign of underlying link bugs, I don’t know, but it always seemed to work, hacking it along in this way. Along with some setup and detection adjustments, and holdoff delays, I automated reading screenshots from my TDS460 into this little app: https://github.com/T3sl4co1l/tekcap (Yes, written in C; how cursed…) Which, in addition to nudging along a stalled download, also happens to treat the end of a download as a stall, amusingly “shaking the last drops off” when it’s done…

    Still haven’t gotten around to making an analogous app for the spectrum analyzer, or for waveform download (I just copy-paste it out of PuTTY when I need to…), or config/setup or other automation; hasn’t been enough need for that. Nice to have the tools handy for if/when I do need it though (i.e., cables, adapter, toolchains; and, KE5FX tools are indeed excellent for the spec’s HPGL output).

    1. Sometimes (with the National Instruments and Prologix adapters at least) you can use a +command to set/increase the transfer timeout to handle the 100x as long transfer times for screenshots without crashing/stalling. That might do something similar to your +read. I wrote a python script to do this with my prologix and it was a lot of adapter setup beforehand before I could get the HPGL out in one uninterrupted/complete file.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.