Thanks for all the responses. The problem turned out to be an a partially
broken wire. When connected to the SS2 the wire was not under any stress
so things worked but with the IPC the wire was under stress and the IPC only
occasionally received the ^S. Anyways, here is a summary of the responses
that I received,
michael pearlman
----- Begin Included Message -----
Since Xon/Xoff is in band, it should work if the data lead from
the printer makes it to the sparc.
If the printer is postscript, try tip'ing to /dev/tty_whatever
and see if you and the printer can talk to each other by you
typing some simple postscript commands and seeing if the printer
answers.
If this fails (or your printer isn't postscript, and therefore won't
hold up its end of a conversation) try looping pin 2 to pin 3 on
the 25 pin connector coming from the IPC. Then tip to the tty
and any characters you type should echo back at you. If the
characters fail to echo, the cable or serial port is bad. If
the characters do echo, then it could be that the default tty
attributes are messed up on that port. This could be a function
of fc, fs, xc, and xs in /etc/printcap (see tha man page for
printcap for more info on these).
Hope some of this helps,
Ric (ric@cs.arizona.edu <Ric Anderson>)
----- End Included Message -----
----- Begin Included Message -----
Subject: Re: ALM-2 under SunOS4.1.1 on a 3/160-type machine? (SUMMARY)
Thanks to many (esp. Hal Stern). The essential checklist is:
(a) have you checked /etc/ttytab to make sure the ttyh* devices are
turned on, have gettys running, and have "local" set correctly
so that they will ignore the h/w carrier detect?
(b) do you have the mcp* devices configured into the kernel?
(c) do /dev/ttyh* exist?
(d) make sure you understand what ttysoftcar(8) is doing!
As it turns out, I had to do one extra little bit of "magic", rm'ing
/dev/mcp* and /dev/ttyh* and re-running
/dev/MAKEDEV mcp0
in order to actually get things running after a kernal rebuild (which
shouldn't have been necessary, I still don't understand why the rest
of this wouldn't work right until after I did that).
The important part, however, not just for ALM-2 (aka MCP) boards, but
for ALL serial lines, is to understand something about how ttysoftcar(8)
works. I'm still not sure I do, but here's what I think I know:
In general under SunOS4.1.1 it's not necessary to fiddle with kernal
rebuilds or even eeprom settings in order to turn on or turn off
carrier detect. What IS necessary is to properly declare the ports
in /etc/ttytab. If "local" is there, software carrier detection
is turned ON (and hardware carrier detection disabled). If the
entry reads anything else, software carrier detection is turned
OFF, all of that via "/usr/etc/ttysoftcar -a > /dev/null 2>&1"
command in /etc/rc.local.
If the device is not listed in /etc/ttytab, apparently it defaults
to the flags value in the kernal configuration and/or eeprom setup.
Having said all of that, I should also add that--under some conditions
still not completely clear to me--ttysoftcar may not always work.
In particular, in using it directly (e.g., ttysoftcar [-y|-n] /dev/ttymumble)
the command sometimes seems to hang. Also, having "remote" instead
of "local" does not always seem to keep software carrier detection
off. On several systems here with modems (e.g., on ttya), I've
found myself having to add:
/usr/etc/ttysoftcar -n /dev/ttya
..at the end of /etc/rc.local in order to actually get hardware
carrier detect.
Stefan Mochnacki <stefan@centaur.astro.utoronto.ca
----- End Included Message -----
----- Begin Included Message -----
Last week I experienced the same problem you describe. I was using a
QMS 410 printer off of an IPC. At first we thought there was a hordware
problem with the printer but soon realised the printer was fine.
Tracking the problem on the Sun side was difficult. To make a long
story short, we got fed up and decided to do a complete re-installation
of the OS. The IPC at the time was Sun perconfigured. I installed
SunOS 4.1.1 (same as before) and the mysterious printer problem
vanished. I can't say why, but the problem is gone and that's fine by
the owner.
If you find out exactly what causes the problem, I would like to here
about it. I still have copies of the postscript files that displayed
the problem and I plan to use them on the next IPC I get my hands on.
If you would like an idea of the hardware tests we went through,
contact "guy@davinci.concordia.ca" for more. I'm sure he'll be glad to
help.
I'll be eagerly awaiting your summary.
Nick Ayoub nicky@davinci.concordia.ca
----- End Included Message -----
----- Begin Included Message -----
Make sure the parity on the printer and the IPC
match as the driver might not strip parity before checking
if the incoming char is stop. Also set the DEC mode so
only ^Q will start it again. It will take the unit several
characters to stop and some printers send a ^S for each
character received after the high water mark on the receive
buffer is exceeded. If you have start on any set, the second
^S will cause the IPC to send another character, then see it wa
s a ^S and stop again, but the character sent will cause another
^S to arrive again, which will cause another character to be sent
..........
Lew Doll
led@mentor.cc.purdue.edu
----- End Included Message ----
----- Begin Included Message -----
You may want to try tying together the signals corresponding to Pins
# 4 and #5 in a standard D-25 RS-232 connector. Also run "eeprom" to
set the hardware hanshake signals off, and reboot.
Stefan W. Mochnacki INTERNET - stefan@centaur.astro.utoronto.ca
----- End Included Message -----
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:20 CDT