After sending ten actual ASCII NUL bytes at both file boundaries, the controller can recognize the completed program and leave EDIT <Store> mode. Typed zeros, comma-separated zeros, and the visible characters \0 are not equivalent to the required control byte.
Where does the HECC80/3 transfer stop?
Follow the data from the PC editor through the serial cable, UART, receive buffer, and file parser. Communication in terminal mode and Edit mode proves that some characters traverse the path. The failure occurs later: EDIT <Store> accepts the program body but waits indefinitely for a valid end-of-file delimiter.
| Path element | Observed condition | What it proves | What remains unproven |
|---|---|---|---|
| PC and communications software | CIMCO Edit sends data | The transmit operation starts | Whether it emits binary control bytes |
| RS-232 path | Terminal and Edit communication work | Basic transmit and receive activity exists | Signal quality throughout a complete file |
| UART and receive buffer | Program content can arrive | The receiver accepts ordinary program characters | Whether framing or flow-control errors occur during longer transfers |
| Store-mode parser | Mode does not terminate | The parser has not accepted the file terminator | Whether the required ten NUL bytes were transmitted |
The decisive distinction is transport success versus record-completion success. A readable terminal session verifies the path for printable characters; it does not verify that the sender can place byte value zero into the stream.
Which file-boundary encoding is correct?
The service instruction calls for ten ASCII nulls at the beginning and ten at the end. ASCII NUL is the nonprinting byte . It is not the printable digit zero, whose byte value differs, and commas add still more printable characters for the controller to parse.
| Editor representation | Bytes placed on the link | Suitable as the required boundary |
|---|---|---|
Ten inserted NUL control characters |
Ten bytes with value | Yes |
0,0,0,0,0,0,0,0,0,0 |
Printable zeros and commas | No |
| Ten typed zero characters | Printable digits | No |
Literal text \0
|
Backslash and zero unless the sender interprets escapes | Only if the software explicitly converts each escape to |
The working representation was \0 interpreted as nulls by the sending setup. That notation is software-dependent. Confirm what goes onto the wire rather than relying on how the editor displays a nonprinting character.
Why does terminal communication work while Store mode hangs?
Terminal traffic is character-oriented. Each printable character can be displayed or acted upon without establishing a complete stored-file boundary. Store mode is record-oriented: it must detect the prescribed preamble, receive the program, and then detect the terminating sequence before it can commit the record and return control to the operator.
If the PC sends printable zeros instead of NUL, the RS-232 electrical transfer may be flawless while the application parser remains in its receive state. Repeatedly changing baud rate cannot repair a correctly delivered but incorrectly encoded delimiter.
A missing terminator is the primary fault signature when the complete visible program appears to arrive and the controller never leaves Store mode. If the transfer stops partway through the body, characters are corrupted, or behavior changes with cable movement, investigate the physical link and UART settings before the delimiter.
How should the file and sender be configured?
- Create the transmit stream with exactly ten
NULbytes before the program. Use the editor or communications package function that inserts a control character or binary byte, not the keyboard digit0. - Place the program content after the opening sequence without converting the null bytes during file save, clipboard processing, or transmit preparation.
- Append exactly ten
NULbytes after the program. Do not separate them with commas, spaces, or line endings. - Inspect the prepared file in a byte-oriented or hexadecimal view. The first ten boundary bytes and last ten boundary bytes must each read
00. - Configure the PC serial settings to match the controller. Retain the known UART low-transmit setting unless testing identifies buffer overrun or flow-control trouble.
- Enter EDIT <Store> on the controller, start the PC-to-control transmission, and allow the final null sequence to pass before stopping or closing the sender.
Some text editors cannot preserve embedded bytes, and some terminal packages transmit escape notation literally. A hex view of the saved file tests storage; a serial capture or analyzer tests what the application actually transmitted.
What should be checked at the physical and serial layers?
Layer one first when the symptom includes missing blocks, corrupted characters, or intermittent transfers. The installation used a homemade RS-232 cable longer than 20 ft and planned a shorter replacement. Check conductor continuity, pin mapping, connector retention, shielding, routing near electrically noisy loads, and signal reference before changing application formatting.
A separate HECC80/3 installation transferred at 9600 baud over about 75 ft of well-shielded cable, with the transfer software limiting the speed. That result shows that a longer run can operate, not that every cable will do so. Cable construction, grounding, routing, interface implementation, and handshake wiring decide whether a particular link is reliable.
| Symptom | First check | Next decision |
|---|---|---|
| Terminal text is corrupt | Serial format, pinout, cable, and grounding | Correct the link before testing file markers |
| Short messages work but long files truncate | Flow control and receive-buffer behavior | Reduce transmit pressure or correct handshaking |
| Whole visible program arrives but Store remains active | Last ten transmitted bytes | Replace printable text with actual bytes |
| Failure changes when the cable moves | Connectors, conductors, shield, and routing | Repair or replace the cable |
How is the corrected transfer verified?
- Inspect both boundaries and count ten consecutive
00bytes at each end. - Send a short, identifiable program first so that file-format testing is separated from long-transfer buffer behavior.
- Confirm that the controller recognizes the opening boundary, receives the program, and exits EDIT <Store> after the closing boundary.
- Recall or display the stored program and compare its beginning, middle, and end with the transmitted content.
- Repeat the transfer. A repeatable exit from Store mode distinguishes a corrected terminator from an accidental operator abort or timeout.
FAQ
Why does the HECC80/3 stay in EDIT Store mode?
The store parser is still waiting for its end-of-file sequence. Send ten actual ASCII NUL bytes after the program, not printable zeros or comma-separated text.
Why are ten typed zeros rejected as ASCII nulls?
The digit 0 is a printable character, while NUL is byte value . They produce different serial data even though an editor may display nulls ambiguously.
Why does HECC80/3 terminal mode work when file storage fails?
Terminal mode proves that printable characters can cross the RS-232 path. Store mode additionally requires the correct ten-byte opening and closing delimiters before it can complete the record.
How do I verify the HECC80/3 file-transfer fix?
Confirm ten 00 bytes at each file boundary, send a short known program, verify that EDIT <Store> exits automatically, and recall the stored program for comparison.