Storing ASCII barcode strings in PLC memory: bytes, words and clears

A barcode scanner wired to a PLC serial port delivers ASCII, and the first questions are memory questions: how many V registers does one scan occupy, how do you clear it cleanly, and how do you keep the last few scans for comparison? The answers are fixed numbers. One character is one byte, a 16-bit register holds two, so a 14-digit code fills seven consecutive registers. This guide sizes the landing buffer, clears it without ghost text, builds a shift-table archive, and decodes what dataview text mode is telling you. It is written for anyone reading a barcode scanner into a PLC over serial and then staring at a text row that will not blank.

The rule: one character is one byte

ASCII assigns each of its 128 symbols a 7-bit code, and memory keeps one character per 8-bit byte (ASCII). A 16-bit V register is two bytes, so it holds two characters: one in the high byte, one in the low byte. That is the entire sizing rule, identical on any register-based PLC. The only thing that differs between platforms is which half of the word receives the first character, and one look in hex view settles that.

Odd lengths round up: a 13-character code still needs 7 registers, and the final byte sits alone in the last word. The same packing question appears whenever a device reports its serial number as raw registers, and parsing ASCII frames as bytes rather than floating-point words shows the protocol-side view of the same trap.

Worked example: a 14-digit barcode landing at V6010

The inputs: a 14-character scan from the reader, 16-bit V registers on the controller, a buffer base of V6010, and a dataview text row that displays V6010 through V6017, which is eight registers and sixteen character positions.

The rule in words: two characters per register, and a lone final character still claims a whole word.

The arithmetic:

• 14 characters ÷ 2 = 7 registers.
• Span from the base: 6016 − 6010 = 6, plus the base word, so V6010 through V6016 holds the scan.
• The text row covers two extra positions (V6017), which print as dots while that word is zero.
• A 10-scan archive: 10 × 7 = 70 words; based at V6100 it runs to V6100 + 70 − 1 = V6169.

A concrete payload shows the layout. Example scan 26833499104521, high byte first:

The decision this drives: allocate 7 words for the landing buffer, clear all 7 every cycle, 8 if you want the eight-register row to read as pure dots, and reserve 70 words for a 10-deep archive. At 50 rows the table is 50 × 7 = 350 words and a full search runs 350 word-compares; that is where string transport, covered below, starts earning its keep.

Clear the whole span, not one register

The clear is a load-and-output pair: LD K0 loads the constant zero, OUT V6010 writes it to the register. Seven registers take seven such rungs, or one loop with indirect addressing once the archive grows. The mistake that creates ghost text is clearing the base register only: the remaining six words of the scan keep their characters, and the dataview prints them right beside your fresh zeros.

Store, clear and archive: the steps

What you need: a scanner sending ASCII with a known terminator, the PLC port configured to match, and a block of free V memory sized as above. If the link prints garbage instead of characters, fix the serial settings before touching memory; packing cannot repair a mangled frame.

1. Fix the frame. Set the scanner's suffix to a terminator you can detect, and count what arrives — here 14 characters plus the terminator. The framing choices are laid out in prefix and suffix framing for barcode scanner input.
2. Size and place the buffer: 14 ÷ 2 = 7 words at V6010, consecutive and word-aligned, with nothing else writing in between.
3. Set the ASCII IN instruction to read 14 characters, so it stops at the frame end and never walks past V6016.
4. On scan-complete, block-move the 7 words from the buffer to row 0 of the archive at V6100.
5. Shift first, insert second: move row 8 to row 9, row 7 to row 8, and so on down to row 0 into row 1 — nine moves of 7 words for a 10-row table — then write the fresh scan into row 0. Row stride is 7 words.
6. Clear the buffer: LD K0, OUT V6010 through V6016, plus V6017 per the tip, so the next scan starts from all-zero bytes.
7. Compare on re-scan: word-compare the 7 buffer registers against each row, 7 compares per row and at most 70 for the full table. All seven equal is a match; one mismatched word rejects the row. Comparing words as integers sidesteps byte order completely, and comparing stored ASCII strings for a barcode match walks the same logic end to end.
8. Prove it: scan one code twice and confirm the compare matches row 0 in all 7 words; then clear and confirm the text row shows sixteen dots.

Why text view shows dots and old digits

Text mode prints one character per byte, two per register, and replaces every non-printable byte with a dot. A row of dots is the correct picture of zeroed memory, not a failed write. Unexpected digits are neighbouring registers: the row starting at V6010 displays V6010 through V6017, so a partial clear leaves live characters sitting beside your zeros. The classic sighting is ..8334.......... after clearing V6010 alone — the two leading dots are V6010's zero bytes, 8334 is old payload still standing in V6011 and V6012, and the trailing dots are the zeroed words beyond.

Hex view is the arbiter when text confuses. It shows two hex digits per byte, four per register: 3833 hex is the characters 83, and 3030 hex is the text 00. That word-to-character conversion is the same one behind converting hex bytes to ASCII strings in structured text, and it is where byte order reveals itself — do the one-time check there. In the software used here, CTRL+SHFT+F3 opens the dataview; put the same row in text and hex side by side.

Choosing the reader that feeds the registers

The memory math does not care how the ASCII arrives; the interface changes only the plumbing. The trade-offs of serial, USB and Ethernet into a PLC deserve a read before you commit a port. On the shop side, fixed code readers cover a bracketed scan at a known distance, handheld code readers cover operator scans at a bench, and smart cameras do double duty when the same station must also inspect. All of them feed the same seven-word buffer.

The LS-CRD-0047 is a compact fixed reader with a 60-120 mm reading distance. On Ethernet, the MV-ID3013PM-12M-WBN sends its decoded result over Fast Ethernet. At a bench, the LS-HCR-0001 is a handheld unit on USB 2.0.

For the wider range, start from the code reader finder.

When register packing is the wrong answer

Register rows win for fixed-length numeric codes: trivial clears, integer compares, 7 words per scan. They stop winning when payloads vary or carry structure. The decision:

For the third row, let the reader decode and hand the controller a finished string: mapping an EtherNet/IP barcode reader's implicit I/O assembly puts whole strings in the I/O image, and splitting the payload into lot and part number fields happens before any register is packed.

Commissioning checks

• Hex spot check on a known scan: V6010 must read 3236 hex for a code starting 26, confirming content and byte order at once.
• Text row after a clear: sixteen dots across V6010 through V6017, never the digit 0.
• Frame count: one scan writes exactly 7 words; a short write points at the terminator or the ASCII IN length.
• Re-scan match: the same code scanned twice matches row 0 in all seven words.
• Endurance: run clear, scan, shift and compare 100 times; the archive must hold the last ten scans with no drift into V6170.

Bring the symbology, the payload length and how many scans you must keep to the contact page, and the buffer and table sizes come back as numbers like these. More PLC-side vision wiring sits under vision systems integration.