Re: Intermittent IR printing problem from HP 50g
Message #5 Posted by James M. Prange (Michigan) on 13 Mar 2007, 8:31 p.m.,
in response to message #1 by Steve Pence
Hi Steve,
As Bruce noted, communication with the 82240A/B printers is
entirely one-way; the printer is unable to tell the calculator
anything about its status, which leads me to expect that the
problem is with the calculator, not the printer.
Which ROM revision are you using in your 50g (execute the VERSION
command to find out)? I'm not aware of any bugs that should affect
printing, but in general, if you haven't already done so, then I
recommend upgrading the 49G, 49g+, and 50g to either the official
2.09
revision or to
Bernard
Parisse's 2.10-7 revision.
Which printing commands are you using, and are you printing text,
column graphics escape sequences, or grobs (graphic objects, which
the calculator encodes as column graphics for printing)? How long
are your print jobs?
As Les noted, the range for IR printing is drastically reduced
with the 49g+ and 50g (and, I expect, the 48gII as well). This has
to do with an intentional reduction of both the IR transmit power
and IR receive sensitivity to result in a non-compliant IrDA range
of only about 100mm (4 inches), to assure the educational
community that it won't be used for surreptitious communications.
In the 48 series, only the IR receive sensitivity is intentionally
reduced for this purpose. Experimentally, the 49g+ and 50g IR
printing range seems to be only about 2 1/2 inches (maybe
60-65mm), but this may well depend on the condition of the
batteries in both the calculator and printer. Be sure to align the
little triangle at the top of the calculator's display cover with
the printer's IR receive window.
Does the printer occasionally print what looks like a solid block
character? That would (except for character 158 in the ECMA 94 set
or character 252 in the Roman 8 set) indicate that the printer
received a byte with an uncorrectable error, usually due to a weak
or briefly interrupted IR signal, but possibly due to interference
from some other IR signal (such as from an IrDA transmitter), or
conceivably from a problem with the calculator's encoding or the
printer's decoding of the byte (including its error correction
code bits).
The calculator can (after sending up to the first 200 bytes)
insert a delay between sending lines to give the printer time to
free up some room in its 200-byte input buffer before sending more
bytes. With the 48 series, the default delay (in seconds) is 1.8,
but with the 49 series (49G, 49g+, 48gII, and 50g) the default
delay seems to be 0 (usually appropriate for printing "via wire").
Try changing the delay to 1.8 seconds by executing 1.8 DELAY (or
by editing the first element of the list stored as the reserved
variable PRTPAR, or by editing the delay in an input form), or if
you're using an external power supply for the printer, a delay of
about 1.1 should be okay.
With a fresh battery in the printer, you can get away with a delay
of less than 1.8, but of course when using the battery only (no
external power supply) the print speed goes down as the battery is
used up, so the delay would need to be increased. Basically, with
a long print job, near the end of the printing, you want a slight
delay between the lines of printing.
If you use the printer only for printing grobs or character
strings of column graphics escape sequences, a delay of 0 should
be okay because a full line of column graphics (170 bytes total)
prints in about the same time as a line of text, and the IR print
transmitting speed is only about 78 bytes per second.
Of course, if you send 200 bytes or less in each print job and let
the printer finish before sending anything else to it, then the
delay doesn't matter.
Does the calculator sometimes print a character that looks like a
block with a white slash through it? That would indicate that it
experienced an input buffer overflow, usually caused by having the
delay set too low, but conceivably from missing a "linefeed
character" (control code <10> or <4>) that would tell the printer
to print out whatever's in its buffer.
Yes, there is an escape sequence to tell the printer to start a
repeating self-test (unlike the self-test by holding down the
paper advance button when turning the printer on, this self-test
repeats until the printer is turned off or the battery goes dead,
whichever comes first). Where <n> represents a character with the
decimal value n, the sequence is <27><254>. A program to send this
to the calculator would be:
%%HP: T(3);
\<<
27 CHR
254 CHR
+
PR1
DROP
\>>
But note that although this built-in self-test checks such things
as the print mechanism, at least some of the built-in font, the
power supply, and that it correctly received those two bytes, I
doubt that it thoroughly exercises the receiving circuits and
input buffer.
For more information about the printers, see the
HP
82240B Infrared Printer Technical Interfacing
Guide, and, of course, the Owner's Manual,
available on the current MoHPC CD-ROM set / DVD-ROM; see
http://www.hpmuseum.org/cd/cddesc.htm. There's also some
interesting background information and diagrams in the October,
1987 HP Journal, also available on the CD-ROM set / DVD-ROM.
Regarding the problem with the paper advance button, as Les noted,
it might be possible to fix that, although it's been a long time
since I've taken one of these printers apart and don't recall how
accessible the switch is, or what kind of switch it is. I'm pretty
sure that the screws are hidden under the little rubber "feet" on
the back of the case, and it seemed to me pretty easy to take it
apart and put it back together without any damage, except possibly
in getting the rubber feet to stick again.
Please let us know about any success or failure you have in
solving the problem.
Regards,
James
|
Go back to the main exhibit hall