Problem Details
A legacy vertical machining center is fitted with a BTR (Behind The Tape Reader) unit used to feed programs electronically instead of punched tape. The BTR is driven by a proprietary DOS host application, and that application is protected by a parallel-port hardware key (dongle). The DOS software is missing, so the BTR cannot be commanded, and no program can be transferred to the control.
The stated problem is therefore not a communications fault. Signal levels, baud rate, and handshaking are irrelevant until one of two things is true:
- The original DOS host software plus its matching dongle are recovered and run on hardware that can service a real LPT port; or
- The BTR is bypassed and the control is fed by a serial (RS232) path that does not depend on that software.
How a BTR Actually Interfaces
A BTR does not use the control's serial port. It intercepts the parallel tape-reader signal set between the photoelectric reader head and the control's reader input, and impersonates the reader.
| Signal group | Typical function | Direction (relative to control) |
|---|---|---|
| Channels 1–8 + sprocket/feed hole | One character per sprocket pulse, one line of tape per frame | Into control |
| Sprocket / strobe | Latches the channel data; the control clocks on this edge | Into control |
| Reader drive / advance | Control commands the reader to step or run | Out of control |
| Tape ready / reader alarm | Media present, no fault, not at end of tape | Into control |
Consequences for troubleshooting:
- The BTR is a character pump. Flow control is exercised by the control's reader-drive line, not by XON/XOFF. If the control stops asserting drive, the BTR must stop clocking data.
- The BTR must emit the same tape code the control expects — EIA RS-244 (odd parity on 8 channels) or ISO/ASCII (even parity). If the control has a code-select switch or parameter, the BTR must match it, including the leader, the program-start character, and the end-of-record character.
- Because the BTR sits on the reader harness, an incorrect wiring or level mismatch can produce hard reader alarms rather than clean serial errors.
Root Cause: Dongle-Locked DOS Host
The BTR's PC-side utility handles file selection, code translation, block buffering, and (on many units) firmware download to the BTR. The parallel-port key must be readable by the software, which imposes hard requirements on the host PC:
| Constraint | Requirement | Why it breaks on modern hardware |
|---|---|---|
| Real parallel port | Physical LPT hardware at a fixed I/O base (typically 0x378 or 0x278) with IRQ 7 or 5 | USB-to-parallel adapters present a printer class device, not a register-level port; dongle reads fail |
| Port mode | Dongles commonly require standard/bidirectional SPP behavior | BIOS defaults of ECP or EPP can change timing and handshake lines enough to break key reads |
| Real-mode DOS | Direct port I/O and timing loops | NT-based Windows blocks direct I/O; emulators generally do not pass raw LPT register access through |
| CPU timing | Software written for slow CPUs may use calibrated delay loops | Very fast hosts can overrun those loops; use BIOS CPU throttling or a period-correct machine |
Practical recovery order:
- Search the machine for the original media and key — electrical cabinet document pocket, control pendant drawer, maintenance manual binder, and any 3.5" or 5.25" media stored with the machine.
- Identify the BTR by its own nameplate/PCB markings, not by the machine model. BTRs were third-party retrofits; the machine builder generally has no record of them.
- Contact the BTR manufacturer (or its successor) through official channels with the unit serial number and request the host software plus a replacement key. Expect the key to be chargeable and serialized.
- If no key exists, stop pursuing the DOS route. Do not plan production around a single unlicensed, unsupported binary.
Decision Path: Repair the BTR or Bypass It
| Option | Prerequisite | Effort / risk |
|---|---|---|
| A. Restore DOS host + dongle | Original software and key obtainable; period PC with real LPT | Low engineering effort, high supply risk, single point of failure |
| B. Use the control's own RS232 reader/punch port | Control has a serial interface option fitted and enabled | Lowest long-term risk; BTR becomes redundant |
| C. Replace the BTR with a current parallel tape-reader emulator | Full reader connector pinout and tape code documented | Moderate; vendor-supported, usually configured from a terminal or web UI instead of DOS |
| D. Physical tape reader restored | Reader head and drive mechanically sound; punched media available | Fallback for proving the machine, not for production |
Prefer Option B if the serial port exists. A control that can load through RS232 removes the BTR, the dongle, and the DOS host from the maintenance chain in one step. Verify by checking for a reader/punch interface board in the control rack and a serial connector on the operator panel or cabinet, then confirm the I/O-device selection parameter and any DNC/remote-buffer option.
RS232 Implementation and Settings
Once a serial path is confirmed, treat it as a classic 3-wire or hardware-handshake link. Legacy CNC serial ports are DTE-like on the connector but not consistently, so verify with a breakout box before assuming a cable type.
Null-modem, 25-pin, hardware handshake
CNC DB25 PC DB9
2 TXD -------- 2 RXD
3 RXD -------- 3 TXD
7 GND -------- 5 GND
4 RTS -------- 8 CTS
5 CTS -------- 7 RTS
6+8 DSR/DCD ------ 4 DTR
20 DTR -------- 6 DSR (+1 DCD)
Shield to connector shell at ONE end onlyConfigure both ends identically. Where the control offers a choice, start conservative and raise speed only after clean transfers:
| Parameter | Typical legacy setting | Note |
|---|---|---|
| Baud | 1200 / 2400 / 4800 | Older controls may not exceed 4800 reliably; raise stepwise |
| Data / parity / stop | 7-E-1 (ISO/ASCII) or 8-N-1 | EIA-coded controls expect odd parity on the tape code itself |
| Flow control | XON/XOFF (DC1/DC3) or RTS/CTS | Drip-feed jobs almost always require working flow control |
| End of block | CR+LF or LF only | Mismatch causes format alarms at the first block |
| Program delimiters | Leading %, trailing % or EOR |
Control may hang waiting for the terminator |
Verification
- Loopback the PC. Jumper pins 2–3 on the PC connector and echo characters in a terminal. This proves the port and cable before the control is involved.
- Punch/send from the control. Output an existing resident program to the PC terminal first. Receiving readable G-code proves cable, baud, parity, and direction in one test, and it does not risk overwriting machine data.
- Send a trivial program. A few blocks with a program number, a comment, and an end-of-program. Confirm the control accepts it without a data/parity alarm.
- Send a long program. Watch for characters lost after the first buffer fills — that isolates flow control specifically.
- Drip-feed dry run. Run the machine in DNC/remote mode with feed-hold available and axes clear, at reduced feedrate override, to confirm the control never starves mid-cut.
- Document it. Record cable pinout, port settings, control parameters changed, and the transfer procedure inside the electrical cabinet. Legacy transfer links fail most often because the settings live in one person's memory.
If You Must Keep the BTR
- Photograph and record the BTR-to-control harness pinout before disturbing anything; that map is the only asset that survives if the BTR itself dies.
- Build a dedicated period host: real LPT on the motherboard, set to SPP/bidirectional in BIOS, DOS installed locally, no network stack.
- Image the working drive and store two copies offline. Keep the dongle attached to the machine, tethered and labeled.
- Keep the tape reader head, its cable, and any bypass jumpers on hand so the control can be returned to its original reader path for fault isolation.
What does a BTR do that an RS232 port does not?
A BTR injects characters into the control's parallel tape-reader input, impersonating the reader head, and is clocked by the control's reader-drive signal. An RS232 reader/punch port is a native serial interface on the control. If the control has a working serial port, the BTR is redundant.
Can I run the dongle-protected DOS BTR software in a virtual machine or DOSBox?
Generally no. Parallel-port dongles require register-level access to a real LPT port at a base address such as 0x378, and emulators typically do not pass that access through. Use a physical PC with an on-board parallel port set to SPP/bidirectional in BIOS.
Will a USB-to-parallel adapter work for the hardware key?
No. USB-to-parallel adapters enumerate as printer-class devices and do not expose the port registers or handshake timing the dongle needs. Use an on-board LPT port, or a card that presents a true SPP-compatible port at a standard base address.
What serial settings should I try first on an older CNC?
Start at 2400 baud, 7 data bits, even parity, 1 stop bit, XON/XOFF flow control, and confirm the required end-of-block and program delimiter characters. Prove the link by punching a resident program out to a PC terminal before attempting to send anything in.
Why does a long program transfer fail while a short one succeeds?
That pattern points to flow control, not to baud or parity. The control's input buffer fills and its XON/XOFF or RTS/CTS handshake is not being honored by the sender, so characters are dropped once the buffer saturates.