Handle STX and ETX framing from a barcode scanner in a PLC

Your scanner is set to 57600 baud, 8 data bits, no parity, 1 stop bit, with STX and ETX as header and footer — and the PLC shows nothing usable, because a receive configured for a fixed length never sees the length it expects. Codes on this line run up to 25 characters and change length day to day, so the frame must end on the ETX byte (0x03), not on a byte count. This guide walks the whole fix: port settings, a 32-byte receive buffer, termination on 0x03, stripping the STX (0x02) before the compare against the stored good scan, and re-arming on every trigger. The arithmetic is short — 27 bytes at 57600 baud lands in about 4.7 ms — and every number you need is on this page.

What do STX and ETX do in the scanner's frame?

STX (0x02) and ETX (0x03) are one-byte control characters that wrap the barcode: the scanner sends STX, then up to 25 data characters, then ETX, so a 25-character code travels as a 27-byte frame. Both sit below 0x20 in the ASCII table — "start of text" and "end of text" — and neither prints, which is why a string display shows nothing where they stand. They are framing, not data: the 25-character limit is payload only, and the two extra bytes ride in every frame.

Some scanners append a checksum or a CR/LF pair after the ETX. Turn those off: bytes that arrive after your end condition stay in the port and open the next frame. Suffix programming is the same mechanism as adding an Enter key with programming barcodes, just with control characters. The framing idea also works with printable characters — prefix and suffix framing for scanner input covers that side — and some devices are stricter in the other direction, rejecting serial queries without exact STX and ETX bytes.

Why does a fixed-length receive lose scans?

A fixed-length receive completes only when its exact byte count arrives, so a 20-character code inside a 27-byte window sits unfinished until the next scan's bytes fill the gap and the two scans merge into garbage. The receive has no other way to know a scan ended; the length is its only end condition. With codes that change length day to day, every mismatch breaks it:

• A 22-byte frame (a 20-character code) in a 27-byte window: the receive waits for 5 bytes that never come, then completes on the start of the next part's scan.
• A 27-byte frame in a 25-byte window: the receive closes after STX plus 24 characters, and the last character and the ETX leak into the port — the classic "downloaded the example ladder and it never reads" symptom.

The same root cause bites with printable terminators; variable length scanner input fixed with a suffix works the identical logic for that case.

How big should the receive buffer be?

Size the receive area at 32 bytes: your longest frame is 25 characters plus STX and ETX, which is 27 bytes, and 32 leaves headroom for one stray suffix byte and the port's terminator handling.

When the receive routine asks for the buffer size, give it 32: the slack over the 27-byte worst case also covers routines that want the buffer one byte longer than the longest frame they store.

How do you end the receive on ETX?

Set the port's end-of-receive condition to a termination character, enter 0x03, and turn the fixed length off — that one change makes every scan, from 5 to 25 characters, end on its own ETX. Port firmware names the setting differently — "end code", "termination character", "delimiter", "receive end condition" — and it lives in the serial port configuration or in the control block of the ASCII receive instruction.

1. Set the port format identical to the scanner: 57600 baud, 8 data bits, no parity, 1 stop bit, no flow control.
2. Set the end-of-receive to a termination character with the value 0x03 (hex 03, decimal 3 — enter it in the radix the editor expects).
3. Turn the fixed length off. If the port demands a maximum length, enter 32 so the ETX always wins the race.
4. Point the receive at a 32-byte data area and clear it to zeros at every arm.
5. Arm the receive on the rising edge of the part-present trigger, not on a free-running timer.
6. Parse on the done flag; flush and re-arm on a timeout.

If you also write to the scanner over the line — to trigger or configure it — the request carries the same two bytes, and sending STX and ETX with an ASCII write instruction shows the transmit side. For the copper, wiring an RS232 ASCII string from a scanner into a PLC serial port has the pinout and ground rules.

How do you strip STX and compare the payload?

Copy the bytes between the two control characters into a separate compare string — everything after the 0x02 up to the 0x03 — and run the equality test on that string against the stored good scan. With the port stopped at ETX, the buffer holds STX, payload, ETX in that order:

1. Locate the 0x02; in a cleared buffer it sits at byte 0.
2. Copy bytes 1 through (count − 2) into the compare string — that range is the payload, 1 to 25 characters — and leave byte (count − 1), the ETX, behind.
3. Write the payload length into the string's length field; filling the two length bytes when converting a CHAR array to a STRING is the step first programs miss.
4. Compare for equality against the stored good scan, captured through this same path on the learn pass so both strings get identical treatment.

Two failure modes live in that buffer, not in your compare logic: stale bytes from the previous scan left between old payload and new, and a parse that runs while the receive is still filling. Framing ASCII barcode data in the PLC receive buffer covers both — a zeroed buffer at every arm and parsing only on the done flag end them. If the trigger stays made long enough for one part to deliver two frames, handling repeat scans with a timeout gates the second one.

How do you re-arm the receive for the next part?

ASCII receive instructions run once per trigger edge, so re-arm the receive every cycle: your trigger sensor raises the arm, the ETX sets the done flag, and your logic clears and rearms for the next part. The instructions are one-shot by design — ASCII receive instructions that execute once need retriggering each scan — and the per-part sequence is four rungs:

1. Trigger rising edge: zero the 32-byte buffer, arm the receive, start a 500 ms timer.
2. Done flag: parse, compare, set the match or reject output.
3. Timer done with no ETX: flush the port, count a reject, re-arm. A missing ETX is a scanner or wiring fault, not a slow barcode.
4. Trigger falling edge: reset the outputs and wait for the next part.

If the trigger sensor has to reach both the reader and the PLC, an I/O box from the reader accessories range keeps that wiring tidy.

What do you check when the link still reads nothing?

Check three things in order — the port settings (57600, 8 data bits, no parity, 1 stop), the cable crossing (scanner TX to PLC RX with a common ground), and the scanner's own suffix settings, which a terminal program shows in one minute.

• Port equals scanner, on the right port. 57600, 8, none, 1, no flow control — and confirm the ladder reads the port the cable actually occupies.
• Terminal test. A terminal program on the line at the scanner's settings shows the frame in seconds and splits the fault scanner-side or PLC-side.
• Nothing at all points at the cable; garbage points at baud or format. Fixing garbage characters from a barcode scanner on a PLC serial link walks that side.
• Levels. An RS-232 scanner output needs an RS-232 port; a TTL-level scanner into an RS-232 port reads nothing at any baud, and one level converter settles it.

When is a networked code reader the better fix?

Move to a networked reader when the serial framing has cost you more than a day: an Ethernet code reader hands the PLC one complete string per trigger and the end-character question disappears. Long RS-232 runs past roughly 15 m, several scanners on one line, or a need to archive an image with every read all push the same way. Scanner input methods to a PLC — serial, USB and Ethernet compares the three paths, and wiring the reader as a TCP server with the PLC as the client is the usual pattern.

For the bracket, the dual aviation plug LS-CRD-0052 is the fixed reader we would hang there: industrial connectors, and one Ethernet string per trigger.

At short standoffs, the compact LS-CRD-0047 covers a 60-120 mm reading distance over USB 2.0.

The decision for your line: terminate the receive on 0x03, size the buffer at 32 bytes, strip the 0x02 before the compare, and re-arm on every trigger edge. Fixed length is right only when every code is exactly N characters; a silence timeout is right only when the scanner sends no terminator at all; and a serial link that still fights after the checks above earns a networked reader, not a fourth weekend.

Start from the code reader finder or the fixed code readers category, or bring your scanner's settings page to the contact page and we will mark the exact setting names for your controller.