Essential Printer Handshake Settings Explained
A legacy machine can produce perfectly valid print data and still fail to print a usable page. The usual cause is not the printer language, baud rate or cable alone. It is the handshake. Essential printer handshake settings determine when a host is permitted to send data, when a printer is busy, and what happens when its buffer is full. Get them wrong and symptoms range from a job that never starts to missing characters, repeated lines and a machine that locks up waiting for a signal that never arrives.
For industrial controllers, laboratory instruments and older computer systems, handshaking is often part of the interface contract. Replacing a dot matrix printer with a modern printer, a print capture appliance or an emulator therefore requires more than accepting bytes on a connector. The replacement must present the signals and timing the host expects.
Why printer handshaking matters
A printer is slower than the equipment feeding it. Even a relatively fast serial device may need time to interpret control codes, move a print head, change a form feed or write captured output to storage. Handshaking prevents the host from overrunning that device while preserving a predictable print process.
This matters particularly where the original printer was designed into the workflow decades ago. A CNC machine may pause until it receives the correct ready condition. A DOS application may assume that a Centronics printer acknowledges every byte. A medical analyser may send data only after an RS232 control line changes state. In each case, a modern replacement that merely offers a USB or network print queue is not a direct substitute.
There are two broad categories to consider: serial flow control on RS232 connections, and status signalling on parallel Centronics connections. They solve the same practical problem but behave very differently.
Essential printer handshake settings for RS232
Serial links carry data over transmit and receive lines, but the control lines are just as significant. Before changing settings, identify the role of each endpoint. A computer or controller is commonly configured as DTE, while a printer is often DCE. This affects cable wiring and which signals each side expects to see.
Hardware flow control: RTS and CTS
RTS/CTS hardware flow control uses dedicated conductors. Traditionally, RTS means Request To Send and CTS means Clear To Send, although in printer applications the practical meaning is usually simpler: the receiving device uses CTS to tell the sender whether it can accept more data.
When CTS is asserted, the host transmits. When the printer or emulator de-asserts CTS, the host should pause immediately. This is a dependable approach for equipment that sends data in bursts or has little buffering. It also avoids placing control characters within the print stream.
However, RTS/CTS only works if all three elements agree: the host configuration, the receiving device configuration and the cable pinout. A straight-through cable, null-modem cable and bespoke machine harness can all present different connections. Assuming that a DB9 or DB25 connector follows a standard without checking it is a frequent source of failed installations.
Software flow control: XON and XOFF
XON/XOFF flow control uses control characters sent within the serial data stream. XOFF, normally hexadecimal 13, tells the sender to stop. XON, normally hexadecimal 11, tells it to resume. It is useful where the cable has only transmit, receive and ground conductors, which is common on simpler legacy equipment.
The trade-off is that these values can theoretically occur within binary data. For ordinary text, Epson ESC/P, PCL and many reporting streams this is usually manageable, but it must be assessed for proprietary protocols or raw graphics output. Both ends must also be configured for the same software flow-control method. Enabling XON/XOFF on only one side can produce unexplained pauses or missing characters.
DTR and DSR: readiness and presence
DTR/DSR is another common arrangement. DTR, Data Terminal Ready, and DSR, Data Set Ready, were originally associated with modems, but many printers and controllers reuse them as general ready signals. Some hosts will not begin transmission unless DSR is asserted. Others will stop or fault if DTR changes during a job.
A capture device may therefore need to assert a readiness line continuously, emulate changes in line state, or map the signal to its internal buffer condition. There is no universal setting. The machine manual, its original printer specification and observation of the live interface should determine the required behaviour.
Data framing still has to match
Handshake settings cannot compensate for incorrect serial framing. Confirm baud rate, data bits, parity and stop bits before diagnosing flow control. A setting described as 9600 8N1 means 9,600 baud, eight data bits, no parity and one stop bit. Older machinery may use 7E1, 7O1, 1200 baud or other combinations that are no longer common.
Do not assume the highest available baud rate is preferable. The correct setting is the one the host uses reliably. Changing it may require changes in inaccessible firmware menus or application configuration, and can create a problem where none existed.
Centronics parallel handshaking is signal-by-signal
Parallel printer ports are often described as simple, but Centronics is an active handshake interface. The host places a byte on the data lines and pulses STROBE. The printer responds with signals that indicate whether it has received the data and whether it is available for the next byte.
The exact signals supported vary by implementation, but the key lines commonly include BUSY, ACK, SELECT, PAPER END and ERROR. BUSY tells the host to wait. ACK is a short acknowledgement pulse after a byte is accepted. SELECT indicates the printer is online, while PAPER END and ERROR report conditions that could prevent printing.
An older computer may be tolerant of some missing status lines. An industrial machine often is not. If it expects SELECT to be active and a replacement leaves the line floating, it may report the printer as offline before sending a single character. If it expects an ACK pulse of a particular polarity or duration, a passive adaptor will not solve the problem.
Active-low signals and timing traps
Many Centronics signals are active low, meaning that a low voltage represents the asserted state. This is easy to reverse when working from a label alone. A line marked ERROR with an overbar in a circuit diagram does not behave like an ordinary positive logic error signal.
Timing matters too. A host may sample BUSY shortly after STROBE, wait for ACK, or impose a timeout that was reasonable for its original printer. An emulator should accept data at the host’s pace while accurately presenting a ready state. If output is being converted to PDF, sent to a network printer or stored electronically, that slower downstream work should normally be buffered rather than allowed to disrupt the source machine’s handshake.
A practical commissioning method
Start by recording the original arrangement before removing a working printer. Photograph connectors and cable labels, note every menu setting, and capture a known-good printout. If the original unit is unavailable, find the equipment’s interface specification rather than relying on the connector type.
Then establish the physical layer. For RS232, confirm voltage levels as well as pin assignments. True RS232 signalling is not the same as TTL-level serial from a microcontroller, even if both are described as serial. For parallel, confirm whether the port is standard Centronics, a proprietary variation or a GPIO-style interface carried on a printer-shaped connector.
Configure the capture or emulation device with matching framing and the intended handshake method. Test with a short job first, preferably plain text with recognisable line endings. Once data is stable, test longer reports, graphics, form feeds and any printer-specific commands used by the source equipment.
When faults occur, classify them by behaviour. No transmission often points to a readiness line, cable orientation or incorrect DTE/DCE assumption. Garbled text suggests baud rate, parity or electrical-level mismatch. Output that begins correctly but loses data under load usually indicates flow-control failure or insufficient buffering. A job that pauses at the same point may reveal a control code, page boundary or buffer condition that the replacement has not yet handled.
A serial analyser, breakout box or logic analyser can shorten diagnosis considerably. Even basic indicator LEDs on transmit, receive and control lines can show whether a controller is waiting for CTS, DSR or a parallel ready signal. For difficult environments, measuring the actual states and timing is more reliable than interpreting decades-old notes.
Handshaking should be part of the replacement specification
When assessing a legacy printer replacement, specify the interface behaviour alongside the printer language. “RS232 supported” is not enough if the application requires RTS/CTS at 9600 7E1, or if a controller needs Centronics ACK and BUSY signalling. Likewise, protocol conversion is only useful when the source machine can complete its existing print cycle without errors or delays.
Retro-Printer Module installations can be configured to capture legacy serial or parallel output while preserving the interface behaviour required by the host. That allows print data to be stored, converted or routed onwards without retaining an ageing mechanical printer solely for its electrical signals.
The most useful result is often not a faster printout but an uneventful one: the machine completes its report, the data is retained electronically, and the operator never has to think about an obsolete printer’s consumables or failing mechanics again.
