LAUGHTON
ELECTRONICS

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

This story describes a
scheme to
elicit certain desired behavior from a high-resolution inkjet printer.

A top view of the HP, with the MSP430 wired into its nervous system.
This printer
has been assimilated by the Borg!

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.