Barcode reader PLC communication: plan a reliable link

A successful scan is only the beginning of a material-identification transaction. The controller must receive a complete identifier, associate it with the correct request, and reject missing, repeated or invalid messages. This matters when a reader moves between material tanks while its receiver remains near the control equipment. You can design that link reliably by separating the wireless hop, the wired interface and the application handshake. Start with the data contract and acceptance tests, then select hardware that can implement them.

Choose the architecture before the reader

For barcode reader PLC communication across a wireless hop, a practical starting point is a reader paired with a receiver that provides a documented industrial interface. Put the receiver near the PLC when that keeps the final wired connection short and straightforward.

There are several possible arrangements:

A receiver that types into a computer is not automatically suitable for a PLC. Keyboard-style output and a serial character stream are different interfaces, even when the connectors look familiar.

Likewise, an Ethernet connector does not establish support for the PLC's application protocol. Where a gateway maps messages into registers, the PLC integration guide for vision-controller Modbus communication explains the additional register and handshake decisions.

Treat the radio equipment as a separate selection task. The catalog examples later in this guide establish wired-reader options only, not a complete wireless combination.

Write an interface contract for every connection

Draw the complete path: reader, radio link, receiver, optional gateway and PLC. Label each connection with its electrical interface, protocol, message format and ownership of acknowledgments.

For a serial connection, record:

• Electrical standard, such as RS-232 or RS-485.
• Connector pinout and signal direction.
• Baud rate, data bits, parity and stop bits.
• Hardware or software flow control, if required.
• Message terminator, maximum length and timeout behavior.
• Whether output is automatic after decoding or requires a command.

RS-232 and RS-485 are not interchangeable. A passive connector adapter does not convert their electrical signaling. Similarly, a USB connector does not tell you whether the device is a host, a peripheral or a supported PLC accessory.

For Ethernet, document connection roles, addressing, transport and application protocol separately. A raw TCP socket is not a register protocol. TCP also delivers a byte stream: one receive operation may contain part of a message or several messages together.

Select cables using the documented pinout, electrical interface and installation requirements, not connector appearance. The accessory finder helps organize that selection, but a cable listing alone does not establish device compatibility.

If a reader decodes locally but produces no output after a command, use the checks in diagnosing silent serial scan commands before changing the radio arrangement.

Define the barcode message byte by byte

For a material identifier containing 14 alphanumeric characters, a simple contract could specify exactly 14 uppercase letters or digits, followed by carriage return and line feed. That is an application example, not a setting guaranteed by every reader.

A visible representation is:

A1B2C3D4E5F6G7<CR><LF>

The angle-bracket labels represent control bytes; they are not characters printed in the barcode. In this example, carriage return is hexadecimal 0D and line feed is hexadecimal 0A. The complete message occupies 16 bytes when encoded as ASCII.

Document whether the barcode itself contains only the identifier. Configure any reader prefix, suffix, symbology identifier or status text deliberately. An unexpected prefix can turn a valid identifier into an overlength message.

A safe parser should accumulate bytes until the complete terminator arrives. It should then check length and allowed characters before publishing the identifier. If a terminator never arrives, discard the incomplete message after a defined timeout and record a framing fault.

If arbitrary binary data or embedded delimiters must be supported, use a documented length-based or escaped format instead. Do not invent a framing scheme that either endpoint cannot implement.

Preserve identifiers as strings. Converting them into numbers can remove leading zeros and makes mixed letters and digits impossible to represent correctly.

Make acceptance a transaction, not a display update

The PLC should distinguish between receiving bytes and accepting a material transaction. A useful state sequence is ready, receiving, validated, committed and acknowledged. Fault and timeout states must be explicit rather than implied by an unchanged value.

Keep separate fields for the identifier, transaction identity, validity, age and diagnostic status. Do not overwrite the last accepted identifier while a new message is still being assembled.

Where the equipment supports it, include a transaction sequence and session identity in the application exchange. A gateway may add these fields around a reader's plain-text output. Verify which component creates them and which component preserves them during retries.

For a repeated transaction, acknowledge the already committed operation without executing it again. However, do not reject every repeated barcode value: the same material may legitimately be scanned twice for different requests. Duplicate suppression belongs to the transaction identity, not just the identifier text.

If the reader emits only an unnumbered string, automatic retry deduplication may be ambiguous. A controlled scan window or gateway-managed request can reduce that ambiguity, but cannot manufacture information that the source never supplied.

The distinction between event handling and repeated updates is explored in barcode scan event handling without recursive updates.

Finally, define feedback precisely. A decode indicator means the label was read. A receiver acknowledgment may mean only that the radio delivered it. Neither proves that the PLC accepted the material. Communicate process acceptance only after validation and commitment.

Budget latency with a worked example

Replace “immediate” with a measurable deadline. Define its starting event, its finishing event and the permitted failure behavior. For example, measure from the reader's completed decode to the PLC's accepted-transaction status.

Serial transmission time can be estimated directly. With 8 data bits, no parity and 1 stop bit, each character also has a start bit, giving 10 transmitted bits per byte.

For the 16-byte example at 9,600 bit/s:

