William A Friedman (will...@popd.ix.netcom.com) wrote:
: I am trying to attach a Fujitsu DL 1200 dot matrix printer to a
: DigiChannel C/CON 16 board, but I cannot get anything to print. I can
: track the data through the spool and out the digibox, but the printer
: does not start.
This is a recycled posting from Jan 95. There was some
controversy over some of this, but I forgot to update it.
>Subject: Re: Serial Printer Problem with SCO Unix/Digiboard
>Newsgroups: comp.periphs.printers,comp.unix.sco.misc
>Followup-To: comp.periphs.printers,comp.unix.sco.misc
>References: <4ra6un$
...@news2.ios.com>
>Organization: COmmittee to Maintain an Independent Xenix
>Distribution: inet
Scot Desort (sdes
...@gsmicro.com) wrote:
: I have a client running SCO Unix. They currently have both a Equinox
: serial board, and a Digiboard 16EM.
You didn't say which Digiboard, which SCO operating system,
what version, and which printer. There are a few things
that need to be done to make a serial printer and a Digiboard
handshake properly.
1. The digiboard manual will show the correct cable wiring
for various connector combinations and and flavours of flow
control. A similar (but not identical) wiring diagram is shown
in the OS5 "SCO OpenServer Handbook" Pp 336.
Basically, you do NOT need bi-directional flow control to run
a serial printer. The computer is much faster than the printer
and the printer need only inform the computer that it's
ready to accept data. Most dot matrix printers do about
240 chars/sec. Speeds over 960 chars/sec (9600 baud) are
wasted.
2. The Digiboard drivers include print spooler scripts.
They are usually buried as /usr/spool/lp/models/*.digi.
The major change is the additions of the line:
stty -ixany 0<&1
to the end of the script which guarantees a buffer flush.
If your print jobs chop the last few lines or each job, you
need this tweak. Another way to flush the buffers is:
/usr/spool/lp/bin/drain.output 5 (5 second wait).
3. It is necessary to convince the serial port to run at
a specified baud rate and with a specified flow control.
The spooler script does not need to be supplied with these
parameters if you use the Digiboard supplied "ditty" program
which permanently fixes these parameters. (Note: the
"standard" spooler script has all kinds of stty options
built in and available with the lp -o[option] parameter.)
The OS5 manual suggests you edit /etc/rc2 or /etc/rc2.d/P88USRDEFINE
file to include the line:
stty stty_settings < /dev/ttyXX
with the settings for unidirectional CTS handshake:
stty 9600 -ixon -ixoff -clocal ortsfl rtsflow ctsflow
or for unidirectional DTR handshake:
stty 9600 -ixon -ixoff -clocal -ortsfl -rtsflow ctsflow
I don't like these because any subsequent stty command to this
tty port will change the settings. Instead, I use:
echo "Setting hardware flow control on digiboard ttyI11 ttyI12 ttyI13"
/usr/bin/ditty -n /dev/ttyI11 9600 rtspace ctspace -fastcook
/usr/bin/ditty -n /dev/ttyI12 19200 rtspace ctspace -fastcook
/usr/bin/ditty -n /dev/ttyI13 19200 rtspace ctspace -fastcook
This gives me bi-directional flow control on all my serial
ports. (Actually, only ttyI11 is a printer. The rest are
modems). Note that you should use the upper case "modem
control" tty port in order to get hardware handshaking.
Digiboard will do hardware flow control with both the modem
and non-modem device name, but there is no guarantee that
all serial ports will do the same. You're safe with the
modem control (upper case) device name. You should also be
sure that both the modem or non-modem control port is
disabled. Run:
disable ttyi11 ttyI11
to be sure. Verify that you have hardware flow control
(ctspace and rtspace are on) and the correct baud rate with:
ditty -a -n /dev/ttyI11
4. If software flow control is desired, you only need 3 wires
in the serial cable. There is no "sticky" ditty command so
a different strategy should be employed. Add this line to
your /etc/rc2.d/P88USRDEFINE file.
(stty 9600 ixon ixoff -ixany ; while : ; do sleep 3600; done) < /dev/ttyi11 &
This will leave the port open with the parameters specified.
The advantage of this is that the spooler script doesn't
open and close the port for every job and that simple commands
like:
cat filename | /usr/lib/lponlcr > /dev/ttyi11
will work and properly handshake.
As with hardware handshake, verify the baud rate and settings with:
ditty -a -n /dev/ttyi11
or:
stty -a < /dev/ttyi11
5. You're not done yet. Certain printers fail to appreciate
the wisdom of the default stty parameters and need additional
help from the spooler script. For the HP laser printers, I use:
stty 38400 cs8 opost onlcr nl0 cr0 bs0 vt0 ff0 tab3 0<&1
in the "HP Laserjet, Thinkjet or QuietJet" script for a parallel
printer. My guess is a serial printer using xon/xoff handshake
would look like:
stty 9600 ixon ixoff -ixany cs8 opost onlcr nl0 cr0 bs0 vt0 ff0 tab3 0<&1
6. Now that you've RTFM, configured, hacked and tweaked the
printer, serial port and system, some clue as to testing would
be helpful. Buy a "breakout box" or a double DB25 with lots
of lights so you can see the action. Send the serial printer
a large job and hit the "on-line" button to "off-line".
The data should stop spewing from the computer to the printer.
Put the printer back on-line and it should continue belching
data. If you're running hardware flow control, you should see
the CTS lite change state when toggling on/off line.
Good luck.
[x] Email to author [ ] To mailing list [x] Posted to newsgroup
--
# Jeff Liebermann Liebermann Design 150 Felker St #D Santa Cruz CA 95060
# 408.336.2558 voice wb6ssy@ki6eh.#cenca.ca.usa wb6ssy.ampr.org 44.4.18.10
# 408.699.0483 digital_pager 73557,2074 cis [don't]
# je...@comix.santa-cruz.ca.us http://www.cruzio.com/~jeffl