ASCII CR and LF Command Terminators: Send the Actual Bytes

A command terminator is one or more actual bytes appended to the command, not the characters you see in an editor. Check whether the device requires carriage return, line feed, both or another framing rule, and whether your terminal or driver already appends it. Duplicating or omitting an ending can make correct-looking commands fail.

The fastest diagnosis is a byte-level comparison between a working transmission and the failing one. Screen appearance often hides exactly the difference you need to find.

Identify the byte and its representation

RFC 20's ASCII table defines carriage return as hexadecimal 0D and line feed as hexadecimal 0A. Their names do not make them interchangeable. The device protocol decides which one ends a command.

As a concrete manufacturer example, Epson's EB-PU specification, section 3.2, requires a carriage return at the end of its ESC/VP21 commands. That requirement belongs to that documented interface; it should not be transferred automatically to an unrelated manufacturer's protocol.

Find which layer owns the ending

Draw a small path from the configured command through its driver to the device. A command field may contain plain text, escaped text or hexadecimal data. A protocol-specific driver may add the terminator itself. A serial terminal can have a separate Send CR option even when the text field looks unchanged.

Enable only the documented behavior at one layer. If the driver appends CR, leave it out of the stored body unless that driver's instructions say otherwise. If using a generic byte sender, include the required byte explicitly through a supported representation.

Save the exact tool mode with a working command. Copying just the visible text from a technician's terminal into another application loses the terminal's encoding and line-ending settings.

Inspect the reply as well

A receiver may use a different reply ending from the command ending. Capture both directions in hexadecimal when possible. If a parser waits for CRLF but the reply contains only CR, it can hold a complete response indefinitely and report a timeout.

Avoid removing all whitespace indiscriminately. Spaces inside a command or response may be meaningful parameters. Strip only the documented framing bytes after a complete frame has been identified.

When a command works once but the next returns an error, inspect whether an extra line ending created an empty command. When nothing happens, inspect for a missing terminator or literal escape text before changing serial baud rate or network settings.

Acceptance should preserve the evidence

Test a known read-only query in the final application, not only a terminal. Save command bytes, reply bytes, tool mode and device identity. Then reconnect and repeat to exclude leftover buffered data.

Deliberately test the wrong ending in a safe bench environment and record the resulting symptom. This creates a useful support signature without asserting that every device rejects it the same way.

Preserve text representation and actual byte sequence side by side in the engineering note. Name the layer that appends the ending and the payload encoding. After importing the profile into another application, compare the resulting bytes again. This catches smart punctuation, trailing spaces and literal escape sequences before they spread across a fleet. Save the original known working query too, so a service technician can reproduce the same harmless comparison without guessing which operation was used during commissioning.

For broader ASCII and binary formatting, see the command-format guide. Discuss the command field's decoding rules with an integration partner before distributing a reusable profile to technicians.