Path: utzoo!attcan!uunet!munnari.oz.au!metro!usage.csd.unsw.oz.au!newt.phys.unsw.OZ.AU!mcba From: mcba@newt.phys.unsw.OZ.AU (Michael C. B. Ashley) Newsgroups: comp.unix.ultrix Subject: serial port on DS5000 not responding fast enough to CNTRL/S? Keywords: LaserJetIII Message-ID: <900@usage.csd.unsw.oz.au> Date: 19 Oct 90 06:08:18 GMT Sender: news@usage.csd.unsw.oz.au Lines: 43 I have a LaserJet III connected to one of the serial ports on a DECstation 5000. My problem is that when I send long files to the printer, it loses about 30 bytes every time the LaserJet's input buffer fills up. What I think is happening is that the LaserJet is sending a control/S to the DS5000 to tell it to stop sending output, and the DS5000 doesn't take notice of the control/s until it has sent another 30 bytes. Unfortunately, the LaserJet doesn't appear to be able to buffer those additional characters (despite having a ~60,000 character input buffer). For the record, here is my entry in /etc/printcap HP|HP LaserJet III:\ :lp=/dev/tty01:\ :br#19200:\ :fc#0177777:fs#01:\ :xc#0177777:xs#040440:\ :sf:sh:rw:\ :sd=/usr/spool/HP:\ :of=/usr/lib/lpdfilters/xf:\ :lf=/usr/adm/lpd-errs: Interestingly, the number of bytes lost (~30) doesn't depend on the baud rate (so it sounds like it is some sort of buffer which is being emptied). I have tried every conceivable combination of fs# and xs# modes, and have also tried writing my own version of the xf filter which captures all the characters sent by the LaserJet (using fs# = raw mode) and implements XON/XOFF flow control itself. I had some success with this if I send a byte at a time (using FSYNCRON mode to synchronize writes) and then wait long enough for any bytes sent by the LaserJet to be recognized by ioctl(1,FIONREAD,&bytes_to_read), but this seems like a kludge. I have had a logic analyser and a CRO hanging off the serial port and am still not clear on what is going on (my logic analyser isn't very good with RS232...). Surely there is some simple answer to this problem. Surely the LaserJet should be able to handle an extra 30 bytes after accepting 60,000. Can someone help with some suggestions? Thanks Michael Ashley Astrophysics Dept., Uni. of NSW, Australia mcba@usage.csd.unsw.oz.au