andrew@alberta.UUCP (Andrew Folkins) (07/26/85)
Does anybody out there have an HP Laserjet printer hooked up to their
PC/XT/AT? If so, does DOS notice when the printer hangs? The specifics :
IBM AT running DOS 3.0
HP Laserjet printer attached to COM1
In AUTOEXEC.BAT : MODE com1:9600,N,8,1,P (as given in printer manual)
MODE lpt1: = com1:
When ever I try to print a file more than about 3K the Laserjet overflows,
and DOS keeps on sending data. Experimentation has revealed that communication
over the com port is done with XON/XOFF protocol, with the Laserjet normally
sending an XON about once a second, and an XOFF when it dies. To get around
the problem, I wrote a short communications program which reads data from the
file and sends it to the printer over the com port (same parameters as above),
and pauses when it receives the XOFF (usually when the printer runs out of
paper).
I can't believe that the printer and DOS are incompatible, but aside from
slowing the PRINT command down to a crawl by increasing the timeslice size,
or writing my own print routine, there doesn't seem to be any way around this.
Any suggestions?
--
Andrew Folkins YABS : If you think education is expensive,
ihnp4!alberta!andrew consider the price of ignorance.johnl@ima.UUCP (08/01/85)
/* Written 7:46 pm Jul 25, 1985 by andrew@alberta in ima:net.micro.pc */ > Does anybody out there have an HP Laserjet printer hooked up to their > PC/XT/AT? If so, does DOS notice when the printer hangs? The laser jet seems to use all known forms of flow control, simultaneously. It sends xon/xoff, and also raises and lowers DTR. The IBM BIOS doesn't know anything about xon/xoff, but it slavishly follows DTR. If you're having flow control problems, most likely your cable isn't bringing the flow control signals through. The laser jet manual has a detailed picture of how the cable should be wired. Alternatively, there are lots of xon/xoff BIOS filters floating around. John Levine, ima!johnl
slerner@sesame.UUCP (Simcha-Yitzchak Lerner) (08/02/85)
> Does anybody out there have an HP Laserjet printer hooked up to their > PC/XT/AT? If so, does DOS notice when the printer hangs? The specifics : The problem, as mentioned later in the article, is that the HP LJ needs xon/xoff support from the host, which PC-DOS doesn't provide. The solution is to look into print spooler s/w, and find one that support xon/xoff serial output. (Or you can write a resident routine to sit on the print BIOS interupt and handle printing w/ xon/xoff if you want to put in the effort) Some ibm-compatibles (I believe the TRS) have extensions to the BIOS that allow the port initialization call to enable/disable xon/xoff protocol. Good luck. -- Opinions expressed are public domain, and do not belong to Lotus Development Corp. ---------------------------------------------------------------- Simcha-Yitzchak Lerner {genrad|ihnp4|ima}!wjh12!talcott!sesame!slerner {cbosgd|harvard}!talcott!sesame!slerner slerner%sesame@harvard.ARPA
slerner@sesame.UUCP (Simcha-Yitzchak Lerner) (08/02/85)
> > The laser jet seems to use all known forms of flow control, simultaneously. > It sends xon/xoff, and also raises and lowers DTR. The IBM BIOS doesn't > know anything about xon/xoff, but it slavishly follows DTR. If you're > having flow control problems, most likely your cable isn't bringing the > flow control signals through. The laser jet manual has a detailed picture > of how the cable should be wired. DTR is not usable for handshakeing unless you are at a low baud rate. I can't say for sure, but from my observations, it appears that the HP LJ sends an xoff when the buffer is getting close to full, and drops DTR when it IS full. Since even PC's have 'reaction time', a few chars are sent before DTR is noticed...by the way, I have had similar problems with HP plotters. {{HP, are you listening?}} -- Opinions expressed are public domain, and do not belong to Lotus Development Corp. ---------------------------------------------------------------- Simcha-Yitzchak Lerner {genrad|ihnp4|ima}!wjh12!talcott!sesame!slerner {cbosgd|harvard}!talcott!sesame!slerner slerner%sesame@harvard.ARPA
koenker@uiucuxc.Uiuc.ARPA (08/02/85)
This is a cabling problem. We've had success here in DOS with the following: out the 9 pin serial port on the serial/parallel adapter connect an ibm 9-25 pin adapter cable then connect an rs232 cable configured as shown in the hp manual, ie pins 2&3 crossed 1&7 passed through and 5&6 on the at end to 20 on the lj end. I'm told that the new manuals have further details and you might want to talk to hp directly: 800854 4031. I've also been trying to get a lj to talk to an AT running xenix and this has provento be much more difficult.
jp@lanl.ARPA (08/06/85)
> > > > The laser jet seems to use all known forms of flow control, simultaneously. > > It sends xon/xoff, and also raises and lowers DTR. The IBM BIOS doesn't > > know anything about xon/xoff, but it slavishly follows DTR. If you're > > having flow control problems, most likely your cable isn't bringing the > > flow control signals through. The laser jet manual has a detailed picture > > of how the cable should be wired. > > DTR is not usable for handshakeing unless you are at a low baud rate. > I can't say for sure, but from my observations, it appears that the HP LJ > sends an xoff when the buffer is getting close to full, and drops > DTR when it IS full. Since even PC's have 'reaction time', a few > chars are sent before DTR is noticed...by the way, I have had > similar problems with HP plotters. > Something is very strange in your printer driver. The DTR should work "instantly" in a normal driver. The DTR signal should be tested immediately before attempting to send a character. The driver will loop until the printer is ready for a new character. I am using a LaserJet on a CompuPro running PCPRO (MSDOS 2.1) successfully at 9600 baud. Never have had a problem even when spewing large files out to the printer. I know it is halting by using CTRL-P to start the printer and then typing a file to the screen. When the printer buffer is full and waiting for a ready the screen stands still until the printer is ready. I think it waits to eject a page before proceeding. Also DTR works satisfactorily when the printer is out of paper or jams or whatever. I believe that the problem is with the cable. Check the manual for the required connections. Jim Potter jp@lanl.arpa
john@hp-pcd.UUCP (john) (08/10/85)
<<< <> Since even PC's have 'reaction time', a few chars are sent before DTR is <> noticed <> < < Something is very strange in your printer driver. The DTR should work < "instantly" in a normal driver. The DTR signal should be tested immediately < before attempting to send a character. The driver will loop until the < printer is ready for a new character. < This must be a case of software inertia in action. Actually I think the "few chars" that are sent is caused by using a double buffered UART with software testing of the DTR status. When a printer receives character # N that fills its buffer it then signals DTR that it is full. But by the time this happens the CPU's UART has already started shipping out character N+1 and the CPU has reloaded the UART with character N+2. The CPU will not see the new DTR status until it is ready to send character N+3. Many UARTS avoid this problem by providing a hardware holdoff input pin (normally the CTS* input). These UARTs would test the pin before sending a start bit and in the above case would pause before sending character N+2. Character N+1 would be stored in the receiver's input buffer until read so nothing would be lost. John Eaton !hplabs!hp-pcd!john
kbb@faron.UUCP (Kenneth B. Bass) (08/14/85)
In article <13600015@hp-pcd.UUCP> john@hp-pcd.UUCP (john) writes: > This must be a case of software inertia in action. Actually I think the "few >chars" that are sent is caused by using a double buffered UART with software >testing of the DTR status. When a printer receives character # N that fills >its buffer it then signals DTR that it is full. But by the time this happens >the CPU's UART has already started shipping out character N+1 and the CPU >has reloaded the UART with character N+2. The CPU will not see the new DTR >status until it is ready to send character N+3. >John Eaton >!hplabs!hp-pcd!john This is a problem I've encountered practically every time I've had to interface any two serial devices. That is, the problem of flow control. There does not exist (to my knowledge) any explicit standard that puts a maximum on the number of characters a device must be able to receive after it signals the transmitter to stop (and vice-versa). I worked with a microcomputer development system once that would send out up to 80 chars. after receiving an XOFF; the modem that it was connected to apparently couldn't handle more than 2 chars. after sending the XOFF. "It ain't necessarily so" linus!faron!kbb
slerner@sesame.UUCP (Simcha-Yitzchak Lerner) (08/15/85)
> > This must be a case of software inertia in action. Actually I think the "few > chars" that are sent is caused by using a double buffered UART with software > testing of the DTR status...... > > Many UARTS avoid this problem by providing a hardware holdoff input pin > (normally the CTS* input). These UARTs would test the pin before sending a > start bit and in the above case would pause before sending character N+2. > Character N+1 would be stored in the receiver's input buffer until read > so nothing would be lost. > > John Eaton > !hplabs!hp-pcd!john The only proble with CTS is that not all machines wire it thru. The reason for this is that there are a lot of UARTS out there with a bad bug: if CTS transitions mid-character xmision, the character is trashed. -- Opinions expressed are public domain, and do not belong to Lotus Development Corp. ---------------------------------------------------------------- Simcha-Yitzchak Lerner {genrad|ihnp4|ima}!wjh12!talcott!sesame!slerner {cbosgd|harvard}!talcott!sesame!slerner slerner%sesame@harvard.ARPA
woof@psivax.UUCP (Hal Schloss) (08/18/85)
In article <326@faron.UUCP> kbb@faron.UUCP (Kenneth B. Bass) writes: >In article <13600015@hp-pcd.UUCP> john@hp-pcd.UUCP (john) writes: >> This must be a case of software inertia in action. Actually I think the "few >>chars" that are sent is caused by using a double buffered UART with software >>testing of the DTR status. > >This is a problem I've encountered practically every time I've had to >interface any two serial devices. That is, the problem of flow control. Well I have had similar experiences connecting our VAX 11/750 to a HP laserjet. The problem occurs with BSD 4.* for the same reasons as on MS-DOS. The fix was to install a Microbuffer from Practical Peripherals. After installing it as a "lump" in the cable all my problems went away. It responds to the Laserjet very quickly and doesn't overflow the printer's buffer, and the Microbuffer has enough buffer left when it sends a X-OFF as to not be a problem. -- Hal Schloss (from the Software Lounge at) Pacesetter Systems Inc. {trwrb|allegra|burdvax|cbosgd|hplabs|ihnp4|sdcsvax|aero|uscvax|ucla-cs| bmcg|sdccsu3|csun|orstcs|akgua|randvax}!sdcrdcf!psivax!woof or {ttdica|quad1|scgvaxd|nrcvax|bellcore|logico}!psivax!woof ARPA: ttidca!psivax!woof@rand-unix.arpa