ftp.nice.ch/peanuts/GeneralData/Usenet/news/1991/CSN-91.tar.gz#/comp-sys-next/1991/Feb/HP-LJ-III-dying-under-NeXTStep-2.0

This is HP-LJ-III-dying-under-NeXTStep-2.0 in view mode; [Up]


Date: Sun 15-Feb-1991 03:15:24 From: mikec@wam.umd.edu (Michael D. Callaghan) Subject: HP LJ III dying under NeXTStep 2.0 Here's the story: Ever since I upgraded my NeXTCube 030 to NeXTStep 2.0, my HP Laserjet III PostScript doesn't work right. I am constantly getting I/O Config errors when printing Complex PostScript files. If I try to reset the printer, I proceed to get PS Error 18, which says a non-postscript operator has been used. PostScript Preview opens the file without error. Printing from Preview causes the same error. The NeXTCube continues to send data to the printer, even when the print queue is empty. I let it sit overnight, and the printer was still receiving data the next morning! I would like to hear from someone at HP, if at all possible. My NeXT printer will be ordered by next Friday, but until then, I need a printer that does what it's supposed to do. Thanks, MikeC
Date: Sun 15-Feb-1991 17:10:41 From: les@chinet.chi.il.us (Leslie Mikesell) Subject: Re: HP LJ III dying under NeXTStep 2.0 In article <1991Feb15.031524.3210@wam.umd.edu> mikec@wam.umd.edu (Michael D. Callaghan) writes: >Ever since I upgraded my NeXTCube 030 to NeXTStep 2.0, my HP >Laserjet III PostScript doesn't work right. >I am constantly getting I/O Config errors when printing Complex PostScript >files. If I try to reset the printer, I proceed to get PS Error 18, which >says a non-postscript operator has been used. If the postscript generates any output back to the sending tty, it is important to have the spooler port configured properly to handle it. I had a problem with more or less random timeouts and hangups which turned out to be caused by the print spooler enabling reverse xon/xoff flow control on the line (i.e the computer could send the printer an xoff for flow control on messages coming back). Nothing on the computer was ever reading from the printer, so after a printout or two that generated output (usually psroff), the computer would send an xoff and the printer would sit waiting to be able to finish sending back its message. Another posting recently pointed out a similar but more drastic problem when character echoing is enabled on the line. That could be your trouble as well. Les Mikesell les@chinet.chi.il.us
Date: Sun 18-Feb-1991 18:34:16 From: croehrig@audiolab.UWaterloo.ca (Chris J. Roehrig) Subject: Re: HP LJ III dying under NeXTStep 2.0 In article <1991Feb15.031524.3210@wam.umd.edu> mikec@wam.umd.edu (Michael D. Callaghan) writes: >Ever since I upgraded my NeXTCube 030 to NeXTStep 2.0, my HP >Laserjet III PostScript doesn't work right. >I am constantly getting I/O Config errors when printing Complex PostScript >files. If I try to reset the printer, I proceed to get PS Error 18, which >says a non-postscript operator has been used. We have the same problem with our LaserJet III with NeXTStep 1.0 when we run at 19200 baud or, to a lesser extent, at 9600 baud. We've scope'd the serial port's Tx and Rx lines, and this is what's happening: The LaserJet has an input buffer (for the raw incoming Postscript, before the Postscript parser gets at it) that has a high water mark set at 64 bytes. When it fills beyond this mark, the LJ sends an XOFF to the NeXT to tell it to stop transmission. The NeXT is apparently handling flow control in software, and good ol' Unix gets around to stopping transmission anywhere from 30 ms to 100 ms after it receives the XOFF. (That's a tenth of a second!) Meanwhile, the NeXT has fired off over a hundred extra bytes at the LJ, who frantically sends a bunch more XOFF's and finally overflows its input buffer and gives the I/O CONFIG ERROR. When you press RESET, the LaserJet sends XON, and is expecting a complete Postscript document, whereas the NeXT resumes transmission in the middle of the document. The PS ERROR 18 is basically a syntax error. Our solution was to run the LaserJet at 2400 or 4800 baud (yuck), with which the Postscript interpreter can almost always keep up. We still get errors on complex pages. The ultimate solution will be to convert to hardware flow control using RTS/CTS which I understand have been implemented on the '040 boards. You'll have to rewire the serial cable for that. Chris Roehrig
Date: Sun 18-Feb-1991 16:10:16 From: clewis@ferret.ocunix.on.ca (Chris Lewis) Subject: Re: HP LJ III dying under NeXTStep 2.0 In article <1991Feb15.171041.3582@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <1991Feb15.031524.3210@wam.umd.edu> mikec@wam.umd.edu (Michael D. Callaghan) writes: >>Ever since I upgraded my NeXTCube 030 to NeXTStep 2.0, my HP >>Laserjet III PostScript doesn't work right. >>I am constantly getting I/O Config errors when printing Complex PostScript >>files. If I try to reset the printer, I proceed to get PS Error 18, which >>says a non-postscript operator has been used. >If the postscript generates any output back to the sending tty, it is >important to have the spooler port configured properly to handle it. >I had a problem with more or less random timeouts and hangups which >turned out to be caused by the print spooler enabling reverse xon/xoff >flow control on the line (i.e the computer could send the printer an >xoff for flow control on messages coming back). Nothing on the >computer was ever reading from the printer, so after a printout or >two that generated output (usually psroff), the computer would send --------------- (mine or Adobe's? By default, psroff emits a fair bit of stuff back up the line unless you define NOCHATTER, and anything wrong with handshaking will show up quickly) >an xoff and the printer would sit waiting to be able to finish sending >back its message. >Another posting recently pointed out a similar but more drastic problem >when character echoing is enabled on the line. That could be your >trouble as well. Many people using Postscript printers are unaware of the fact that Postscript prints error messages and so-on "back up the line". When people start having problems, whether it be sporadic hangups, or when you're trying to debug your hand-written Postscript, or you're trying to configure psroff (;-) it really pays to see what the printer is saying. For a printer on a serial port, you just start up a cat reading from the serial port. Eg: if your printer is on port /dev/ttyA, just type: cat /dev/ttyA& And then you'll see everything the printer has to say about your print jobs. For example, psroff uploads stuff about how many pages were printed and other miscellaneous things - if you run: cat /dev/ttyA > somewhere You can keep a printer log with the real page count. You can use this feature for all sorts of things, including having the printer tell you how wide all the characters are.
Date: Sun 19-Feb-1991 16:29:37 From: les@chinet.chi.il.us (Leslie Mikesell) Subject: Re: HP LJ III dying under NeXTStep 2.0 In article <1363@ecicrl.ocunix.on.ca> clewis@ferret.ocunix.on.ca (Chris Lewis) writes: >>I had a problem with more or less random timeouts and hangups which >>turned out to be caused by the print spooler enabling reverse xon/xoff >>flow control on the line (i.e the computer could send the printer an >>xoff for flow control on messages coming back). Nothing on the >>computer was ever reading from the printer, so after a printout or >>two that generated output (usually psroff), the computer would send > --------------- >(mine or Adobe's? By default, psroff emits a fair bit of stuff back >up the line unless you define NOCHATTER, and anything wrong with handshaking >will show up quickly) Yours (thanks - I finally have nice looking man page printouts for the things I've picked up from the net). >Many people using Postscript printers are unaware of the fact that Postscript >prints error messages and so-on "back up the line". I knew about it but it still took a bit of time to figure out what was happening since the printer usually would print the first psroff job with no problem, then hang up even if the same thing was sent again. Our other postscript-generating programs didn't have the same problem, and when I ran a daemon program to log the printer's output, the problem wouldn't happen. Les Mikesell les@chinet.chi.il.us

These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.