Print barcode labels from a vision application without an HMI add-on

You took the HMI package out of the project — or it never had a printing function — and the line still needs a barcode label for every part the vision system accepts. The fix is not an HMI option. A network label printer that speaks ZPL runs a raw TCP print service, conventionally on port 9100, and prints exactly the bytes you send it. Your vision application, a code reader, or a PLC can open that socket and send a complete label in under 200 bytes. This guide gives you the ZPL job, the arithmetic that proves the barcode fits the printhead, three wiring architectures, and the checks to run before a shift starts.

The decision: one socket, no HMI add-on

Raw TCP printing — the printer world calls it direct-socket printing — hands your bytes to the printer's network service directly: no Windows driver, no spooler, and no Line Printer Daemon in the path. On the printer side the raw print port appears as the documented ip.port setting, shipped on 9100, and the number can be changed there; print-server hardware exposes 9100 for the first printer and 9101 for a second. Your application therefore owns a short ZPL text template, substitutes the decoded string into one placeholder, and writes the result to the printer's address on port 9100.

The HMI stops being a requirement. Panels that can open a socket print their own labels, so printing QR sample labels from an HMI panel remains a valid route where an operator already works from a screen. The raw socket is the route you take when the vision application is the host, because the label format then travels with your code and survives every HMI revision.

Where the decoded string comes from

Anything on the network that produces a decoded string can feed the printer. For code reading at line rate, the fixed code readers catalog covers it: the LS-CRD-0028 reads up to 60 codes/s and delivers its results over Fast Ethernet.

At bench scale, the MV-ID3013PM-12M-WBN, a compact reader with a 12 mm focal length and a 1.3 MP sensor, hands over the same kind of string.

When the printed value comes from inspection rather than a code — an OCR result, a measured dimension formatted as text — smart cameras such as the MV-SC5060XM-08M-WBN, a 6 MP mono camera with an 8 mm focal length on GigE, generate the payload on the device. If that string arrives over the network, the same wrapping applies; see smart camera OCR string output over TCP. Strip the string to exactly what you print — truncate the reader output to the digits you need — before it touches the template.

The label: ZPL with one placeholder

A complete label is a small text job. This one prints a header, a Code 128 barcode carrying the decoded string, and a date line on a 104 mm wide, 203 dpi printhead:

^XA
^PW832
^LL600
^BY3,3,72
^FO50,50^A0N,28,28^FDWork order label^FS
^FO50,100^BCN,72,Y,N,N^FDABC-123456789^FS
^FO50,200^A0N,28,28^FD2026-11-05^FS
^PQ1
^XZ

Read it as three groups. ^XA and ^XZ open and close the format; ^PW832 sets the print width in dots (832 dots is the 104 mm head at 203 dpi, which works out to 8 dots per millimetre) and ^LL600 the label length. ^BY3,3,72 sets 3-dot barcode modules; ^FO positions each field and ^A0N,28,28 selects a text font. ^BCN,72,Y,N,N is the Code 128 field with a 72-dot bar height and the interpretation line switched on, ^FD carries the data, ^FS ends the field, and ^PQ1 prints one label.

Your code keeps everything except the payload of the middle ^FD as constant strings.

Prove the barcode fits before you order labels

Code 128 width is fixed arithmetic, so run it before committing to a printhead or label stock:

Worked example, using the payload from the job above, ABC-123456789 — 13 characters:

• modules: 11 x (13 + 2) + 13 = 178
• with quiet zones: 178 + 20 = 198 modules
• at 3-dot modules: 198 x 3 = 594 dots, and 594 / 8 = 74 mm of symbol
• against the 832-dot (104 mm) head: 594 fits with 238 dots, about 30 mm, to spare

The whole job, including the fixed text, is under 200 bytes — one TCP write. If a second station reads the label back, the printed module is 3 dots / 8 dots per mm = 0.375 mm wide, so a camera resolving 2 pixels per module needs pixels no larger than 0.19 mm on the label; the reading-distance side of that trade is covered in Code 128 module size, reading angle and reader distance.

