mark@drd.UUCP (Mark Lawrence) (07/15/88)
I'm *trying* to hook up an NEC LC-890 SilentWriter PostScript Page printer to our Sun 3/260 (running SunOS 3.5, thank goodness!) on /dev/ttya. The line for the port in /etc/ttys looks like thus: 0zttya The entry for 'z' in gettytab looks like thus: z|std.19200|19200-baud:\ :sp#19200: The /etc/printcap for the printer looks like thus: lp|lw|ps|PostScript:\ :lp=/dev/ttya:br#19200:rw:\ :fc#0000374:fs#0000003:xc#0000000:xs#0040040:\ :mx#0:sf:sh: The printer is set up through an LCD menu system and is set thus: RS-232 interface 19200 baud 8 data bits 1 stop bit space parity XON/XOFF flow control Communications between the Sun and the printer work nominally, that is, I can send trivial postscript files (when the printer is in postscript mode) and plain ascii files (when the printer is in its HP LaserJet emulation mode) and I get good hardcopy. I run into problems when sending multiple pages (large amounts of bytes) to the printer. Sometimes one or two pages will get printed and the rest of the output gets sucked into some black hole. I've tried the following actions to figure out what's going on: I switched the interface speed to 1200 (changed the entry in ttys and printcap; sent HUP to init, killed and restarted lpd, changed the selection on the printer). I was able to get many more pages out but ALOT slower. Still not totally reliable output. This led me to believe that perhaps flow control was not working properly. The combination of flag and local mode bits in the printcap were suggested by Frame in the Installation section of their Reference Manual when utilizing a PostScript printer without Transcript. I've studied the tty(4) man page and all looks sensible. What I don't know is whether to trust what /usr/5bin/stty is telling me about that port after refiring up the lpd. It says: }112 drd:/etc# /usr/5bin/stty -a < /dev/ttya }speed 19200 baud; line = 0; intr = ^c; quit = ^|; erase = DEL; kill = ^u; }eof = ^d; eol = ^`; swtch = ^z }parenb -parodd cs7 -cstopb -hupcl cread -clocal -loblk }-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl -iuclc }ixon ixany -ixoff }isig icanon -xcase echo -echoe echok -echonl -noflsh }opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel I *think* it's saying that even parity is turned on and ignore parity is set and that xoff is off. The man page fails to mention what ANY of these codes mean. I tried switching to the DTR (hardware) mode of flow control by clearing the TANDEM bit in the flag in the printcap and selecting DTR at the printer. I killed and restarted the lpd. Is there anything else that I must do to make the tty recognize DTR and send DSR? Anyway, this action didn't help matters any. I tried sending the postscript patch to the printer that Frame supplies. It follows: ----------patch begins %! % This is the uart patch to fix timeout errors on the LaserWriter. % This is the 4/4/86 version of the patch. Earlier patches do not % work reliably most of the time. This one seems to work OK. 0000000000 % the exitserver password version (23.0) ne {(Patch not installed -- wrong printer type or version) = stop} if statusdict /Patch1Installed known {(Patch already installed -- not installed again) = stop} if serverdict begin exitserver statusdict /Patch1Installed true put currentfile eexec c3c703843e75cc772962e3a7fadee742bb1258167ac7020cbc1cdfd379c35f53 da38afaed75c86541fde979ff594180fe542991f2199c8614247e4a1e3e5ecff 8bc3844d36e2d091e9f649518473592b44be262c7a2929ac4a9acd626bd3c441 e2aae320e60b2c21e02bc9c4f3cde0d5eca674f5b0bbff3ee860a7cd2e4e9f7b 9eed9b1286e5a9b9b0fdf8e73951152837a16a6913e477cc8a4f3cebbf2e78e8 fe5b0f92d45a274e75df31e5182cd81dce61bc53bdb8685f0a7ce24c0b8440f7 67b7fd750bb998fc775415b1c7b8502ea7c744ccb807635f7244d3fdd6ebd01f 634c9f3241fddc1a95d62bfb710a9ea6831ec6e1792f60503f077868e860dc3a 518d8ac29dc625ec65157889cd1f943a37eb55ef0e44c3a4776a481f1dd10cda 79b3db9907295c0ab9e3142df3ef0840b07f29d67c4f8aba333c9cc6e9f57d3f 47083e0bd9e85151ef158308a7d991b02ddcf47bffe6fed2f8e342dd7d2f81ca 80bb689bd0cb5af2a471b5577a4f8dbdfd2b0fcd0267bfa4dc6038bc235d3d8b 35469a680b41dc95e6a1d48ba543d291575d72475ef512492547629c4db741b8 68705f01282c230e1570cea8daea989707e99dce1d11d561256bd24608a66945 2042384aadfcc25cb0167b5896b1a13092d0a7c4ce1343e30834de5d5df345b9 ccb742acf36f7d3a9b43361cf5a9e0121fec84ba8b6c06312a71600ab9783ddc 59b8cb4da03019e82690df5cb2aefd9026aed30efb24b19e5405410685eb35b3 b25cf8ba535156ee600749abf2e3c572313c62dcd9492ca3abcfe7ee8fd40410 902f417c82908b412c9a826206f4292ab5196013a5f3615661cf81fc60b36a84 f457c2adb1a0c1c19f089d170de47d6933ce247d44865035caa1a6d4a2f6986f 9856de5f3d05a5a1020bce9768df8e8aab928b90029dfc2bbb715e19b5e7bc3e 11f05c1dad24849f8aadb7867f9d92f4400a432cdd6587057c582dc25fbeadde f75121202e2a90dc6a4491ae9ee2b39c5fab5071a2f415d4a3cf8357fff771d8 790cc5788d506086c5a07ddbc2997f3abe28972cd40275c0117c77f479fd0b74 53a0bfcd82f30d1eb3c35fc914657d6f484bf3be81c54238267ccc2a19ec42a3 1336014c6446b12e3fe7746b658f829c52173a78e456ad78c2d65a3209949a5a 735d3795579151ee0102773c204134e8563b011a90c7cf0622058081c60b4d5d 6a146eb610c92e2e9c05f7ca40a1375e7c397def7f0d6a4c65e22728ae30adc2 b1b088339a7e7ab8f2dc6a3b5abd1318663cc5d3c37edd57f8ace64a565d1775 6e5a1268986105c918547306e0bf12d128220771e074323746ac15c52ef16e95 c0e62a0746b7c202a2e2aba2060cd64d5f656dbeb1fa837734d4a23093ddb312 537c0a6f8e224e5aa6cd22f1740e3611550b85d1a447c58ca8 ------patch ends Anyway, that didn't affect anything. I tried setting the CRMOD flag in the printcap and killing then restarting lpd. That didn't make it work better either. At this point I'm at a loss and all I've got is a vague suspicion that flow control is the culprit. I'm under the assumption that If I can print anything at all, XON/XOFF flow control should work regardless of whether pins other than 2,3,and 7 (Transmit, Receive and Ground) are connected or not. Isn't that so? I have tried both modes of flow control at line speeds of 9600, 4800 and 2400 also. Basically, the lower the speed, the more hardcopy you generally get but not reliably. Can you suggest anything I can do to make this interface work? Especially, can you tell me how I can verify that the tty is actually set in the modes I think I set it and how I force it to use hardware DTR/DSR if I so wished? Any boots here *much* appreciated. Mark -- DRD Corporation | [uunet!apctrc,romed,tulsun]!drd!mark 6111 East Skelly Drive Suite 415 | apctrc!drd!mark@uunet.UU.NET Tulsa, OK 74135 (918)664-9010 | mlawrence@jarsun1.ZONE1.COM +------------------------------------+--------------------------------------+
guy@gorodish.Sun.COM (Guy Harris) (07/16/88)
> lp|lw|ps|PostScript:\ > :lp=/dev/ttya:br#19200:rw:\ > :fc#0000374:fs#0000003:xc#0000000:xs#0040040:\ > :mx#0:sf:sh: The mode settings from your "printcap" entry say to: turn off EVENP, ODDP turn off RAW turn off CRMOD turn off ECHO turn off LCASE turn on CBREAK turn on TANDEM turn on LITOUT Turning on LITOUT makes the setting of EVENP and ODDP totally irrelevant; it puts the hardware into 8 bits, no parity mode. It also makes the setting of CRMOD and LCASE irrelevant; both of those modes affect special processing of characters on output, but LITOUT turns off all that processing. Turning on TANDEM turns on XON/XOFF flow control *TO* the computer, so that if characters are sent *to* your machine faster than it can process them, it will try to send out ^S to stop the incoming flow. (The way this is implemented in the Version 7 and BSD tty drivers is that it sticks the ^S on the output queue; this means that if there's other output ahead of it it may not get out for a while. The S5 and 4.0 drivers let the ^S "jump the queue".) This looks like a reasonable set of modes for a laser printer such as that. > What I don't know is whether to trust what /usr/5bin/stty is telling me > about that port after refiring up the lpd. Given that you're not running 4.0, I would suggest that you trust what "/bin/stty" says instead. The native mode bits of the pre-4.0 tty driver are the 4.3BSD ones; the S5 one emulates them. > It says: > > }112 drd:/etc# /usr/5bin/stty -a < /dev/ttya > }speed 19200 baud; line = 0; intr = ^c; quit = ^|; erase = DEL; kill = ^u; > }eof = ^d; eol = ^`; swtch = ^z > }parenb -parodd cs7 -cstopb -hupcl cread -clocal -loblk > }-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl -iuclc > }ixon ixany -ixoff > }isig icanon -xcase echo -echoe echok -echonl -noflsh > }opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel > > I *think* it's saying that even parity is turned on and ignore parity is > set and that xoff is off. The man page fails to mention what ANY of > these codes mean. You must be looking at the wrong man page; you want either TERMIO(4) or STTY(1V). Those describe the S5 tty driver modes, as emulated by SunOS 3.x, or the S5 "stty" command to set and print them. TTY(4) and STTY(1) describe the V7/BSD tty modes, so it's not surprising that it "fails to mention what ANY of those codes mean" since they're not V7/BSD modes. However, if it *is* telling the truth, it's saying that the modes specified by the "printcap" entry are NOT in effect. It says "cs7" and "parenb", meaning it's set up for 7 bits plus a parity bit; if LITOUT were on, it should say "cs8" and "-parenb". It also says "-ixoff", meaning that TANDEM is off. Again, I would suggest /bin/stty everything >/dev/ttya to get the "native" modes; it is conceivable that there might be a bug somewhere in the S5 emulation that causes "/usr/5bin/stty" not to tell the truth, although I don't expect that to be the case (I just tried setting "tandem" and "litout on a 3.5 machine and running "/usr/5bin/stty -a", and it reported "cs8", "-parenb", and "ixoff"). > I tried switching to the DTR (hardware) mode of flow control by clearing > the TANDEM bit in the flag in the printcap and selecting DTR at the > printer. I killed and restarted the lpd. Is there anything else that I > must do to make the tty recognize DTR and send DSR? Anyway, this action > didn't help matters any. Well, that's not going to work; turning TANDEM mode off doesn't switch to DTR flow control. *Nothing* switches to DTR flow control; SunOS doesn't support it, so there's nothing you *can* do to make the tty recognize DTR as a flow-control line.
mark@drd.UUCP (Mark Lawrence) (07/20/88)
In article <60198@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) wrote: a lot of helpful things about termio, tty's and stty in order to help me figure out what the blazes is happening between and NEC LC-890 PostScript printer and my Sun 3/260. A large part of the problem was my naivete about how to properly use stty and system V cousin (unix tools are like a two-edged sword: parry and thrust and sometimes lop one's own foot off). Anyway, in my little over two years of experience with Unix, I never knew the following about how to use stty properly with serial ports that the line printer daemon deals with and thought it might be generally useful. >You must be looking at the wrong man page; you want either TERMIO(4) or >STTY(1V). Those describe the S5 tty driver modes, as emulated by SunOS 3.x, or >the S5 "stty" command to set and print them. TTY(4) and STTY(1) describe the >V7/BSD tty modes, so it's not surprising that it "fails to mention what ANY of >those codes mean" since they're not V7/BSD modes. It turns out that stty (1V) simply brings up stty (1) which of course mentions nothing about termio(4). tty(4) gives no cross reference either. Guy's pointer was invaluable. Another thing the man pages don't clue you into is the proper use of the < and > when using stty. With /bin/stty, the use is counter-intuitive, IMHP. I did not realize that the serial in port in question had to be queried *while* a print was in progress. Lpd evidently sets the port characteristics for every job and then resets them. I, of course, queried the port while it *wasn't* printing. Following the right method (and running the interface at 19200), I get: old tty, speed 9600 baud, 0 rows, 0 columns even odd -raw -nl echo -lcase -tandem tabs -cbreak -nopost -noisig -stopb erase kill intr quit stop eof ^? ^U ^C ^\ ^S/^Q ^D and new tty, speed 19200 baud, 0 rows, 0 columns -raw nl -echo -lcase tandem tabs cbreak -crtbs -crterase -crtkill -ctlecho -prterase -tostop -tilde -flusho -mdmbuf litout -pass8 -nohang -pendin decctlq -noflsh -nopost -noisig -stopb erase kill werase rprnt flush lnext susp intr quit stop eof ^? ^U ^W ^R ^O ^V ^Z/^Y ^C ^\ ^S/^Q ^D before and during the print job from /bin/stty. Also during the print, I get: speed 19200 baud; line = 0; intr = ^c; quit = ^|; erase = DEL; kill = ^u; eof = ^a; eol = ^`; swtch = ^z -parenb -parodd cs8 -cstopb -hupcl cread -clocal -loblk -ignbrk brkint ignpar -parmrk inpck istrip -inlcr -igncr -icrnl -iuclc ixon -ixany ixoff isig -icanon -xcase -echo -echoe echok -echonl -noflsh -opost -olcuc -onlcr -ocrnl -onocr onlret -ofill -ofdel from /usr/5bin/stty. I guess this is what is meant by learning the right incantation. Question: Is there a convenient way to monitor what is coming back from the printer to see if it is issuing any XOFF's so that I may eliminate flow control as the source of my problem? I'd like to verify that the tty driver is truly suspending output so that I can go back to the printer manufacturer and ask WTFO. Mark-- -- DRD Corporation | [uunet!apctrc,romed,tulsun]!drd!mark 6111 East Skelly Drive Suite 415 | apctrc!drd!mark@uunet.UU.NET Tulsa, OK 74135 (918)664-9010 | mlawrence@jarsun1.ZONE1.COM +------------------------------------+--------------------------------------+
guy@gorodish.Sun.COM (Guy Harris) (07/22/88)
> >You must be looking at the wrong man page; you want either TERMIO(4) or > >STTY(1V). Those describe the S5 tty driver modes, as emulated by SunOS > >3.x, or the S5 "stty" command to set and print them. TTY(4) and STTY(1) > >describe the V7/BSD tty modes, so it's not surprising that it "fails to > >mention what ANY of those codes mean" since they're not V7/BSD modes. > > It turns out that stty (1V) simply brings up stty (1) which of course > mentions nothing about termio(4). The manual page source we have - which is what should be in the on-line documentation, and should have been used to generate the printed documentation - has completely separate "stty.1" and "stty.1v" files, so either they were printed wrong (if you're referring to the printed documentation) or set up wrong on the distribution tape (if you're referring to the on-line documentation), or the "man" command (assuming that's how you read it) did the wrong thing or was told to do the wrong thing. Try "man 1v stty", giving the "1v" explicitly (there have been some problems with "man" giving the S5 man page by default, maybe on your system "man stty" gave the 4BSD page by default). STTY(1V) does refer to TERMIO(4V). > Another thing the man pages don't clue you into is the proper use of > the < and > when using stty. "Fixed in 4.0": DESCRIPTION stty sets certain terminal I/O options for the device that is the current standard output. Without arguments, it reports the settings of certain terminal options for the device that is the standard output; the settings are reported on the standard error. ... SYSTEM V DESCRIPTION stty sets or reports terminal options for the device that is the current standard input; the settings are reported on the standard output. > Question: Is there a convenient way to monitor what is coming back from > the printer to see if it is issuing any XOFF's so that I may eliminate > flow control as the source of my problem? I think there are hardware boxes ("line monitors" that do this), but they cost money (you may be able to rent one if you don't have one, but that still costs money...).
les@chinet.UUCP (Leslie Mikesell) (07/22/88)
In article <229@drd.UUCP> mark@drd.UUCP (Mark Lawrence) writes: > >Question: Is there a convenient way to monitor what is coming back from >the printer to see if it is issuing any XOFF's so that I may eliminate >flow control as the source of my problem? I'd like to verify that the >tty driver is truly suspending output so that I can go back to the >printer manufacturer and ask WTFO. > If you make sure that flow control is disabled on the port, you should be able to see them with a cat -v </dev/tty?? if you have read permission on the port. I run a little program that I wrote a while back to collect SMDR from our phone switch that just dumps all the input from a port into a file and starts a new file every night. There can be quite a bit of output from the printer (a timeout error from every job that doesn't end in ^D for one thing) which may be confusing your tty port if you have ixany set. Also be sure that the 890 is set for xon/xoff flow control using the front panel buttons. I have one running at 9600 baud on a 3B2 serial port using only xon/xoff. The only problem I have is with software that sends hardware initialization commands in the postscript prolog. Les
jaap@kunivv1.sci.kun.nl (Jaap Bril) (08/10/88)
We encountered a similar problem connecting a (non-postscript) printer to
a VAX with 4.2BSD.
It turned out that the ioctl-calls lpr did were faulty.
#
a5010c| ACCOUNTED printer :\
:lp=/dev/a5010c:\
:sd=/usr/spool/a5010c:\
:st=/usr/adm/a5010c/status:\
:af=/usr/adm/a5010c/acc:\
:if=/usr/adm/a5010c/filter:\
:lf=/usr/adm/a5016t/log:\
:xs#0000040:\
:pl#66:\
:py#67:\
:pw#96:\
:px#96:\
:tr=:br#9600:\
:sc:\
:sh:
#
We patched by putting in a driver (converter) wich did a setline:
#ifdef 4.2BSD
#include <sgtty.h>
/* these really should be in lpd */
setline()
{
struct sgttyb tty_sg; /* needed for an */
short int tty_local; /* 8 bit interface with xonn/xoff */
ioctl(1,TIOCGETP,&tty_sg);
ioctl(1,TIOCLGET,&tty_local);
ioctl(1,TIOCSETP,&tty_sg);
ioctl(1,TIOCLSET,&tty_local);
ioctl(1,TIOCSETP,&tty_sg);
}
#endif
MAybe this works for SUN too.
--
*Jaap Bril * mcvax!kunivv1!jaap *
*computer&communicatie zaken * *
*faculteit wiskunde en natuurwetenschappen * *
*KU Nijmegen, The Netherlands * *