NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/sys/sgi/16638

Text File | 1992-11-18 | 4.1 KB | 72 lines

Newsgroups: comp.sys.sgi
Path: sparky!uunet!ornl!rsg1.er.usgs.gov!darwin.sura.net!zaphod.mps.ohio-state.edu!usc!news.service.uci.edu!ucivax!zardoz.cpd.com!neil
From: [e-mail] (Neil Gorsuch)
Subject: Re: Printer Parallel port misery
Message-ID: <BxxuEs.7Fz@zardoz>
Sender: news@zardoz (usenet news administrator)
Organization: Uninet Peripherals, Inc.
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 19 Nov 1992 00:52:03 GMT
Lines: 60

In article <[e-mail]> [e-mail] writes:
>In article <[e-mail]>, [e-mail] (Joe Elliott) writes:
>- I have been having problems with printers for some time now. All of them
>- with PostScript printers and parallel ports.
>- Things are great for small print jobs but given a reasonable load, the port
>- just stops and the jobs keep queueing up.
>Cannot really be Xon/Xoff, as the normal Centronics printer protocol is
>simplex - i.e. printer cannot drive port, so cannot send (ascii text) information
>back to the computer. PostScript printers sometimes give you messages.

I don't know exactly what kind of hardware the computer is using for
it's Centronics interface, but here is some general information that
might be helpful.

A Centronics interface uses 1 output signal and 2 input signals for
output data flow control.  There is an output strobe line that is
pulsed by the computer interface every time a new byte is available on
the data lines, an input acknowledge line that is pulsed by the
printer when the byte is read from the data lines by the printer, and
a busy line that is asserted by the printer when it is not ready to
accept another byte yet.  There are other signals for status such as
paper empty and printer fault, but they normally don't come into play
for output throttling.  Before another byte is placed on the
Centronics data lines by the computer, it is supposed to wait until
the busy line is clear, and also until the previous output byte (if
there was one) was acknowledged by a pulse on the acknowledge line.
On our Centronics interface, we have seen 2 ways that things can
"hang" when in output mode:

1. If the computer Centronics interface is a lot faster than the
printer Centronics interface, and the Centronics cable is not very
good (most aren't and have lots of capacitance and cross-talk) or are
not terminated very well at either end, a false acknowledge pulse can
be seen because of cross-talk/ringing, and the busy signal assertion
will be delayed long enough that another byte will be sent out first.
Then because the printer wasn't ready for the second byte, it ignores
it and will never acknowledge it and the computer interface will wait
forever for the acknowledge pulse.  There is no good way to put an
arbitrary timeout value either, because of the widely varying amounts
of time that a printer can wait to acknowledge an output byte.  This
situation can be fixed by a better cable.  In our interface, the
output cycle is slowed down by default and needs a software switch to
be set to go into higher speed mode.  This way it will usually work in
the default case of a marginal Centronics cable.

2. A lot of Centronics computer interfaces simply ignore the
acknowledge pulse and only use the busy signal for output throttling.
They can get away with this in almost every case, since almost every
printer interface has a hardware latch that sets the busy signal true
when a the strobe pulse is seen.  The latch is then cleared by the
printer's firmware when the data byte has been read.  Our older models
did this, and if there was a Centronics cable with a lot of
capacitance, the busy signal would take so long to be seen in the
computer interface that it would send out another byte prematurely,
and everything would hang again.  The only cure in that case was a
better Centronics cable.
--
Neil Gorsuch  INTERNET: zardoz!uninet![e-mail]  UUCP: uunet!uninet!neil
MAIL: 17981 Sky Park Blvd., Suite O, Irvine, CA, 92714  PHONE: [phone]
Uninet Peripherals, Inc.                                FAX: [phone]