Printing On Thin Air: Lying to the machine, Case study #2

Laughton Electronics This story describes a scheme to elicit certain desired behavior from a high-resolution inkjet printer.
top view of the printer
A top view of the HP, with the MSP430 wired into its nervous system. This printer has been assimilated by the Borg!

carriage mechanism
This view shows some of the carriage and paper-feed mechanism. The large disk attached to the gear at the bottom left has a pattern of ridiculously fine lines near its perimeter, read by a pair of photocells. The disk and cells comprise a high-resolution encoder that measures the rotary motion of the paper-advance rollers. Also shown here is a linear encoder for the carriage motion; it uses photocells on the carriage to measure fine lines etched on the shiny metal band visible above the disk.

This article describes an instance of what I call "lying to the machine." The victim in this case was a Hewlett-Packard inkjet printer. The company who hired me wanted to incorporate that type of printer into a line of machines they were developing. The machines were for stamping images on merchandise such as poker chips and bottle caps; the images would download from a PC.

They intended their new machine to use a two-step process. Images would be printed on a transfer ribbon that threaded its way first through the inkjet and then to the product stamping station. But finding a suitable printer was a problem. Although sheet-fed printers come in all shapes and sizes, printers capable of using continuous media (such as a ribbon) tend to be professional-grade, wide carriage devices - expensive, and also far too bulky for the client's needs. So instead they turned their attention to an HP photo printer, a miniature sheet-fed unit."Can you," they asked, "trick it into printing on the ribbon instead of on photo paper?"

At first it didn't seem like any great problem. As an initial experiment I decided to try printing on nothing at all: no ribbon, no paper - nuttin'! After stripping the covers off the printer it was easy enough to locate a mechanical paper-sense switch; it was directly in the paper path near the feeder. But tripping this switch after the feed wheels actuated wasn't enough to convince the HP's embedded microcontroller that a sheet was present. Hmmm... The thing wasn't as gullible as I had expected!

Soon the real scope of the challenge became evident. There was an additional paper sensor, and it was mobile. It was a photosensor, mounted on the carriage next to the printhead.

The crucial point is this: Before printing anything, the carriage would make a few exploratory passes as the sheet arrived from the feeder, and the photosensor was expected to switch on and off in a predictable fashion as it observed the lead edge and the left and right edges of the sheet. Only then would the printing begin. It was a clever means to exactly register the sheet position, and also to insure the sheet wasn't crooked... but it completely thwarted my attempt to print on thin air! The photosensor signal — or a plausible facsimile — had to be present. During the exploratory passes the signal had to switch on and off in response to how the sheet was being scanned (horizontally) by the carriage and jogged (longitudinally, or "vertically") by the feed rollers.

I set about generating a facsimile of the missing signal. (Because the printer's program memory was inaccessible I couldn't disassemble the code and then bypass the unwanted paper sensing behavior.)

A tiny kludge board with a Texas Instruments MSP430 single chip microcomputer did a tidy job of creating the ersatz "photosensor" signal. This required some tracking of printer activity, starting with the command to the feeder. The MSP430 also had two pairs of inputs connected so as to eavesdrop on quadrature signals I'd reverse-engineered on the HP. One pair of signals came from a linear encoder that tracks the horizontal motion of the carriage. The other quadrature pair came from a rotary encoder attached to the paper transport rollers — ie; the longitudinal axis. Both encoders are visible in the lower photo, left. (You can click to enlarge almost any image on this site.)

The code I wrote for the MSP430 started by waiting for the feeder to actuate; then it began decoding the two pulse trains from the encoders in order to track horizontal and vertical position coordinates. Instant by instant the program decided whether the photosensor ought to be on or off; this was accomplished by repeatedly comparing the changing coordinates with hard-coded numbers I'd chosen to represent the edges of a virtual sheet of paper supposedly being surveyed.

An output pin on the MSP430 carried the fabricated on-off signal back to the HP's photosensor input. All the time, of course, the HP, too, had been tracking the coordinates, and every step of the way the MSP430 told it what it wanted to hear! By means of this deception I succeeded in printing on thin air, and the HP's embedded microcontroller was none the wiser.

This job illustrates an apt solution to the client's problem. Tight, assembly language coding is demonstrated, as well as effective interfacing between the MSP430 and the printer's logic circuits. Moreover, the entire project was undertaken without benefit of any sort of manufacturer training, schematics or documentation: all physical and functional details of the printer circuitry, as well as insights into the purpose and the principles of the sensors and firmware, were derived by reverse engineering.
Servicing the Unserviceable
extra (main index)
copyright notice (Jeff Laughton)