more on printer problem

[munoz@oberon.com (Richard A. Munoz)]

    Date: Thu, 28 Mar 91 08:24:06 PST
    From: "@IU.AI.SRI.COM:slug-admin@Warbucks.AI.SRI.COM"%HERMES@intel9.intel.com

    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
   incorrectly)

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: drstrip@gnome.cs.sandia.gov (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
printer side.

    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?