venta@otello.sublink.org (Paolo Venta) (08/23/90)
Hello, maybe some1 of you knows the trick to make a serial printer work correctly on a 3b2-600. Printer: Mannesmann MT131/9 Machine: at&t 3b2-600 Problem: printer is loosing characters, handshake xon/xoff does not work though it's set. Printer's menu says xon/xoff handshake is enabled. My interface script for the printer contains a: stty -parity -tabs -hupcl cread -ixany ff1 ixon -ocrnl onlcr -onocr opost 9600 0<&1 (on the same line). I tried both short and long buffer on the printer. Same results, at different times (longest the buffer, latest the problem, but it always occurs). Now, before loosing more time trying hardware handshake with ctsflow, i wonder if someone is using a similar printer on this hardware. To use ctsflow i probably need to make a custom cable since the mt131 uses pins 10,11 and 19 of V24 as 'ready' signal, which appears to be the cts/rts stuff. Thanks a lot for any information! Paolo -- Paolo Ventafridda -*- INTERNET: venta@otello.sublink.org TELEMATIX MILANO - Via C.Gomes 10, 20124 Milano - +39-2-6706012
friedl@mtndew.Tustin.CA.US (Steve Friedl) (08/29/90)
Paolo Venta writes: > Hello, maybe some1 of you knows the trick to make a serial printer > work correctly on a 3b2-600. Hi folks, One of the most common things that I do is make printers work after others give up [ pats self on back ], and flow control is one of the biggest reasons why things don't work. Rather than answer him in email I thought I would post to maybe give you folks some tips on dealing with flow control issues. First, we assume here that he is using the EPORTS card, which has eight serial ports plus. This is contrasted with the older PORTS board that has four serial and one parallel port. EPORTS has hardware flow control and much faster processors than PORTS. When doing any significant RS-232 work, it is really handy to have a breakout box or (better) a data line monitor. Being able to view the serial data stream is a major, major win when trying to get it all to work. I highly recommend the Datacomm Technologies DataTool 5500 -- I'd be useless without it. First, some printers are really fussy about their incoming control lines (usually DSR, DCD, and CTS). Some printers will refuse to print at all if the required combination of control lines is not high, and others will simply refuse to issue an XOFF (for instance, Okidatas). If you have a breakout box, send a big job and watch the data line from the printer and look for the XOFF to go back. If you don't see it, try asserting all inputs. Next, be careful when selecting the proper stty options. Paolo's interface is using: > stty -parity -tabs -hupcl cread -ixany ff1 ixon -ocrnl onlcr -onocr > opost 9600 0<&1 If it were me, I would probably add something like `cs8' to specifically mention the wordsize and `istrip' to remove any stray parity bits being set by the printer. I also notice that he has disabled `ixany' -- this is a good thing. As you'll recall, ixany means that any character can restart control after an XOFF, and this will be Big Troubles when the printer uses "robust XOFF". This is when the printer sends XOFF at regular intervals (say, once a second) while flow is stopped, and it is done to compensate for the occasional XOFF that gets lost. The problem is that the second XOFF will *restart* the flow if ixany is set, and it ends up being a real mess. HP LaserJets can be set up for robust XOFF, among others. .nf > I tried both short and long buffer on the printer. Same results, > at different times (longest the buffer, latest the problem, but it > always occurs). .fi When testing flow control problems, reduce the size of the printer's buffer as much as possible (disable it if possible). There is no need to burn off a dozen pages to see that your flow control is not happening -- disbale the buffer and find out forthright. I further recommend that smaller buffers are better for normal operation anyway. These buffers are not the big win that they are on a single-tasking operating system like MS-DOS, and about the only thing a big printer buffer will buy you under UNIX is a much longer time from killing an lp job to the time that it actually stops. Now onto 3B2-specific problems. The EPORTS card has problems running XON/XOFF at high speed with some kinds of devices. Each of the input ports on the card has its own RAM buffer, and data goes right from the UART to the RAM via a DMA channel. The onboard CPU scans these input queues at regular intervals and transfers the data to the 3B2. This is a really great mechanism for getting VERY fast input/output rates. Let's say that the onboard CPU scans the input queue for channel one and finds nothing. At this time the output queue is busy burning off characters to the printer, and at this very moment an XOFF arrives. The CPU has just finished with this queue and has moved onto the next one. While it is doing this, characters are still blowing out channel one, and the printer is getting nervous: "is it ever gonna stop?" In time, the onboard CPU gets around to channel one again and it sees the XOFF deposited there. It immediately stops the output flow right away, but at high speeds it can be quite a significant time. At 19200bps it is reportedly 16 or 32 character times (don't remember which), and for some devices -- the HP LaserJet comes to mind again -- this is just too much. The only solutions are to slow down the printer, use hardware flow control, or get a real computer like an NCR Tower :-). To really do this right would require that the UART have special "watch" character so it would issue an interrupt if the mentioned character arrived in the port. Then the onboard CPU could do scanning as usual with occasional forays to service a port that just got XOFFed. Alas, this wasn't done on EPORTS. My understanding of AT&T's fix to this was to scan the queues at a faster rate, allowing each channel to be serviced at more regular intervals. Hardware flow control is a big win in any case. Stop times are very fast -- half a character time? -- because it doesn't rely on scanning of the input queues. I am not sure whether dropping of CTS causes an interrupt or if the UART just inhibits the transmit-buffer-empty signal (or disables DMA), but in any case it is much much better than software flow control. If you know how to do it, use it. Note that printers are the only thing that hardware flow control is good for on EPORTS. For reasons that seem to escape even the EPORTS support people, software and hardware flow control are mutually exclusive, and this cause Many Big Problems for people who want to use their cards for real things in the real world. If anybody out there knows of ANY reason why this is the case, even a bad reason, I would love to hear it. I want very much to believe that AT&T is not full of sh*t, but so far that's the only conclusion I'm able to come to. It makes me want to trade in my "3B2 UNIX" license plate :-( Steve -- Stephen J. Friedl, KA8CMY / I speak for me only / Tustin, CA / 3B2-kind-of-guy +1 714 544 6561 / friedl@mtndew.Tustin.CA.US / {uunet,attmail}!mtndew!friedl Steve's bright idea #43: put TV Guide on CD-ROM for quick access
les@chinet.chi.il.us (Leslie Mikesell) (08/29/90)
In article <506@mtndew.Tustin.CA.US> friedl@mtndew.Tustin.CA.US (Steve Friedl) writes: [XOFF skid on 3B2 EPORTS...] > At 19200bps it is reportedly 16 or 32 character times (don't >remember which), and for some devices -- the HP LaserJet comes to >mind again -- this is just too much. The only solutions are to >slow down the printer, use hardware flow control, or get a real >computer like an NCR Tower :-). Another way that should work would be to add one of those serial buffer boxes that are commonly used between PC's and printers. They can be found for <$100 in the smaller buffer sizes, which should be cheaper than dumping the computer (at least in the short run). > To really do this right would require that the UART have >special "watch" character so it would issue an interrupt if the >mentioned character arrived in the port. Then the onboard CPU >could do scanning as usual with occasional forays to service a >port that just got XOFFed. Alas, this wasn't done on EPORTS. No, to do it right the on-board CPU should have sufficient capacity to service the received character interrupt from the UARTs under all conditions. Micro-CPU's are not prohibitively expensive for this. [...software/hardware flow control are mutually exclusive] > If anybody out there knows of ANY reason why this is the >case, even a bad reason, I would love to hear it. I want very >much to believe that AT&T is not full of sh*t, but so far that's >the only conclusion I'm able to come to. Well they do have that reputation to maintain. Les Mikesell les@chinet.chi.il.us