APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Parallel printer cable length

© July 2004 BigDumbDinosaur

Given that reliable parallel port operation limits one to a cable length of no more than 15 feet, network print servers make a lot more sense.

Incidentally, a seemingly slow parallel port can be a victim of an overly long cable -- this malady can also affect network print servers that drive their printers via a parallel port. To understand why, you need to know a little bit about how the Centronics interface operates.

Centronics' original design consisted of eight data lines corresponding to the eight bits of a byte (usually labeled D0-D7) and two handshaking lines called *STROBE and *ACK (the asterisk indicates that these lines are low-true). Other lines, such as *BUSY and *RESET, exist in modern implementations to increase functionality. However, only D0-D7, *STROBE and *ACK are required to set up a working interface.

When the port is quiescent and the printer idle, D0-D7 will be at random logic levels. *STROBE, which is controlled by the computer, will be held at logic one (high or 5 volts) and *ACK (acknowledge), which is controlled by the printer, will also be held high.

When the computer is ready to print it will place a data byte on D0-D7, with the hardware logic corresponding to the individual bit values (i.e., a set bit will be manifested by the corresponding data line being brought high and a clear bit represented by a logic zero -- low or zero volts -- on the corresponding line. Following a small delay of one to two microseconds, the computer will inform the printer that a valid byte is present by momentarily bringing *STROBE low and then returning it to high -- *STROBE is said to have been toggled. Each transition of *STROBE must be maintained for at least one microsecond to assure that the printer will have sufficient time to recognize the toggling of *STROBE.

Assuming that the printer is ready for data, it will react to the toggling of *STROBE by reading the data from D0-D7. When the printer has completed this process it will toggle *ACK, which (in most cases) will cause an interrupt to occur in the computer, letting it know that the printer is ready for more data. Here again, each transition on *ACK must be maintained for at least one microsecond.

Now, in examining the above sequence it becomes clear that the data transfer rate can be quite high (as much as 500 K per second), which means there isn't a lot time for the data signals to propagate. Theoretically, electrical impulses can travel about 328 yards per microsecond. However, reactive effects within the cable substantially reduce the rate of propagation and also distort the signal's waveform or shape. If the cable is too long, errors will occur, either resulting in slower printing, random garbage appearing in the printer's output, or both.

To assure reliable operation, the waveform of the various signals must be reasonably rectangular (as seen on an oscilloscope) so that the logic transitions are clearly defined. If the waveform is excessively distorted, which can occur with a long cable, the hardware may have difficulty in determining when a logic transition has occurred, again causing errors.

Where the biggest slowdown comes is in the receipt of the *ACK signal. If signal distortion and/or propagation delay occurs, the expected interrupt from *ACK will not arrive as often, which means the computer will not feed data to the port as often. If the cable is too long, *ACK may become too distorted to cause a clean logic transition and the expected interrupt may never occur, stalling the printer.

The bottom line is keep the cable short, 10 feet or less is ideal. At 20 feet, printing problems will start to occur. Your only solutions if you need to increase the distance between the computer and the printer are to either use an EIA-232 (RS-232) interface, which can operate over distances of several hundred feet, or a network print server (a 100Base-T network is reliable out to 100 meters or about 328 feet). Given the greater flexibility of networking, you'd be better off going that route.

Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> Parallel printer cable length limits

Inexpensive and informative Apple related e-books:

Take Control of Apple Mail, Third Edition

Take Control of Pages

Photos: A Take Control Crash Course

Take Control of Parallels Desktop 12

Take Control of Preview

More Articles by © BigDumbDinosaur

I was once at a job where two (2) 20 ft cables were strung together to run a printer.

Not only was the distance incredible but it passed through a busy walkway AND at one spot a person regularly rolled their office chair across the cable. The results were actually less dismal than you'd expect, but I made them put in a print server anyway.

I'm a mean Mr.Grinch, I am :-)


The effect of the chair rolling over the cable would bother me less that the obvious tripping hazard. <Grin> Not to mention the ugly black marks made on the cable by the chair's casters.

It's a good thing OSHA didn't find out about this apparently dangerous workplace! If they had, they'd be promulgating all sorts of safety regulations about printer cable usage. For example, a hard hat and safety glasses would be required while connecting or disconnecting the cable from the printer. The technician would also have to undergo specialized training so as to learn how to avoid injury from the five volt signals that are present.


---July 23, 2004

There are other ways around the 15ft cable limit. One is to use a low-capacitance, shielded cable. We've been using a 75 ft parallel cable to run an old Printronix P600 line printer for over 10 years now with nary a hiccup. Until recently, that is.

Our OpenServer box has been configured with two parallel ports for years, one for the Printronix, and one for an old HP LJII that has been out of commission for a couple of years. The LJII used to run off of the motherboard's parallel port and the P600 off of an add-in Lava PCI parallel port. A couple of months ago I needed an extra PCI slot for another SCSI adapter, and decided to eliminate the PCI parallel card and go back to the onboard parallel port. But it refused to work with the old P600 interface, which was configured with optional resistor packs for extended cable length. The Lava card didn't mind, but the motherboard circuitry certainly did, even with a 10ft cable.

So the other option besides a low-cap cable is to use a quality parallel adapter card instead of the one on the motherboard.


Successes with longer cables notwithstanding, Centronics never designed the interface to be reliable at high speeds where any distance is involved. With no error checking of any kind, a garbled byte will be accepted by the printer as valid data. Only when *STROBE and/or *ACK get messed up will it become painfully apparent there is a problem.

Unfortunately, unlike some other bus systems (e.g., SCSI), the Centronics' interface and timing specs were actually quite sloppy. They set a minimum period during which *STROBE and *ACK had to be maintained in one state or the other and set a minimum period between the time the data was placed on D0-D7 and *STROBE was toggled (this is called setup time), but didn't address propagation delays and other timing issues that might arise.

Also, at the time the original interface was developed, discrete logic was much more common in circuit design, and that contributed to variations in timing, signal shape (waveform) and even what voltage constituted a legitimate logic one or logic zero. To mask some of these potential problems, Centronics also specified that the cable length be limited to 10 feet. You have to consider that in those days, cables were usually IDC ribbon stuff, not shielded, jacketed cable like we use now, so losses were actually lower due to lower reactive effects.

You really should not be depending on the apparent superiority of an add-on parallel port card over the embedded interface in the motherboard. Timing rates can vary greatly between printers -- the receipt of *ACK by the host can be delayed because of processing overhead in the printer -- and the timing and duration of the *STROBE signal may vary as a natural consequence of varying processing
loads experienced by the host machine. In any case, the interface will usually run as fast as the printer can *ACK bytes. As Tony pointed out above, with distance you should move to a network print server.

BTW, the parallel port arrangement found in all modern PC's is actually based upon an "improved" design by Epson. Epson took the basic Centronics interface and added other control lines like BUSY, *RESET and so forth. The EPP/ECP features added more control lines to facilitate bi-directional operation.


---July 24, 2004

Perhaps the thing to realize is that just because it works with this cable and this card and this printer doesn't mean it still will if you change anything.


My point exactly!

Also, see https://nemesis.lonestar.org/reference/computers/interfaces/centronics.html for some more information about parallel ports and how Epson (under pressure from IBM) bastardized the original Centronics standard.


---August 19, 2004

Never had any problems with long printer leads, worked installing computers/fixing them for many years in the past, and seen cables stretched under floors, and around walls some extremely long parallel leads - never any problems printing. Rules are one thing - but have you ever hooked up a decent cable that is the length you say will fail, and seen the results? Textbook is one thing, real world is another. Colleges and universities can never teach real world.

---August 19, 2004

I'm willing to bet that I have more experience in the real world than most of the people reading this. I've been doing computers since 1967 and full time since 1981.

I HAVE seen the problems Steggy refers to. Not every time with every long cable, but often enough to know that he is 100% correct.


"Textbook is one thing, real world is another. Colleges and universities can never teach real world. (ken)"

How did colleges and universities get into the discussion? And since when are published industry standards just something to dismiss as an academic exercise?

Like Tony, I've been banging away at this stuff for many years (almost 40, to be exact). I don't claim to have all the answers and I'm sure Tony doesn't as well. However, I'd be willing to bet that between the two of us we have run across just about every known computer hardware problem at one time or another.


---August 19, 2004

Wrong. I do claim to have all the answers. Some of them are WRONG answers, but ..


Oops! My apologies, Professor! <Grin>


---January 19, 2005

I ran into an issue with a printer cable, IEEE1284, that was over 6 feet, and it would not work on an OS/2 operating system. The docs for OS/2 stated that 6 feet was the maximum length the printer cable could be for a parallel port connection. So, I guess the OS has something to do with this spec? Perhaps Ken was using a more forgiving OS like Windows? OS/2, was for it's time, a nice graphical multiuser OS, that was so much better than windows in so many ways, like multitasking, but it never took off. I was a huge user, before I switched to Linux, and *nix in general. I'm glad I did, but I am going to be installing https://ecomstation.com which is the new version of IBM's OS/2 Warp. Should be interesting :-)


OS/2 would have been Windows if Microsoft hadn't been such a snake in the grass. In fact, a good deal of what you saw in Windows 3.x was "borrowed" from OS/2. The only part that Microsoft didn't "borrow" was the stability and performance.


Printer Friendly Version

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

Printer Friendly Version

Basic happened to be on a GE timesharing system that was done by Dartmouth, and when GE decided to franchise that, it started spreading Basic around just because it was there, not because it had any intrinsic merits whatsoever. (Alan Kay)

Linux posts

Troubleshooting posts

This post tagged:





Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode