Barcode scanner serial to ethernet converter into plant data tags

The scanner at the line speaks RS-232, and the controller that holds your plant data tags sits in another cabinet, another building, sometimes another plant. A serial cable will not reach, so the scan has to cross the network. A serial-to-Ethernet converter turns that into a socket problem: the scanner's bytes arrive as UDP datagrams or a TCP stream, and the tag engine writes them to tags. This walkthrough gives you the converter mode, the port number, the listener loop and the latency to expect, so the lot code from an operator's scan lands in the right tag every time. Of the usual ways to feed scan data into a PLC, this one wins when the run is long and the network is already approved.

How a serial-to-Ethernet tunnel works

A serial-to-Ethernet converter — device server is the generic name — terminates the scanner's RS-232 link and re-speaks it on Ethernet. Three settings define it: an IP address, a transfer mode, and how it packs serial bytes into network packets.

The mode decides who dials whom:

• TCP server: the converter listens, and the host connects out to it. One persistent socket, one host.
• TCP client: the converter dials a listener you open on the host. Several converters can point at one listener, one port each.
• UDP: no connection at all. Each packed burst arrives as one datagram with the source address attached.

For an operator-triggered scanner, pick UDP. A scan is one event, the operator hears the decode beep and rescans if the tag does not move, so delivery guarantees buy nothing. Pick TCP client when scans are machine-triggered and nobody watches; the connection-state flag becomes your alarm. The TCP client or listener decision for a network barcode reader carries over unchanged — on the network, a tunneled serial scanner is just another network reader.

What you need

• A scanner or fixed reader with an RS-232 serial output. The fixed code readers filter 28 models by a serial interface and the handheld code readers filter 9. A reader that already declares one, like the MV-ID6200PM-00C-NNG — a 20 MP logistics code reader with a global shutter — drops straight into this tunnel.

• One converter serial port per scanner; a two-line cell needs a two-port converter or two units.
• Converter power and mounting per its own manual, plus a static IP address or a DHCP reservation.
• A listener host on a reachable network: the controller, an edge gateway, or the server running your tag engine. Same subnet is the easy case; a routed path works too when the firewall allows the one port.
• Matching serial settings. 9600 baud, 8 data bits, no parity, 1 stop bit is the common factory default, and the scanner's actual configuration is what counts.

Wire the scanner to the converter

On a standard DB9 connector, pin 2 is receive, pin 3 is transmit and pin 5 is signal ground, named from the DTE side. A scanner and a converter are both usually DTE, so the cable crosses 2 to 3 in both directions — the null-modem arrangement — and carries pin 5 straight through. When a link powers up but delivers nothing, swapping pins 2 and 3 is the first test; it fixes most dead serial links. Use shielded cable, ground the shield at one end, and keep the run under about 15 m, the practical RS-232 limit at these data rates.

Set both serial ends to the same framing. A mismatch does not produce silence; it produces garbage characters, and the garbage-character diagnosis for a serial scanner link applies unchanged through a converter. While you are in the scanner's settings, fix its trigger behaviour too: the serial trigger and silent host command diagnosis explains why an ignored command looks identical to a wiring fault. The same swapped-pins and framing checks, in order, are laid out in this serial wiring and data troubleshooting walkthrough.

Configure the converter: address, mode and packet timing

Give the converter a static IP or a DHCP reservation and write it on the panel drawing; a scanner feeding tags should never change address after commissioning. Then set the mode to the pair you chose, and set the packing behaviour — the timeout that closes a packet after the line goes quiet. Set it to 50 ms. Below about 10 ms one scan can split across two datagrams; above 100 ms the tag update becomes visible to a person watching a dashboard. If the converter can frame on a delimiter byte instead, use the scanner's Carriage Return and the timeout stops mattering.

The converter-into-host arrangement is the standard cure wherever an RS-232 device has to reach a historian or tag database; this RS-232 to Ethernet converter data-acquisition walkthrough shows the whole chain on a PLC line.

Pick the port and open the firewall

The port bands are fixed: 0 to 1023 are the well-known service ports, 1024 to 49151 are registered for applications, and 49152 to 65535 are dynamic — the band operating systems draw outbound connections from. Three rules follow:

1. Stay above 1024. The low band belongs to system services and often needs privileges.
2. Stay below 49152. A listener there cannot collide with an outgoing socket on the same host, which is the failure that appears weeks after commissioning.
3. Avoid the host's own ports. Controllers and gateways publish a table of the ports their services reserve; one edge controller, for instance, documents two UDP service ports in the 22000 range.

Pick an unused registered port and record it; 21000 works as well as any. Then open exactly one firewall rule on the listener host: inbound UDP 21000, or TCP 21000 if you chose TCP. You will find the setting in the host's firewall or its web management. Before blaming anything else, ping the converter from that host — reachability first, socket second.

Open the listener and write the tag