16 × 10 / 9,600 = 0.0167 seconds
Serial transmission time ≈ 16.7 ms

This excludes radio retries, device buffering and PLC execution. It also excludes command and acknowledgment traffic.

Suppose an illustrative acceptance budget allocates 80 ms to decoding, 120 ms to radio delivery, 30 ms to buffering, 17 ms to serial transfer and 40 ms to PLC handling. The total is:

80 + 120 + 30 + 17 + 40 = 287 ms

These are planning assumptions, not product specifications or promised performance. Replace them with measured values under representative conditions.

For an illustrative 500 ms deadline, the remaining allowance is 500 − 287 = 213 ms. That allowance must cover observed variation and recovery behavior; it is not proof that the system meets its deadline.

Check sustained throughput separately. A single transaction completing quickly does not establish behavior during a burst. Define queue capacity and what happens when it fills: reject with feedback, pause new requests or store transactions using a documented policy. Silent overwriting is not acceptable.

Treat wireless distance as an acceptance requirement

A required separation of 25–30 m is a site requirement, not sufficient evidence that a particular radio will work. Metal tanks, intervening structures, receiver position, operator orientation and other radio traffic can change delivery behavior.

Test the entire working route, including positions where the operator's body blocks the direct path. Include normal equipment activity and other expected wireless use. Record successful delivery, end-to-end latency, retries when available, and connection recovery.

A brief successful demonstration does not characterize an intermittent link. Exercise stationary and moving scans, weak-coverage locations, reconnection and receiver power cycling.

During an outage, decide whether scanning is prohibited or messages are stored. If storage is allowed, preserve transaction order, age and identity. A delayed scan must not silently satisfy a newer material request.

Use the equipment's documented pairing and security controls. Keep network-connected receivers on an approved automation segment, and restrict configuration access according to the site's controls policy.

Select wired components without assuming wireless support

Browse fixed code readers and the camera and reader finder when evaluating an engineered reading station. These are useful alternatives when an operator can present the tank label at a defined location or the process can bring the label to a reader.

The LS-CRD-0028 lists Fast Ethernet. Treat it as a wired fixed-reader candidate whose supported output protocols must still be confirmed.

The LS-CRD-0052 lists Ethernet. Its connector and network interface do not, by themselves, establish compatibility with a PLC application.

Neither catalog entry here establishes wireless operation, transaction acknowledgments or a compatible radio bridge. Do not specify either as a wireless handheld replacement on that basis.

Consider vision controllers when image processing, multiple readers or application-level coordination actually requires them. A controller is not automatically a protocol converter; its documented software and interfaces must cover the proposed task.

Before changing an existing installation, follow the reader configuration backup checklist. Preserve the working interface settings and record each change so testing remains reversible.

Verify faults before relying on the material value

Begin with a direct wired bench connection where practical. Confirm the exact received bytes before adding the radio hop. This separates parser faults from wireless delivery faults.

Use controlled tests with known expected outcomes:

Inject malformed input only through a controlled test harness or documented test facility, isolated from live actuation. Record receive counts, accepted transactions, rejected messages, timeouts and duplicates separately.

Check business validity after syntax. A correctly formed identifier may still name the wrong material, an inactive lot or an unapproved tank. The barcode-to-part verification guide explains why a successful decode is not the same as a correct match.

For each accepted transaction, retain enough diagnostic information to reconstruct its request, source and timing. Avoid logging only the latest displayed identifier, because that hides intermediate failures.

Know when the usual arrangement is wrong

A direct serial receiver is attractive when the PLC already supports character handling and the transaction is simple. It becomes less suitable when the application requires multiple mobile readers, persistent queues or detailed recovery after interruptions.

A gateway can centralize those functions, but adds another configuration, power dependency and failure point. Choose it because its documented behavior fills a specific gap, not because it has matching connectors.

An HMI may provide an operator workflow or mapped data area, but it does not automatically eliminate protocol configuration or acknowledgment design. Verify its actual reader support and PLC mapping.

If the process requires a tightly bounded decision time, do not assume a general wireless link can provide it. A fixed wired station may be the better design when delayed or missing identification would create unacceptable process consequences.

If operators only need to transfer occasional identifiers, elaborate image-processing hardware may add no value. Start with the simplest architecture that meets the acceptance, recovery and traceability requirements.

Checklist before ordering and commissioning

• Define the payload: state identifier length, character set, prefixes and terminators so every component handles the same message.
• Confirm each interface: obtain documented electrical details, pinouts, connection roles and application protocols.
• Identify acknowledgment ownership: distinguish decode success, radio delivery and PLC acceptance in both logic and operator feedback.
• Set timing limits: specify the deadline, message timeout, queue policy and behavior after reconnection.
• Prove duplicate handling: test repeated transactions separately from legitimate repeated scans of the same material.
• Survey the working route: qualify radio delivery at actual scanning positions rather than relying on nominal distance alone.
• Test stale and invalid data: keep incomplete or delayed messages from becoming the current material selection.
• Preserve configuration: save reader, receiver, gateway and PLC settings with the test record.

For the next step, send the interface contract, required working distance and acceptance criteria through applications support. Once compatibility is confirmed, use the accessory configuration step to organize the documented cable and connection requirements.