HyperTerminal can capture DPRNT output when the CNC serial framing, cable wiring, flow control, and terminal settings match. A different terminal program will not correct an electrical or framing mismatch, although a diagnostic-oriented tool such as RealTerm can make received bytes and control-line states easier to inspect. Treat unexpected characters or missing records as a serial-link fault until a controlled test proves otherwise.
Signal timing behind the symptoms
The number that matters is the receiver's sampling time relative to each transmitted bit. An asynchronous serial receiver identifies a start bit and then samples the following data, parity, and stop-bit positions according to its configured baud rate. If the CNC and computer disagree about that framing, valid voltage transitions become invalid characters.
Classify the symptom before changing software. Consistently readable text followed by a missing final line points toward record termination or buffering. Repeated wrong characters point toward baud rate, data-bit, parity, or stop-bit disagreement. No characters at all directs attention to the selected port, cable pinout, transmit and receive paths, signal reference, handshaking, or whether the macro reaches DPRNT.
| Observed quantity or state | Failure boundary | Where to read it |
|---|---|---|
| Baud rate | Different transmitter and receiver timing | CNC communication parameters and terminal port setup |
| Data bits, parity, and stop bits | Different character framing | Both endpoint configurations |
| Received byte sequence | Bytes differ from the intended DPRNT record |
Terminal capture or byte-display view |
| Handshake state | Transmitter waits indefinitely or overruns the receiver | CNC flow-control setting, terminal setting, and control-line display |
| Record terminator | Receiver never displays or commits the final record | Captured bytes and CNC output behavior |
Serial transfer mechanism
DPRNT formats macro data and sends characters through the CNC's configured serial channel. The terminal application receives those characters through a computer serial port or serial adapter and renders or stores them. The macro, CNC communication configuration, physical cable, computer driver, port selection, and terminal configuration form one path; every layer must agree.
The terminal does not know what a CNC value means. It processes a stream of framed characters. Correct punctuation with wrong numeric content therefore directs the investigation toward macro formatting or variables, while corrupted punctuation and letters direct it toward the serial path.
Cable topology also matters. A straight-through connection and a crossover connection route transmit, receive, and handshake signals differently. Determine the required pinout from the CNC and computer interface documentation, then verify continuity pin by pin. A connector that fits mechanically does not prove that the signal paths are correct.
Software flow control uses characters within the data stream; hardware flow control uses dedicated control conductors. Selecting a method that the other endpoint does not use can halt transmission. Disabling flow control without checking the sender's requirements can instead permit lost characters when the receiver cannot accept data fast enough.
Configuration decision points
HyperTerminal is adequate when the job is simple text capture and its serial options expose every setting required by the CNC. Choose a diagnostic terminal when the fault requires raw-byte inspection, explicit control-line visibility, repeatable logging, or clearer separation between displayed text and captured data. Changing applications is a diagnostic decision, not the first repair.
| Condition | Likely area | Next decision |
|---|---|---|
| No data from any macro | Port, cable, transmit path, handshake, or CNC channel selection | Prove electrical routing and port ownership |
| Every character is unreadable | Baud or framing mismatch | Compare all framing fields side by side |
| Short records work; long records fail | Flow control, buffering, or output pacing | Inspect handshake behavior and captured byte counts |
| Text is readable but values are wrong | Macro variables or DPRNT formatting |
Test fixed literal text, then add variables |
| Only the last record is missing | Record termination, display buffering, or capture closure | Inspect the final received bytes before closing the session |
DPRNT capture procedure
- Read the active CNC serial-channel configuration. Record the baud rate, data bits, parity, stop bits, flow-control method, and any output-channel selection exactly as displayed.
- Identify the computer port assigned to the physical serial interface or adapter. Close other applications that could already own that port.
- Configure HyperTerminal with the same framing and flow-control values. Keep character echo and line-ending display options separate from the actual received data; local echo can make one transmitted record appear twice without duplicate bytes arriving.
- Verify the cable against the required endpoint pinout. Check transmit, receive, signal reference, and every control conductor used by the selected handshake method.
- Run a minimal macro path that emits fixed, recognizable text through
DPRNT. Fixed text separates communication faults from macro-variable conversion and numeric formatting. - Capture the session to a file, then compare the stored characters with the fixed test record. If the terminal supports a raw-byte view, inspect the line-ending bytes and any unexpected control characters.
- Add one formatted value at a time. When failure begins, compare the generated record length and formatting with the last successful test.
- Repeat the same test in a diagnostic terminal only if HyperTerminal cannot expose the byte or handshake information needed for the next decision.
Verification criteria
A successful test requires more than readable text on the screen. Run the same macro several times and compare the capture files. Each execution should produce the same byte order, separators, sign and decimal formatting, and record boundaries for the same input values.
Then test the longest expected record and the normal sequence of repeated records. Watch for truncated fields, merged lines, duplicated display caused by local echo, or pauses associated with flow control. Reopen the saved file with a byte-aware viewer when the final line appears absent; a display problem and a missing transmitted terminator require different corrections.
Finally, disconnect or select the wrong port deliberately and confirm that the test fails in the expected way. Restoring the correct path should restore repeatable capture. This proves that the observed data came from the intended CNC channel rather than cached display content or another serial device.
Recurring pitfalls and escalation boundary
Changing several serial parameters together destroys diagnostic information. Change one field, rerun the fixed record, and preserve the capture. Common traps include confusing local echo with duplicate transmission, treating a display line break as proof of a received terminator, selecting a similarly named computer port, and replacing terminal software before verifying the cable.
Serial adapters and drivers add another boundary. If bytes disappear only during sustained output, compare received byte counts across repeated runs and inspect handshake states. If corruption changes when the cable is moved or nearby equipment operates, check connector retention, signal reference, shielding practice, cable routing, and the physical interface before modifying the macro.
FAQ
Why does DPRNT output show unreadable characters in HyperTerminal?
The CNC and HyperTerminal usually disagree on baud rate, data bits, parity, or stop bits. Copy every active framing value from the CNC communication page into the terminal configuration, then repeat a fixed-text test.
Why does HyperTerminal receive no DPRNT data?
Check that the macro reaches DPRNT, the correct CNC output channel and computer port are selected, and the cable routes transmit to receive with a common signal reference. Also compare the flow-control method at both endpoints.
Why does DPRNT work for short lines but lose long records?
Long-record failures point toward receiver buffering, output pacing, or mismatched flow control. Capture repeated tests, compare byte counts, and inspect hardware-control states or software-control characters according to the configured method.
Why does each DPRNT line appear twice?
Local echo can display typed or transmitted content in addition to the characters received from the CNC. Disable local echo for the test and use the capture file, not the screen alone, to count received records.
When should I stop troubleshooting DPRNT and contact support?
Stop after verified pin-to-pin wiring, matched framing, confirmed port ownership, and a repeatable fixed-text test still produce missing or corrupted bytes. Preserve the CNC communication settings, macro test, cable pinout, terminal configuration, capture files, and repetition conditions, then escalate to the CNC manufacturer's official support channel or the serial-interface supplier.