Print
quality was a constant concern with my client's Diablo daisy-wheel
printers. (See Diablo
Daisywheels: a devilish design
indeed)
And it wasn't just
an aesthetic issue. That's because some
of the printers were used for printing bank account numbers in
MICR machine-readable font. The strange looking MICR digits
and symbols
(a familiar sight on cheques) need to
be recognizable by
automated
equipment, and among other
requirements it's crucial that the
characters be printed at maximum density; ie, 100% black; not just
dark gray.
Daisy-wheel
printers are impact printers, and the image is produced by a print
hammer slamming an embossed petal of the plastic print-wheel against
a ribbon and onto the paper. Density is largely a function of hammer
energy, and the solenoid that drives the hammer is remarkably
powerful. But the Diablo wasn't designed for MICR characters, which are
substantially larger than ordinary text. Therefore we were pushing
the envelope, and always had a keen interest in maximizing hammer
energy.
Unfortunately it was hard to draw conclusions from our experiments. Running extra
current into the solenoid boosted quality, but adding mass to the
hammer made no decisive improvement. Frustrating our investigation
was the fact that the motion of the solenoid and hammer couldn't be
observed. Although it took place right before our eyes, the hammer
cycle was utterly invisible!
At 20 ms, it was much too fast to
see. I decided to put together a stroboscope and see what I could
learn about hammer kinetics.
the hardware
The
strobe light itself was no great challenge. I'd built them before,
for a factory that needed to inspect the printing being applied to
fast-moving electrical wire, notations such as “16 AWG
600V”. The
stroboscope principle is simple. The
subject is kept in darkness
except for selective illumination supplied by the strobe at specific
instants. Assuming that the
motion of the subject is repetitive
(eg;
the notation “16 AWG 600V” appears again and again)
and that the
strobe flashes are appropriately synchronized, then the human eye
will perceive the subject to be motionless. That's because the
flashes only reveal the subject at a given point in its cycle; the
remainder of the cycle is obscured by darkness. (A shutter can be
used to produce the same effect.)
In simple cases a stroboscope can just use an oscillator to
dictate timing for the flashes. But for the Diablos that approach wouldn't
suffice, and I put the strobe timing under microcomputer control. The
task was easily managed by one of my Forth computers, which
was part of my test setup anyway. The strobe program was just an adaptation
of an Exerciser program I routinely used for printer testing.
the software
The loop in my strobe program was not like an oscillator
that executes at a precise, periodic rate. That's because Diablo
latency is slightly variable, "latency" being the delay from the time
the Diablo receives a print-wheel (and hammer fire) command
to the time the hammer solenoid actual energizes. To counteract this
unpredictability I needed a timing reference; I connected a line
from the hammer-solenoid circuit back to the computer. At the heart of the software loop were four
main steps:
- issue the print-wheel/hammer-fire command to the Diablo
- wait for current to be applied to the solenoid coil
- starting from that instant, pause for an exact,
software-defined
interval
- pulse an IO pin to flash the strobe!
The delay interval was such that the strobe would flash while the
hammer was in mid-flight.
Prior to the loop's next iteration came some housekeeping chores. The
timing interval would be adjusted (usually increased slightly) by
adding a signed delta value to it. Then
there'd be a check to detect keystrokes on the computer keyboard, and
the entire loop would repeat. The repetition rate was furiously
fast, more than 40 hammer impacts per second.
observing the
hammer
During
these tests the printer sounded like a machine-gun barrage. But —
very much in contrast! — the stroboscopic image of the hammer had an eerie, peaceful
grace. By pressing keys on the computer keyboard you could cause the
apparent motion to speed up, slow down, stop or even reverse. (The
keys simply raised or lowered the delta value.) It was magical to be
able to watch the solenoid closing so lazily, and to see the hammer
go drifting in slow-mo toward its target. And, if the print-wheel had
been commanded to move, you'd see the tail end of that
motion
as well. That's
because
Diablo firmware overlaps the two actions, actually starting the
hammer launch before the print-wheel motor has finished swinging the
desired petal into place.
the results
At
last we had a window into the workings of the hammer and the
solenoid. It showed that the problem with hammer energy was more
complex than we had suspected.
We'd
overlooked a key consideration, obvious enough in hindsight.
Although
the stiff plastic arm of the solenoid armature seems absolutely
rigid, and although the hammer it propels weighs only a couple of
grams, nevertheless the arm gets stressed so violently that it
flexes
substantially. (The flex isn't shown in the accompanying animation.)
The bending occurs just as the solenoid gap approaches zero and the
magnetic
attraction skyrockets. At this point the solenoid armature
accelerates faster than the hammer it's propelling, and the
difference between the two motions is taken up by the elasticity of
the plastic arm. After the armature snaps to a halt against the magnet
there's a final burst of
energy released as the arm straightens out and
“flicks” the
hammer toward its target. (These components may be tiny, but the
g-forces applied are absolutely brutal!
It's no wonder the
process
is so noisy.)
If
it'd been possible to use an even stiffer arm then maybe we would've
been able to avoid the premature solenoid closing and deliver more of
the solenoid's peak force to the hammer. As it was, we never
achieved any great breakthrough in print quality. But certainly I
was successful in shedding some light on the subject.
|