Step by step: from accepted read to printed label

1. Fix the printer's address. Give it a static IP or a DHCP reservation, confirm the raw print port (9100 unless someone changed ip.port), and open the firewall for host-to-printer TCP on that port.

2. Prove the path before touching the vision code. From any laptop on that subnet, send the test job above and watch one label come out:

   import socket
   
   PRINTER_IP: str = "192.0.2.50"    # example address; use yours
   PRINTER_PORT: int = 9100          # raw print service
   payload: str = "ABC-123456789"    # example decoded string
   
   job: str = ("^XA^PW832^LL600^BY3,3,72"
               "^FO50,100^BCN,72,Y,N,N^FD" + payload + "^FS^XZ")
   
   with socket.create_connection((PRINTER_IP, PRINTER_PORT), timeout=2.0) as sock:
       sock.sendall(job.encode("ascii"))
   # Test: one label prints with the interpretation line ABC-123456789.
   

3. Choose who owns the socket — reader, host application, or PLC — and give the job to exactly one of them; the raw print service takes one connection at a time.

4. Validate the string before substitution: expected length, allowed characters, the prefix-character escaping above, and trimming of line endings.

5. Trigger one label per accepted read. On a failed read, print nothing — or a deliberately different reject label, never a copy of the last good one. The no-read side is its own problem; see abort a serial read when the scanner returns nothing.

6. Hold the connection open for the line's rate and reuse it; reconnect on failure with a timeout, and queue the last few labels while the printer answers ping but refuses the port.

7. Run the acceptance test: N accepted parts produce N labels, and every interpretation line matches the decode log for a full shift.

Who opens the socket: three architectures

On the PLC row, raw sockets to port 9100 work with no industrial protocol on top; barcode reader to PLC over raw TCP sockets shows the controller side and wiring your PLC as the client when the reader is the TCP server the reader side. Whole projects run this way — printing barcode labels from scanner data with a PLC is the same architecture with the controller as the socket owner.

Checks before the line runs

• Printer language: a ZPL job prints nothing usable on a printer that only speaks another label language. Confirm ZPL support before writing any code.
• Address and port static, firewall open host-to-printer on TCP 9100.
• One writer: one socket owner, or one port per writer on a print server (9100 and 9101).
• Width arithmetic done, with the symbol plus quiet zones inside both the printhead and the label stock.
• ^LL matches the stock length, or labels tear mid-print.
• No-read policy chosen and tested, including a printer-offline retry path.
• A test job sent from the actual socket owner, not from a laptop.
• Label count reconciled against read count over one shift.

When raw 9100 is the wrong answer

The printer has no network port. A USB-only printer needs a network print server with a raw port in front of it, or a network-equipped model; sharing it through a PC drags the driver and spooler back into the path you just removed.

You need proof of print. The raw socket is one-way: no acknowledgement ever comes back, so a dropped label stays silent. The engineering answer is not socket status but a read-back station — see below.

IT forbids direct sockets to printers. Route through a print-server appliance or an LPD queue instead; raw printing avoids LPD, it does not forbid it.

You are already committed to the Windows driver route, for instance to print from an existing desktop application. Then the pitfalls move into page setup and silent printing, covered in fixing page setup before hiding the print dialog.

Close the loop: prove the label, not just the print

If the label matters enough to print, read it back. A second code reader — or the same model, mounted at a verification station — confirms the printed symbol decodes to the string you sent; standalone barcode verification of model labels without a PC runs exactly that arrangement, and date code print quality inspection grades the print itself. Glossy label stock glares under the reading light; a semi-polarizing lens cover such as the MV-SC3000-C-HP on the smart camera tames it.

Pick the reader that feeds your printer in the code reader finder, and if the printing side fights you — escaping, framing, rate — tell us the printer model and reader series on the contact page.