mcba@newt.phys.unsw.OZ.AU (Michael C. B. Ashley) (10/19/90)
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
ttl@sti.fi (Timo Lehtinen) (10/21/90)
In article <900@usage.csd.unsw.oz.au> mcba@newt.phys.unsw.OZ.AU (Michael C. B. Ashley) writes: >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. Just for the record, we had exactly this same problem when printing from a DS2100 to a Ljet III (with Adobe PS cartridge). Hooking the printer to a VAXstation 2000 that we had lying around solved the problem. Both machines run ULTRIX V4.0 - it appears to be hardware based (or device driver). I thought the problem was related to the infamous DS2100/DS3100 -serial port problems and figured that when we get our DS5000 it would be fixed... Your experience seems to indicate that the situation is worse than expected. Does any know if this is a known problem with ULTRIX/RISC or the HW ? Timo -- ____/ ___ ___/ / Kivihaantie 8 C 25 / / / SF-00310 HELSINKI, Finland ____ / / / Phone: +358 0 573 161, +358 49 424 012 Stream Technologies Inc. Fax: +358 0 571 384
grr@cbmvax.commodore.com (George Robbins) (10/23/90)
In article <900@usage.csd.unsw.oz.au> mcba@newt.phys.unsw.OZ.AU (Michael C. B. Ashley) writes: >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. Does the LJ have a setting for the the control/s threshold? There's no particular guarantee that control/s stops transmission after only one or two characters and you may need to jack up the threshold appropriately. On the other hand, the Ultrix driver could be broken... > > Just for the record, we had exactly this same problem when printing from > a DS2100 to a Ljet III (with Adobe PS cartridge). Hooking the printer to > a VAXstation 2000 that we had lying around solved the problem. Both machines > run ULTRIX V4.0 - it appears to be hardware based (or device driver). I > thought the problem was related to the infamous DS2100/DS3100 -serial port > problems and figured that when we get our DS5000 it would be fixed... Your > experience seems to indicate that the situation is worse than expected. > > Does any know if this is a known problem with ULTRIX/RISC or the HW ? > > Timo > > -- > ____/ ___ ___/ / Kivihaantie 8 C 25 > / / / SF-00310 HELSINKI, Finland > ____ / / / Phone: +358 0 573 161, +358 49 424 012 > Stream Technologies Inc. Fax: +358 0 571 384 -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
mcba@newt.phys.unsw.OZ.AU (Michael C. B. Ashley) (10/25/90)
In article <900@usage.csd.unsw.oz.au>, I wrote: > 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. I have now examined this problem quite carefully using an RS-232 analyser, and have reached the following conclusions: (1) The DS5000 will output anything from 10 to 256 characters from its serial port (at 9600 baud) AFTER receiving a control-S. The number of characters sent depends on the :fs and :fc options in the /etc/printcap file (cooked mode gives you between 10 and 50 characters over-run, cbreak gives about 50, and raw (if you do the handshaking yourself) gives you up to 256 characters). (2) After receiving a control-S, and after the DS5000 eventually stops sending characters, it may then send a control-S to the printer (if the DS5000 input buffer is filled and if TANDEM mode is selected), and when it does so it SENDS A FEW ADDITIONAL CHARACTERS. I only observed this once, but it is a serious bug. (3) The LaserJet III will only accept about 30 characters after it has sent a control-S to the DECstation. Any more than 30 characters will result in an IO CONFIG ERR, and characters will be lost. This is hopeless. Incidentally, I am using the HP with the HP PostScript cartridge. So, in summary, both devices are at fault: the DS5000 for not responding to a control-S within a reasonable time, and the LaserJet for not being able to buffer a reasonable number of characters after receiving a control-S. Is there some easy solution to this problem that I have missed? As I mentioned in my earlier posting I have tried writing my own printer filter and doing the I/O a byte at a time, but when I ask the kernel if there are any characters for me to read from the printer (by using a ioctl(1,FIONREAD,&bytes_to_read);) it replies "no there aren't" even if some have been seen by the hardware and are filtering their way up through the operating system. Also, I'm not convinced that the call write(1,char,1) is returning after the character is physically emitted from the serial port, rather than after the character has vanished far enough into the kernel that it is guaranteed to be printed (note that I am using fcntl(1,F_SETFL,FSYNCRON)). I would rather be doing astronomy than messing with this annoying problem :-) Thanks for any advice. Michael Ashley / Dept. Astrophysics / Uni. of NSW / Australia mcba@usage.csd.unsw.oz.au