You mounted the reader, taught the symbology on a clean sample, and the HMI's barcode-scanner object still shows no connection. On the panel the symptom is always the same: a blank tag or a timeout after a few seconds. The cause is almost never the decode itself. This guide walks the failure in the order that finds it fastest: the IP layer first (does the reader answer ping from the HMI's subnet?), the transport second (is one end listening on the port the other end calls?), and the data last (does the string leaving the reader match what the recipe parses?). With a laptop on the bench you can clear all three in under an hour, and the same checks apply unchanged to a PLC or PC host.
The failure tree: link, transport, data — in that order
A first connection that never establishes is one of three mismatches, and each test takes minutes:
- IP layer. The reader's address and mask do not place it in the HMI's subnet, so nothing the HMI sends ever arrives. Test: ping the reader's address from the HMI, or from a laptop standing in for it.
- Transport. Both ends are configured, but the direction, the protocol or the port disagrees — the object polls a port nothing listens on. Test: open the reader's port from a laptop before touching the HMI again.
- Data. The link is up and the tag is still wrong or truncated: the reader's output format and the recipe disagree on terminator, length or preamble. Test: capture one result string and read its final bytes.
Work in this order because each layer hides the next — you cannot debug parsing over a socket that does not open.
| Symptom on the panel | Most likely cause | 10-minute test | Fix |
|---|---|---|---|
| Ping to the reader times out | Reader outside the HMI's subnet, cable fault or duplicate address | Ping from a laptop set into the HMI's subnet | Static reader address inside the HMI's plan |
| Ping works, object shows no connection | Wrong port or wrong client/server mode | Terminal session from a laptop to the reader's port | Reader as TCP server on a fixed port, object as client on the same port |
| Connection opens, tag stays empty | Trigger mode or result routing | Trigger a read and watch the reader's own tool | Route results to the TCP output and align the trigger scheme |
| Tag shows partial or wrong characters | Terminator, length or preamble mismatch | Capture one string, inspect the last bytes | Match terminator and length at both ends |
Step 1: the IP layer — same subnet or nothing
Both devices must sit in one subnet before any port setting matters. A reader straight from the box sits on the fixed address its quick-start sheet states; your HMI sits in the machine network. When the two plans differ, ping times out and every later setting looks broken.
The check is a bitwise AND of address and mask:
The fix: give the reader a static address inside the HMI's plan — 192.168.1.30 with mask 255.255.255.0 against an HMI at 192.168.1.10 — and leave DHCP off the reader for good. To reach it before the change, set a laptop into the reader's own subnet (192.168.0.99 with the same mask), open the reader's web page or setup tool, apply the new plan, then ping 192.168.1.30 from the HMI's side until it answers in 1-2 ms.
Three address faults survive that fix: a duplicate address (ping replies that come and go), a mask that differs at the two ends (traffic leaves one side and never comes back), and a gateway set where none is needed — leave it at 0.0.0.0 on a direct cable or an isolated switch, because a gateway only routes traffic out of the subnet. No name resolution is involved either: enter the numeric address in the object, never a host name.
Any fixed code reader with an Ethernet interface drops into this plan, for example the MV-ID3013PM-12M-WBN, a 1.3 MP compact reader with an M12 lens mount on Fast Ethernet.
- Interface
- Fast Ethernet
- Resolution
- Up to 3 MP
- Shutter
- Global
- Lens mount
- M12
Step 2: the transport — who connects, and on which port
An HMI barcode-scanner object polls. It opens the connection, requests reads and drops the link on screen change, so the reader must be the TCP server and the object the client. A reader left in client mode spends its time calling outward to the HMI, which has no listener, and the object reports no connection while both ends look correctly configured. This direction mismatch is the most common transport fault on a first bring-up.
On ports: Ethernet readers of this class leave the factory with results on TCP port 23, the old telnet port, and the vendor's setup tool can move it — the default comes from the reader family's own communications guide. Modbus TCP, where the reader offers it, listens on port 502, a number registered with IANA and identical everywhere. EtherNet/IP reaches a reader on TCP 44818. If you choose your own port, pick one above 1023 and enter the same number at both ends; a mismatched pair fails exactly like a closed port.
One more transport rule: many readers hold a single control connection at a time. If the vendor's desktop tool is still open on the bench PC, the HMI's attempt is refused. Close every tool and terminal session, then retry.
The test from the laptop: open a terminal to 192.168.1.30 on port 23. A session that opens and stays open proves a listener; trigger a read and the result scrolls by. An instant refusal means nothing listens there — wrong port or wrong mode. For the direction decision with other hosts, TCP client or listener: match your network barcode reader to your host sets out the rule, barcode reader as TCP server: wire your PLC as the client does the same for a polling PLC, and barcode reader to PLC over raw TCP sockets without EtherNet/IP shows the socket-level detail. A PLC does the same job with block instructions: a worked example with TSEND_C and TRCV_C against an Ethernet reader follows the identical pattern.
In the HMI project software, add the object once and set its address, port and mode there — on this class of panel the barcode-scanner object sits under Objects » Barcodes » Barcode Scanner.
Connector quality matters on a moving line: the LS-CRD-0052 is a 1.2 MP reader with a 12 mm focal length, wired through dual aviation plugs on an Ethernet interface.
- Resolution
- Up to 3 MP
- Shutter
- Global
- Interface
- Ethernet
Step 3: the data — the string the recipe actually parses
Once the socket opens, three data faults account for nearly everything left:
- Terminator. A reader typically ends each result with CR+LF (0x0D 0x0A), LF alone, or nothing but a fixed length. The recipe expects one of the same three. A recipe waiting for a terminator the reader never sends waits forever; a fixed length shorter than the payload truncates the tag. Capture one string with a laptop listener and look at the last two bytes before changing anything.
- Preamble. Some readers prefix the symbology name or a station label to the payload. Disable the preamble in the reader or plan the parse around it, or the prefix rides into your tag on every read.
- Trigger scheme. If the object requests each read, the reader must be in on-demand mode and answer the object's trigger; if the reader streams continuously, set the object to accept unsolicited data. Continuous streaming with a terminator-keyed recipe is the simplest pairing.
The same framing discipline on a serial link is shown in barcode scanner to an HMI serial port: framing data without headers.
Worked example: one reader, three faults, twenty minutes
Bring-up on a fresh station. HMI at 192.168.1.10 with mask 255.255.255.0; object in client mode pointed at 192.168.1.30, port 23.
-
Ping fails.
ping 192.168.1.30times out. The subnet math above says why: the reader still sits on its default 192.168.0.30, which ANDs with the mask to 192.168.0.0, not 192.168.1.0. Laptop moved to 192.168.0.99, reader's page set to 192.168.1.30 with mask 255.255.255.0, laptop moved back — ping now answers in 1 ms. - Object still red. A terminal session to 192.168.1.30 on port 23 is refused instantly. The reader was left in client mode from a bench test, calling out to 192.168.1.10 on port 4001. Reader set to server on port 23; the session opens; a triggered read scrolls the tag text. Close the session — one client only — and the HMI connects on its next attempt.
-
Tag truncated. The label carries 1234567890 but the panel shows 123456. The reader sends
1234567890plus CR+LF — 12 bytes: 31 32 33 34 35 36 37 38 39 30 0D 0A. The recipe used a fixed length of 6 with no terminator. Recipe set to terminator CR+LF with length 10: the full tag appears, every read.
Total elapsed time about 20 minutes, and the reader was decoding perfectly the whole way through — every fault lived in the settings.
Checks before you blame the HMI, or the reader
- Decode first: read your samples with the reader vendor's own tool before any networking. If the tool cannot read, the problem is optical, not protocol — module size, angle and distance rules are in code 128 barcode module size, reading angle and reader distance.
- Check the link LEDs at both ends, then swap in a known-good cable; a lead that tests fine on the bench and fails in the duct is common enough to rule out early.
- Stand-in host: a laptop set into the HMI's subnet proves the reader side in isolation.
- One client at a time: close vendor tools, terminal sessions and any second project still polling.
- Run a continuous ping from one host while the line is quiet; intermittent replies mean a duplicate address.
- Power-cycle both ends after address changes — some readers apply the mask only at boot.
- If the model uses a laser aimer, keep eyes out of the beam while jogging the mount; LED-illuminated imagers need no such care.
When Ethernet is not the answer
For one bench station or a single operator screen, a wired USB or serial link deletes the whole IP layer and half of this article. The USB path is covered in fixed code reader setup over USB: first connection and readback checks, the keyboard route in keyboard wedge barcode readers and focus in your HMI, and the serial Modbus route in read a barcode reader into a PLC over Modbus RTU. Choose Ethernet when the run passes a few metres, when one host polls several readers, or when the same reader feeds both a PLC and a panel; choose USB or RS232 when the cable is short and the settings sheet must stay one line long. And if the goal is live inspection images on the panel rather than a decoded string, that is a different pipeline — one smart cameras fill natively, covered in smart camera image in a PLC HMI: what actually displays live.
Two fixed readers that suit an HMI link: the MV-ID813M-05S-WBN-SR on GigE with a 4.9 mm focal length, and the LS-CRD-0028 on Fast Ethernet with an 8 mm lens at 30 fps.
- Interface
- GigE
- Resolution
- Up to 3 MP
- Interface
- Fast Ethernet
- Resolution
- 5 MP
Make it stay fixed
Write five values on the commissioning sheet and in the HMI project's device notes: reader address, mask, mode, port, terminator. Keep readers on static addresses; if the plant runs DHCP, reserve or exclude those addresses so nothing steals them. Label the reader's address on its bracket, and hold the bench rule of one client at a time.
When you are specifying rather than debugging, the fixed code readers category and the camera finder filter by interface and resolution, the code-reading guides collect the host-side articles, and the system configurator builds the whole station. If the link still refuses after all three layers, send those five values plus one captured string through the contact page — that is enough to pinpoint the failing layer without another site visit.
Questions
Why does ping succeed but the HMI object still shows no connection?
Ping only proves the IP layer. The object then opens TCP, so check the transport next: the reader must be in server mode listening on the exact port the object calls, and nothing else may hold that socket, because vendor tools and leftover terminal sessions count as clients. Note also that many HMI barcode objects attempt the connection only while their screen is displayed — test with the reader screen active on the panel, not from the start screen.
Should the barcode reader be the TCP client or the TCP server?
With an HMI barcode-scanner object, make the reader the server. The object polls: it opens the connection, requests reads, and drops the link on screen change, which only works against a listener. Reader-as-client suits a PLC or PC running its own listener that receives a push on every trigger. If the reader offers only push mode and the HMI cannot listen, use Modbus TCP instead, since most panels read registers happily.
Is TCP port 23 the correct port for an industrial barcode reader?
Port 23 is the factory default result port on Ethernet readers of this class, inherited from telnet, and the vendor's setup tool can move it. It is correct only if the HMI object calls the same number. Port 502 belongs to Modbus TCP and 44818 to EtherNet/IP, both fixed by registration. If you choose your own port, pick anything above 1023 and enter it identically at both ends; a matching pair beats any particular number.
Can I read the barcode over Modbus TCP instead of a raw string?
Yes, when the reader has a Modbus TCP server, which listens on port 502. The decode lands in holding registers, so the HMI reads a register block into the tag instead of managing sockets. The gains are deterministic polling and easy PLC sharing. Size the block for your longest expected payload plus two spare registers, and poll at least twice as fast as parts present, or you will read one code onto two parts.
Why does the connection drop and re-establish every few seconds?
Look for a second client or a duplicate address. Many readers accept one control connection, so a bench laptop or a vendor tool steals the socket each time it reconnects, bouncing the HMI. A duplicate IP does the same to all traffic: run a continuous ping from one host only and watch for replies that appear and vanish, then re-address the offender. Steady cycling on a quiet network points at the reader's inactivity timeout — lengthen it or keep the polling object resident.
Do the HMI and the reader need a gateway or DNS server set?
No, as long as they share a subnet, which is how a point-to-point cable or an isolated vision switch should be built. The gateway only routes traffic leaving the subnet, so set it to 0.0.0.0 or the plant default and leave it alone. DNS never enters this link because the HMI object stores a numeric address — if your object is set to a host name, replace it with the reader's address. Cross-subnet links need gateways at both ends and open ports on any router between.