1. Open the socket. For UDP, bind the host to your port and wait. For a converter in TCP client mode, open a server socket on that port and accept. In a controller's chart or scripting environment this is one comm-handle call; in raw code it is a plain socket open.
2. Read with a timeout. A few seconds at most, so the loop can run housekeeping and notice a dead socket. With UDP at a 50 ms packing timeout, one datagram is one scan.
3. Validate the frame. Expect the trailing Carriage Return you configured; reject anything without it. The prefix and suffix framing patterns for scanner input cover stricter schemes, including a fixed preamble.
4. Parse the payload. Split lot number from quantity at your delimiter and check both fields before writing anything; the lot and part number string-splitting pattern maps one to one. Hold the result as ASCII with an explicit length — the ASCII string storage patterns for PLC memory show the tag layout.
5. Write the tag and the event. Lot code to one tag, quantity to another, and a scan counter or timestamp that changes on every scan, so the dashboard animates on change instead of polling the string.
6. Alarm the silence. A TCP connection that drops, or a UDP port with no datagram for longer than one expected scan interval, raises an alarm. A stale lot number on a clean-room dashboard is the expensive version of this failure.

Worked example: scan-to-tag latency for a 15-byte lot string at 9600 baud

Inputs, and where each comes from:

• Payload: 14 characters plus the Carriage Return, 15 bytes — a lot code such as L24-0871A, a comma, and the quantity 1200, matching the lot-plus-quantity scan this build is for.
• Framing: 8N1, 10 bits per byte including start and stop bits (industry standard).
• Port speed: 9600 baud, the common scanner default.
• Packing timeout: 50 ms, the value set above.
• Network transport: under 1 ms across one switched hop.

The rule in words: line time equals bytes times bits per byte divided by port speed; scan-to-tag time equals line time plus packing timeout plus network transport.

Result: the tag updates about 66 ms after the beep. That clears any human-facing dashboard and any MES round trip budgeted in hundreds of milliseconds. The packing timeout dominates the total, which is why 50 ms is the setting that matters; the serial line itself could carry 9600 / 10 = 960 bytes per second, a 64-byte scan roughly every 67 ms. Decision: leave 9600 baud and a 50 ms packing timeout for operator scanning; raise the port speed only for continuous machine-triggered reading.

Verify it end to end

Ping the converter from the listener host; addresses and routes are cheaper to test than sockets. Fire a test scan and log the raw datagram before any parsing, so wiring faults and program faults separate cleanly. Watch the lot tag change and the scan counter step. Then run the failure drills: unplug the scanner and confirm the silence alarm fires within one scan interval; pull the network lead and confirm a TCP converter raises its connection flag and reconnects. With UDP nothing arrives during an outage and the tag holds the last lot — that is precisely what the silence alarm is for.

Wi-Fi handhelds look like a way to skip all of this, and plant IT groups refuse them often enough that a wired converter is usually the smoother approval. Decide the reconnect and alarm behaviour before commissioning; the barcode reader to PLC link planning guide lists those decisions. More tag-side patterns like this one sit on the systems topic page.

When the tunnel is the wrong tool

• Scanner within serial reach of the controller, say under 15 m, with a spare port on the CPU: wire it directly; the direct serial connection into a PLC CPU is the simpler machine.
• Long run with no network approval in sight: an RS-232-to-RS-485 pair carries the same bytes up to roughly 1200 m at these speeds, with no switch in the path. For the port choice on the scanner side, the RS-232 or USB decision for a scanner without Ethernet covers the trade.
• Buying hardware anyway: skip the converter and buy a reader with Ethernet on board. The MV-ID3013PM-12M-WBN, a compact fixed reader with a Fast Ethernet port, a 12 mm lens and a 1.3 MP sensor, talks to your listener directly and removes one box and one failure mode from the panel.

• Other RS-232 devices on the floor — scales, printers, meters — ride the identical tunnel; this RS-232 to Ethernet protocol converter walkthrough for scale data shows the same listener holding weighing data.

Common mistakes

• Converter and host both waiting: server mode on the converter plus a listener on the host means no connection ever forms. One side dials; pick which.
• Firewall closed: ping succeeds, the port stays deaf. The inbound rule for the one port is part of commissioning, not an afterthought.
• Port inside the dynamic band: works on the bench, collides months later when the host opens more outbound connections. Registered band, below 49152.
• Serial framing mismatch: garbage, not silence. Match baud, parity and stop bits on both ends.
• No frame delimiter: two fast scans concatenate into one string and the parse fails once a shift. The Carriage Return suffix prevents it.
• No silence alarm: the dashboard keeps showing yesterday's lot for hours. Counter tags and timeouts cost nothing.

Before you order

• The reader's interface line says Serial — filter the code reader finder by interface before committing to a model.
• Converter ports equal scanner count, plus one spare port in the panel.
• A static IP or reservation written on the drawing, and the port number next to it.
• The firewall request already filed with protocol and port, because IT lead times are the long pole in this project.
• Scanner configuration noted: 9600 baud 8N1 or your documented values, with the Carriage Return suffix.

If the reading hardware is still open, the build-a-system configurator and the finder cover the chain from scanner to tag, and the contact page takes a panel layout and a scanner list if you would rather have the link plan checked before you order.