[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
more on printer problem
- To: firstname.lastname@example.org
- Subject: more on printer problem
- From: email@example.com (Richard A. Munoz)
- Date: Thu, 28 Mar 1991 17:40:03 -0500
- Cc: firstname.lastname@example.org
- In-reply-to: David R. Strip's message of Thu, 28 Mar 91 11:55:14 -0700 <9103281855.AA03681@gnome.local>
Date: Thu, 28 Mar 91 08:24:06 PST
I am attempting to move picasso (lgp3) from bliss to cheer.
I changed the printer host entry, spooled printer
entries in both hosts, removed printer-queue-control,
printer-control, and hardcopy entries from bliss and
added them to cheer. Also added the print spooler entries
to cheer, etc. I then attached the SAME printer cable that
had been attached to bliss to the serial port on cheer
(bliss is a 3650, cheer an xl1200). WHen I fire everything
up (reboot to be sure that I am seeing the new entried, load
the print system,...) , cheer complains that picasso
doesn't seem to be responding.
If I disconnect the cable, the complaint changes to not
attached. If I reset all the changes, and rewire to bliss,
I can print.
SO --- what gives? Any suggestions for the next step in
tracking this down? Could the serial port on the xl1200
be flaky (never had occasion to use it before, so I don't
know if it works). Seems strange that the host can tell that
the printer is there but not responding vs. not there at all
when the cable is removed.
I'm working from memory, but here's my take:
What kind of serial options do you have set on the
printer object? I ask this because the default serial
options on the XL1200 are different than on the 36xx.
Specifically, I believe xon/xoff is not on by default.
You should probably have the following serial options:
NUMBER-OF-DATA-BITS 8 PARITY :NONE XON-XOFF-PROTOCOL YES
If this doesn't work, try number-of-data-bits 7 parity :even.
The 8.0 site operations has some info on this, although it
may not be complete. Also, printer objects are very sensitive
to how serial options are specified. Uppercase everything and
use Yes and No instead of T or NIL. (This is mainly superstition.)
"Printer not responding" errors occur when the LGP3 (or LGP2)
does not "sync" with the process controlling the printer serial
stream. "syncing" takes place when the printer stream object
sends an "EOF" character to the printer and expects one back
with a certain time period (2 minutes.) Syncing takes place
all the time, including when the printer stream gets instantiated.
Usually this problem occurs for one of the following reasons:
- The printer is wedged and hence not responding
- The printer has been switched to another port (e.g. Appletalk)
- The cable is not a null modem cable.
- The printer is very busy at the time
- The serial options on the lispm don't match the printer's option
setting. (e.g. Printer object says 9600 baud but the printer's
dip switches are set for 1200 baud. Also, this could happen if
the printer object relies on the default serial option settings
which may be incorrect.)
- The serial cable is too long or broken
- The lispm's serial port is broken.
- The serial code on the lispm got screwed up (e.g. patched
There's always a chance you found a new bug in the printer or
serial line support code.
"Printer not connected" errors occur when the lispm serial
line does not have a signal on the carrier detect or CD (8?) pin
(on a DB25.) I.e. the lispm printer support uses the CD pin
to recognize if a serial printer is attached. If you want to
turn this off, put DTR-VALID NIL in the user property of
the printer object.
Date: Thu, 28 Mar 91 11:55:14 -0700
From: email@example.com (David R. Strip)
When we last visited with our hero he had just
received some advice to try. The namespace problems
were a no-op - he had rebooted before trying anything.
As to the null modem vs. none, that has now been tried,
and the result was that without the null modem, life
was worse than before.
Yep. A null modem is a must, including having the CD
pin on the lispm side be connected to DTR or CTS on the
Now we try not loading the print spooler, just printing to the
device. Within moments of the Hardcopy file command a page
appears with the words "Error: ioerror". The screen flashes
and a function 0-s brings us a window that declares that the
printer did not respond to an EOF marker. A subsequent attempt
yields serial unit 1 locked.
The locking of the serial unit is a secondary effect (although a
bug in itself.) Are you running something before 8.0.1? Several
cases of the serial unit locked problems have been fixed in that
release. Divide and conquer.
Still looking for something to try the loopback test suggested.
More input from the folks in the audience?